Diese E-Mail kommt aus einer Mailingliste, ich reiche sie hier mal an das Publikum weiter. Vielleicht kann ja jemand der Person helfen:
Hallo!
Ich habe seit geraumer Zeit das zweifelhafte Vergnügen, eine nicht ganz unerhebliche Zahl an Angriffen via ssh zu beobachten (alles nur Login-Versuche auf Server). Konkret geht es um das Ausprobieren von Kombinationen aus Benutzernamen und Passwörtern.
Im Grunde kann einem das egal sein, wenn man Login via Passwort nicht
zulässt und stattdessen mit public/private key arbeitet. Allerdings wird das in den Logfiles inzwischen extrem auffällig und es vernebelt möglicherweise die Sicht auf ernstzunehmende Angriffe. Es handelt sich um mehrere Hundertausend Zeilen pro Woche in auth.log oder grob alle 10s ein Versuch im statistischen Mittel - möglicherweise mehr und mit steigender Tendenz.
Es gibt verschiedene Antwortoptionen, z.B.:
1.) Ignorieren - Vogel Strauß.
2.) Nur erfolgreiche Logins loggen - Drei Affen
3.) Blacklist erstellen
4.) Whitelist
5.) fail2ban
6.) VPN vorschalten
7.) Port knocking
Es gibt auch harte und weiche Rahmenbedingungen. Zwingend sind:
I) Die Guten brauchen immer Zugriff (Feuerwehraxiom).
II) Die Bösen müssen draußen bleiben (Polizeiaxiom).
III) Es handelt sich um einen isolierten Mietserver (Blech).
Wünschenswert sind:
A) Ich würde gerne sehen, was da passiert.
B) Ich möchte die Angreifer studieren und lernen.
C) Die Lösung soll transferierbar und anpassbar sein.
D) Die Lösung soll in ein universelles Konzept passen, ggf. mit
mehreren Komponenten.
E) Der Aufwand soll überschaubar sein.
F) Das Konzept soll nachvollziehbar sein.
G) Gegenmaßnahmen sollen keine Informationen leaken, die für den
Angreifer hilfreich sind.
H) To be continued…
Strauß und Affen mag man in der Natur beobachten oder im Zoo; meine Welt ist das nicht, sonst gäbe es diese E-Mail auch gar nicht.
Da sich II von selbst versteht, ist I die harte Nuss. Aus den Erfahrungen der letzten 20 Jahre kann ich sagen, dass auch ein sshd manchmal leise Servus sagt. Da die Möglichkeit des Zugangs robust gestaltet werden soll, ist Redundanz erforderlich. Daher habe ich mehrere sshds am Start, teilweise in unterschiedlichen Konfigurationen. Leider bietet sich wegen III ein Zugriff über einen Jumphost und/oder über eine andere Netzwerkschnittstelle nicht an. Die Redundanz muss über eine einzige NIC realisiert werden. Eine Oder-Verknüpfung[8] über verschiedene Ports reicht
aus.
Ein VPN wäre im Sinne von II sehr schön, allerdings gäbe es dann ebenfalls das Redundanzproblem bzgl. I in sich und zusätzlich eine Und-Verknüpfung[9] mit sshd, was den Aufwand hinsichtlich E hochtreibt. Allerdings ist ein mehrfaches VPN eine Option. Vielleicht wird das eine zukünftige Ausbaustufe nach D.
Port knocking stört A, wäre aber in Verbindung mit einem kombinierten
Konzept die optimale Lösung. Dafür sollte man einen sshd reservieren.
Fail2ban kann bei direktem Kontakt eines offenen Portes im Netz auch
nützlich sein, ist aber pro Einzelangriff keine dauerhafte Lösung, wenn die Sperre temporär ist. Als zweite Verteidigungslinie ist es definitiv eine wichtige Waffe.
Damit kommen wir zum interessanten Teil - für diejenigen, die überhaupt bis hierhin durchgehalten haben. Eine Whitelist mit sonstiger Totalsperre widerspricht A und B, erfüllt aber E und funktioniert, solange ich aus dem richtigen Netz zugreifen kann.
Eine Blacklist ohne Whitelist riskiert Störungen von I. Beides ist in einem kombinierten Setup mit mehreren verschiedenen Eingängen noch robust genug. Die Kombination von beidem mit der zweiten Verteidigungslinie fail2ban ist noch eleganter.
Die technische Umsetzung erfordert etwas Denk- und Fleißarbeit, und initial ist der Aufbau der Blacklist widerliche Arbeit (der erste Teil betrifft die Struktur, der zweite die Daten), aber es lohnt sich. Man lernt bei der Recherche eine ganze Menge, sieht Muster in den Logfiles, und inzwischen kann ich mit statischen Listen (IPv4) weit über 95% filtern. Die verschiedenen Ports geben verschiedene Statistiken, und bzgl. angreifenden IPs und angegriffenen Ports kann man sogar ein Ausweichverhalten der Angriffe beobachten.
Der interessanteste Effekt war die mutmaßliche Annahme der Angreifer (ich habe natürlich nicht mit ihnen gesprochen), dass es einen Last-Trigger oder eine temporäre Sperre gibt. Die Zeit zwischen zwei Angriffen von der gleichen IP ist bei einigen mehrstufig nach oben gegangen. Ist G überhaupt erfüllbar?
Ebenfalls lässt sich vermuten, dass Portscans und Angriffe in einigen Strukturen getrennt sind. Das sieht man vermöge eines selbstgebauten TCP Loggings mit iptables.
Unerfreulich ist, dass es Firmen im Security Umfeld gibt, die ihre Ergebnisse der Portscans als Service im Web veröffentlichen. Damit muss ein Angreifer nicht selber scannen und taucht nicht im Log auf. Ist das eine Dienstleistung speziell für die Mafia? Hier wäre zu überlegen, ob man denen nicht einen völlig falschen Sachverhalt vorspiegelt. Einen offenen Port, den nur die sehen, und der deren Datenbestand mit einer Halluzination verseucht. Damit könnte man auch sichtbar machen, wer (im Sinne welche angreifende IP) sich an diesem Datenbestand bedient. Wenn die Grundstruktur steht, hat man eine Honeypot-Spielwiese.
Noch eine Erkenntnis: Dial-Up mit infizierten Privatrechnern taucht kaum auf - was an meiner verzerrten Wahrnehmung und der Reihenfolge der Sperren liegen kann. Cloudprovider von gross bis klein sind aber episch vertreten. Entweder mieten sich Angreifer die Ressourcen, die Kunden sind unfähig Ressourcen abzusichern oder die Cloudprovider stellen idiotisch schlecht abgesicherte Standardkonfigurationen für ihre Kunden bereit, weil kein Geld für geschultes Personal da ist. Es wird auch nicht besser werden: wenn heute die Jobs fehlen, wer soll dann in dieses Berufsfeld gehen und morgen die Arbeit machen? Security belastet den Shareholder Value.
Daher heute ein Menü im Sternerestaurant und morgen dann die Henkersmahlzeit. Das muss die Nachhaltigkeit sein, von der alle reden. Oder doch eher die spätrömische? Der Fachkräftemangel trifft aber auch die Angreifer. Aus dem log:
| error: kex_exchange_identification: client sent invalid protocol identifier „GET / HTTP/1.1“
Fällt der Cybercrime ROI so klein aus, dass man sich nur noch Azubis leisten kann? O tempora, o mores!
Das Thema ssh verdient definitiv eine Vertiefung. Die von den Distributionen gelieferten Werkzeuge sind IMO nicht mehr hinreichend zeitgemäß, um Infrastruktur im Netz sinnvoll zu betreiben. Es ist nicht die Gefährlichkeit der Angriffe, sondern die Datenflut und die Gefahr der Abstumpfung, die mir Sorgen bereitet. Und die nächste Iterationsstufe steht natürlich vor der Tür: KI. Damit kann man anderen Leuten dann vollautomatisch auf den Senkel gehen.
Ggf. die Firewall auf den neuen Port anpassen^^
