Datenhaufen zu IT und Elektronik.

Kategorie: Kernel-Error-Blog (Seite 9 von 47)

Ausfall bei Telekom SmartHome

Das Telekom SmartHome System hat seit gestern am Morgen Probleme. Die automatischen Regeln tun was sie sollen und lokal kann man sich ebenfalls noch mit der Box verbinden und fast wie gewohnt steuern. Online ist aber kein Stich zu machen. Ebenfalls die Anbindung mit anderen Onlineservices ist damit tot.

https://community.qivicon.de/questions/ausfall-im-qivicon-rechenzentrum-homebases-aktuell-nicht-online

Ausfällt und Probleme kann es immer mal geben. Vor allem dieses Qivicon / Telekom „Ding“ ist mäßig stabil, tat aber in den letzten Monaten recht brauchbar seinen Dienst. Ein Ausfall von nun knapp 24Stunden ist dennoch echt heftig. Ich kann mir nicht viele Dinge vorstellen bei denen es zu so einem langen Ausfallen kommen kann, vor allem das die Herren so ja keinen besonderen Peak haben dürften. Hier hat wohl jemand echt massiv verkackt, sofern nicht gerade jemand die Jungs mit einem DDoS „warm“ hält. Das hätte man sicher schon über andere Wege erfahren.

Ob da wohl jemand die Datenbank kaputt gemacht hat? Vielleicht ist hier ja was out of sync, das wieder zusammen zu bekommen kann schon mal echt lange dauern 🙂 Fast alles andere ist: An der falschen Stelle gespart oder halt epic fail.

Samstag am Morgen hat es angefangen, na da werden wohl jetzt ein paar Bereitschaftsadmins und Devs um ihr Wochenende gebracht. Na dann….

Postfix: E-Mail-Verschleierung gezielt einrichten

Um sich vor Angreifern zu schützen ist ein ganz gutes Mittel, dem Angreifer nicht direkt zu erzählen welche Software genau und in welcher Version man diese einsetzte. Bei Webservern ist dieses fast überall gängige Praxis, meist bekommt man nur noch das Produkt angezeigt. Oder wie bei einem Kollegen nur YOUR MUM. Warum ist das nun ggf. hilfreich? Ganz simples Beispiel. Man setzt einen verwundbaren Mailclient auf seinem Desktop ein, oder hat einen phpmailer (*würk*) in seiner Webseite eingebaut. Versendet man über diesen nun eine E-Mail schreibt er meist seinen eigenen Namen mit der eingesetzten Version in die E-Mail Header. Copy & Paste fertig für einen möglichen Angreifer, damit er die „Bugzilla Page“ nach den brauchbarsten Löchern durchwühlen kann. Dann muss er nur noch eine passende präparierte E-Mail schreiben und der Client wird leiden.

Ähnlich ist es mit den IP Adressen. Die IP Adresse des Clients landet ebenfalls in den Mail Headern. So hat der Angreifer schon mal eine Idee über die Netztopologie oder es gibt ihm ggf. eine Möglichkeit den Benutzer durch verschiedene Netze zu „tracken“.

Beides lässt sich über die smtp_header_checks etwas entschärfen. Über diesen Weg kann man per RegEx bestimmte Mail Header heraussuchen und löschen oder nach eigenem Ermessen ersetzten.

Hier der Eintrag für die main.cf:

root@smtp:/usr/local/etc/postfix # postconf smtp_header_checks
smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Hier das Beispiel für die /usr/local/etc/postfix/header_cleanup:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Im Ergebnis sieht es dann wie folgt aus:

[...]
Received: from ::88 (YOUR MOM [::88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.kernel-error.de (Postfix) with ESMTPSA id 7458E7B802
	for <wurst@example.com>; Wed, 27 Mar 2019 21:44:10 +0100 (CET)
[...]
X-Mailer: YOUR MOMS MAILER
[...]

Ganz wichtig ist natürlich die Frage ob dabei Signaturen gebrochen werden; das werden sie nicht. Auch DKIM usw. nicht.

Dann mal viel Spaß!

Postfix-Fehlerantworten anpassen: So gehst du vor

Wieder wurde ich gefragt wie ich bei meinem Postfix den Error Reply für rejected 5xx E-Mails geändert habe. Nun ja, das habe ich überhaupt nicht.

Postfix hat seit vielen Jahren die Option: smtpd_reject_footer diese wurde in 2011 beim „Aufräumen“ umbenannt in: smtpd_reject_footer

Cleanup: smtpd_reject_contact_information is renamed to smtpd_reject_footer, because it can be used for non-contact information.

Beide Optionen sind anscheinend eher unbekannt. Was ich gut verstehen kann. Denn setzt man nun in seiner main.cf den smtpd_reject_footer wird diese zwar brav angehangen und taucht sogar beim Absender im Postfach auf, nur welcher Benutzer liest diese schon und folgt dann noch dem jeweiligen Hinweis? Bisher ist diese Rückmeldung meines Systems nur sehr wenigen überhaupt aufgefallen ;-P

Vor ~12 Jahren habe ich sie wohl zum ersten Mal gesetzt. Ich meine da auf die Adresse vom Postmaster verwiesen zu haben, damit die Nutzer sich dort hin melden können. Später hatte ich mal einen Link auf eine zweisprachige Hilfeseite bei mir und noch später etwas wie: „Das Problem ist zu 99% dein Mailserver, frag DEINEN Admin!“. Dieses war es bis heute, denn heute habe ich die erneute Frage zum Anlass genommen, dieses hier zu schreiben und natürlich direkt auf riot.im zu verlinken. Dann kann man mich direkt anschreiben. Sicher etwas freundlicher als: „geh weg du bist eh das Problem“ und einfacher als noch eine E-Mail an den Postmaster zu schreiben. Sicher werde ich nun durch diese Nachricht 1 oder 2 mal im Jahr angeschrieben, wenn es dieses überhaupt wird.

Achja, so sieht der Eintrag in der main.cf von Postfix aus:

root@smtp:/usr/local/etc/postfix # postconf smtpd_reject_footer
smtpd_reject_footer = For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com

Damit lässt sich nun dieses Ergebnis erzielen:

banane@bsd03:~ # telnet smtp.kernel-error.de 25
Trying 2a01:4f8:150:1095::25...
Connected to smtp.kernel-error.de.
Escape character is '^]'.
220 smtp.kernel-error.de ESMTP Postfix
helo asdf
250 smtp.kernel-error.de
mail from: <test@spam.de>
250 2.1.0 Ok
rcpt to: <spamlover@kernel-error.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: test
.test
.
554-5.7.1 Spam message rejected
554 5.7.1 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
Connection closed by foreign host.

Fragen? Dann wie immer bitte fragen…

Raspberry Pi verstärkt als Angriffsziel

In den einen oder anderen meiner Honeypots greifen in den letzten Monaten verstärkt Bots beim Versuch sich mit dem Benutzernamen PI anzumelden. Im November 2018 waren am SSH 13% der Loginversuche mit dem User pi. Für März 2019 sieht es so aus als wenn es etwas um 87/88% werden. Ganz früher waren es ja mal die User root oder test und so etwas… Inzwischen also pi, gut gut. So verstärkt ist nur etwas auffällig. Ist da ein Loch? Sind zu viele Anwender zu nachlässig bei der Zugangssicherung und die Dinger stehen wirklich so „nackt“ im Internet? Leider scheint mir das Letztere nicht sehr unwahrscheinlich :-/

Alles >= Pi3 hat ja schon eine ganz gute Rechenleistung. Hoffen wir einfach mal darauf, dass die Bots dieses nur zum Rechnen von Cryptogeld nutzen wollen und nicht zum Spammen oder noch schlimmer für Angriffe. Loginversuchszahlen größer 70% habe ich sonst oft nur kurz vor einem großen DDoS gesehen. Jemand andere Zahlen für mich?

Mar 25 06:20:21 pot06 sshd[93829]: Invalid user pi from xx.xx.xx.xx port 55312
Mar 25 06:20:21 pot06 sshd[93829]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55312 ssh2
Mar 25 06:20:21 pot06 sshd[93827]: Invalid user pi from xx.xx.xx.xx port 55310
Mar 25 06:20:21 pot06 sshd[93827]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55310 ssh2
Mar 25 06:20:21 pot06 sshd[93829]: Connection closed by invalid user pi xx.xx.xx.xx port 55312 [preauth]
Mar 25 06:20:21 pot06 sshd[93827]: Connection closed by invalid user pi xx.xx.xx.xx port 55310 [preauth]

Oh was ebenfalls sehr verdächtig ist: Die Quellen dieser Loginversuche kommt nicht wie sonst aus Indien, China usw… Sondern inzwischen ebenfalls sehr oft aus dem DACH-Raum. Nicht das hier dem Menschen besonders sicher und vorsichtig sind; nein es zeigt nur, dass die Angriffe wohl schon oft erfolgreich waren.


Kleines Update

Habe hier drei Rückmeldungen welche sich sehr ähnlich anhören 🙁 Alles aber aus der gleichen unprofessionellen Sicherheitsblase. Vielleicht kommt ja noch eine „unabhängige“ Meinung?!?

Da hat jemand SSLv3 bei Bechtle abgeschaltet….

Erinnert ihr euch noch an meine Onlinetool Empfehlung und den dort verwiesenen Mailserver der Domain bechtle.com/de? Auf meine Frage hin hat mir ja leider niemand richtig geantwortet, nicht mal der Postmaster 🙁 Aber inzwischen ist SSLv3 abgeschaltet!

Es hätte ja zumindest mal jemand etwas anders sagen können als: „Geh weg du bist privat, dafür haben wir hier so nen anderen…“ Aber naja… Nun gibt es am Mailserver von Bechtle zumindest kein SSLv3 mehr 😀 Ich stelle mir einfach weiterhin vor, dass es durch meinen Hinweiß abgeschaltet wurde.

In diesem Sinne…

Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu „probieren“.

Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!

Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: https://github.com/Kernel-Error/postfix-mta-sts-resolver

Wer es also ebenfalls mal probieren möchte, viel Spaß.

Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer mta-sts im System. Wir wollen es ja nicht als Root laufen lassen, hm?

Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*


Update

Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.

Fragen? Dann fragen 🙂

Topf Secret

Das Projekt FragDenStaat kennt ja inzwischen fast jeder und die meisten werden es schon mal genutzt haben. Etwas übersehen habe ich Topf Secret. Kommt aus dem gleichen Projekt, dreht sich dabei aber speziell um das Thema Lebensmittelhygiene.

https://fragdenstaat.de/blog/2019/01/15/neue-kampagne-topf-secret/

Ich habe ein paar Anfragen gestellt, bin mir nur noch nicht ganz Sicher ob ich es wirklich wissen möchte. Ein Kollege hat mir mal gesagt: „Wer viel fragt; bekommt viele Antworten!“ :-/ Was meint ihr dazu?

SMTP MTA-STS: Strict Transport Security für deinen Mailserver

Haben wir uns schon über MTA STS / RFC 8461 unterhalten? Nicht? Dann dann wird es aber Zeit 🙂

MTA STS ist ein RFC von Ende 2018. So kann man eine Policy veröffentlichen um anderen Mailservern mitzuteilen, dass man seine E-Mails bitte nur per TLS (also mit Transportverschlüsselung) erhalten möchte und an welchen MX…

Eine ganz nette Idee nur…. Wenn man keine E-Mail ohne Transportverschlüsselung erhalten möchte, dann könnte man ja einfach keine E-Mails ohne Transportverschlüsselung annehmen?!?!? Natürlich sagt man anderen Mailservern zusätzlich noch an welchen sie bitte die Mails zustellen sollen, das es eine Transportverschlüsselung geben muss und alles nur mit einem gültigen Zertifikat ablaufen kann.

Fehlt da nicht noch etwas? Klar reporting… Dazu gibt es im Moment ein RFC: SMTP TLS Reportingdraft-ietf-uta-smtp-tlsrpt-23

Ein einfaches Onlinetool zum Testen gibt es ebenfalls: MTA-STS validator

Was muss man dafür nun tun? Ohne Frage muss der eigene Mailserver sauber TLS sprechen… Dann wirfst man einen TXT RR in die jeweilige DNS Zone:

$ dig IN TXT _mta-sts.kernel-error.de +short
"v=STSv1;id=20190202111557Z;"

Die eigentliche Policy veröffentlich man nun per Webserver jeweils für die Zone unter: mta-sts.domain.tld https://mta-sts.kernel-error.de/.well-known/mta-sts.txt

Das Reporting lässt sich ebenfalls schnell per TXT RR in der DNS Zone einrichten:

$ dig IN TXT _smtp._tls.kernel-error.de +short
"v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"

Beides ist sehr schnell und einfach eingerichtet. Postfix selbst berücksichtigt dieses leider noch nicht. Es gibt natürlich schon eine Implementierung, welche ich persönlich noch nicht ganz glücklich finde. Wer schon mal schauen will: https://github.com/Snawoot/postfix-mta-sts-resolver

Fragen? Dann einfach mal fragen 🙂

Mailserver Test aus Holland

In den Niederlanden gibt es eine staatliche Initiative um das Internet Sicherer zu machen. Dazu gehören ebenfalls verschiedene Onlinetools zum Testen seiner Systeme.

Ganz gelungen finde ich dabei das Tool zum Testen seines Mailserver. Wenn ich da einfach mal eine Domain eintrage: https://en.internet.nl/mail/bechtle.de/201507/ Fällt mir auf, dass ich da mal fragen sollte warum SSLv3 mit RC4 hier anscheinend noch OK ist.

Viele Spaß beim Selbstscan! Bei Fragen natürlich wie immer einfach fragen 🙂


Als kleines Update… Die Jungs haben auf meine Frag/Hinweiß geantwortet:

Guten Tag,

vielen Dank für Ihre Anfrage und das damit verbundene Vertrauen in unser Unternehmen.

In der Bechtle Gruppe sind die Kundensegmente zwischen Bechtle direct GmbH und der ARP GmbH so aufgeteilt, das jeder Kunde gemäß seinen Bedürfnissen optimal betreut werden kann.

Während sich die BechtleAC direct GmbH ausschließlich auf Großkunden und Konzerne konzentriert, bietet die ARP GmbH allen Kundensegmenten ein großes Sortiment von IT-Hard- und Software sowie individuellen IT-Lösungen an. Neben der persönlichen Betreuung verfügt die ARP GmbH über einen preisgekrönten Online-Shop, der auf die individuellen Bedürfnisse jedes Kunden anpassbar ist.

Bitte wenden Sie sich mit Ihrem Anliegen direkt an die ARP GmbH. 

Hm… Ob sie das RFC beachten und ich den Postmaster erreiche?

*trommelwirbel*

Mar  6 08:14:49 smtp postfix/smtp[97730]: 5193FB4292: to=<postmaster@bechtle.com>, relay=mx.bechtle.com[178.249.84.24]:25, delay=17, delays=0.41/0.02/15/1.2, dsn=2.0.0, status=sent (250 2.0.0 2qygs8tdp2-1 Message accepted for delivery)

Zumindest nicht sofort abgewiesen 🙂

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑