Amazon jetzt auch Intruder?

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Ich bin jetzt ein bisschen platt... Gehört Amazon jetzt auch zu den Eindringlingen, die fremde Server hacken?

2015-03-11 16:18:15,780 fail2ban.actions: WARNING [ssh] Ban 54.154.82.95

root@xxx:# whois 54.154.82.95

ARIN WHOIS data and services are subject to the Terms of Use

available at: https://www.arin.net/whois_tou.html

If you see inaccuracies in the results, please report at

http://www.arin.net/public/whoisinaccuracy/index.xhtml

The following results may also be obtained via:

http://whois.arin.net/rest/nets;q=54.154.82.95?showDetails=true&showARIN=false&ext=netref2

NetRange:       54.144.0.0 - 54.159.255.255 CIDR:           54.144.0.0/12 NetName:        AMAZON NetHandle:      NET-54-144-0-0-1 Parent:         NET54 (NET-54-0-0-0-0) NetType:        Direct Allocation OriginAS: Organization:   Amazon Technologies Inc. (AT-88-Z) RegDate:        2014-10-23 Updated:        2014-11-13 Ref:            http://whois.arin.net/rest/net/NET-54-144-0-0-1

OrgName:        Amazon Technologies Inc. OrgId:          AT-88-Z Address:        410 Terry Ave N. City:           Seattle StateProv:      WA PostalCode:     98109 Country:        US RegDate:        2011-12-08 Updated:        2014-10-20 Comment:        All abuse reports MUST include: Comment:        * src IP Comment:        * dest IP (your IP) Comment:        * dest port Comment:        * Accurate date/timestamp and timezone of activity Comment:        * Intensity/frequency (short log extracts) Comment:        * Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time. Ref:            http://whois.arin.net/rest/org/AT-88-Z

OrgTechHandle: ANO24-ARIN OrgTechName:   Amazon EC2 Network Operations OrgTechPhone:  [phone] OrgTechEmail:  [e-mail] OrgTechRef:    http://whois.arin.net/rest/poc/ANO24-ARIN

OrgAbuseHandle: AEA8-ARIN OrgAbuseName:   Amazon EC2 Abuse OrgAbusePhone:  [phone] OrgAbuseEmail:  [e-mail] OrgAbuseRef:    http://whois.arin.net/rest/poc/AEA8-ARIN

OrgNOCHandle: AANO1-ARIN OrgNOCName:   Amazon AWS Network Operations OrgNOCPhone:  [phone] OrgNOCEmail:  [e-mail] OrgNOCRef:    http://whois.arin.net/rest/poc/AANO1-ARIN

Ist das noch normal? Es muss mindestens drei Fehlversuche geben, damit fail2ban tätig wird - Standardeinstellung

Spirituelle Grüße Euer Robert

[dedlfix]

Tach!

Gehört Amazon jetzt auch zu den Eindringlingen, die fremde Server hacken?

Vermutlich nicht, aber zu den Unternehmen, bei denen man Rechenleistung und virtuelle Server mieten kann.

dedlfix.

[Robert (off)]

Tach!

Gehört Amazon jetzt auch zu den Eindringlingen, die fremde Server hacken?

Vermutlich nicht, aber zu den Unternehmen, bei denen man Rechenleistung und virtuelle Server mieten kann.

Also ein Fremder, der es nun von Amazons Serverfarm aus probiert?

Also sollte ich die Amazons eher mal darüber informieren?

Robert

[Jörg Reinholz]

Also sollte ich die Amazons eher mal darüber informieren?

Gute Güte.

Wie viel Arbeit willst Du Dir damit machen?

Ich reagiere nur noch bei Notorikern und zwar mit einer anhaltenden Sperre. Oder solchen Dummköpfen.

Jörg Reinholz

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Also sollte ich die Amazons eher mal darüber informieren?

Gute Güte.

Wie viel Arbeit willst Du Dir damit machen?

Ich reagiere nur noch bei Notorikern und zwar mit einer anhaltenden Sperre. Oder solchen Dummköpfen.

Nun denn, wenn der über Tage immer und immer wiederkommt? Ich habe leider vorhin erst mein Verdichtungsscriptlein laufen lassen. Und siehe da, der Typ war immer wieder mal da. Das sieht man im normalen Log-Verlauf ja gar nicht so leicht.

Spirituelle Grüße Euer Robert

[Jörg Reinholz]

Nun denn, wenn der über Tage immer und immer wiederkommt?

Dann blocke ihn manuell mit iptable. ?

Jörg Reinholz

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Nun denn, wenn der über Tage immer und immer wiederkommt?

Dann blocke ihn manuell mit iptable. ?

Ach mein lieber Jörg, das habe ich doch schon umgesetzt und bin Dir auch dankbar für den Hinweis. Aber das beseitigt doch nicht das Problem, sondern nur dessen Wirkung...

Spirituelle Grüße Euer Robert

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Ach mein lieber Jörg, das habe ich doch schon umgesetzt und bin Dir auch dankbar für den Hinweis. Aber das beseitigt doch nicht das Problem, sondern nur dessen Wirkung...

Und Du weißt doch:

[code lang="phrase"]     Und ist das Skriptlein noch so schlau, schau trotzdem hin, Du faule Sau!

[/code]

Spirituelle Grüße Euer Robert

[Mattes]

Dann blocke ihn manuell mit iptable.

Aber das beseitigt doch nicht das Problem, sondern nur dessen Wirkung...

Du wirst das Problem nie beseitigen. Hast du diesen Wicht ausgesperrt, kommt morgen der nächste (oder derselbe unter anderer IP).

Ich weiss nicht, welche Regel du für ssh einsetzt, aber Leute, die wahllos Namen und Passwörter durchprobieren, könntest du im Grunde geflissentlich ignorieren, sofern du den ssh-Zugang nur per Schlüssel erlaubst. Sie werden mit der Methode schlichtweg nicht reinkommen, genauso wenig wie man mit einem Dietrich die PIN-Eingabe am Geldautomaten überlisten kann.

Das soll nun keine Rede gegen fail2ban sein, aber du brauchst dir auch nicht um jeden Hansel einen Kopf machen. fail2ban soll dir mit seinem Automatismus Arbeit abnehmen – nur musst du das auch zulassen, anstatt dir noch mehr Arbeit aufzuhalsen wegen irgendwelcher Sachen, die vielleicht an sich, siehe oben, gar keine Gefahr darstellen. Bei ganz Hartnäckigen kann man noch eine manuelle Sperre anlegen, aber alles darüber hinaus ist verschwendete Lebenszeit.

Ich habe bei meinen Servern den ssh-Port sogar komplett gesperrt und Ausnahmeregeln für die zwei Adressbereiche angelegt, über die mein Provider mich ans Netz klemmt (mit einem Hintertürchen). Das ist quasi das Gegenteil deiner Strategie und funktioniert seit Jahren bestens. Wenn ich nie aus Russland rein muss, warum soll ich mich um jeden Russen-Dödel kümmern, der gegen's Türchen bollert?

[Alexander (HH)]

Moin Moin!

Wunderbar, Dein Posting nimmt mir eine Menge Tipperei ab. ;-)

Ergänzend:

1. Bei sehr massiven Angriffsversuchen kommt wegen der "Du kummst hier net rein"-Antworten vom sshd immer noch eine Menge Traffic zusammen, die den Hoster nervös machen können. Ich hab das mal mit einem Hoster aus Süddeutschland ausdiskutieren dürfen, dass kein Idiotenscript mit Name und Passwort in meinen Key-Only-sshd reinkommt. K.O.-Argument vom Hoster war: Das macht trotzdem zu viel Traffic. Deswegen habe ich zusätzlich zu einem Key-Only-sshd fail2ban aktiviert, damit der sshd nur die ersten paar Versuche pro IP beantwortet.

2. Es hilft, den sshd auf einem anderen Port als 22 laufen zu lassen (> 1024), darauf sind die typischen Scripte bislang offensichtlich nicht ausgelegt.

3. Wenn man den sshd auf bestimmte IP-Ranges einschränkt und dann doch mal in eigentlich geblockten Regionen der Welt unterwegs ist, kann ein SSH- oder VPN-Tunnel "nach Hause" sehr hilfreich sein, um von dort aus per SSH über eine "saubere" IP-Adresse auf den Server zu kommen.

4. Für Tage, an denen man hinter einem halbwegs paranoiden Proxy sitzt, hilft ein Multiplexer, der auf Port 443 gleichzeitig SSH und HTTPS anbietet. PuTTY kann von sich aus durch einem HTTP-Proxy per CONNECT auf einen SSH-Server gehen, für ssh unter Linux gibt's ein paar Helferlein, die alle über die Option ProxyCommand arbeiten. Für den Proxy ist das nicht von einem Zugriff auf eine per HTTPS abgesicherte Website zu unterscheiden. Nachteil ist, dass die meisten Multiplexer eine eigene Verbindung zum httpd bzw. zum sshd aufmachen und so alle eingehenden Verbindungen zum httpd bzw. zum sshd vom localhost zu kommen scheinen. Einige wenige frickeln mit den Netzwerk-Stack von Linux rum und umgehen das Problem, indem sie die bereits offene Verbindung an httpd oder sshd weiterreichen. Das wiederum kann sich mit Firewall-Scripten beißen, die mit dem Trick nicht rechnen. Und natürlich ist das Linux-spezifisch, während der Weg über localhost auf so ziemlich jedem Unix funktionieren dürfte.

Alexander

[Kay]

Meine Erfahrung in Kurzform

Denn Port ändern bringt schon mal gefühlte 99,9% weniger Versuche.

Portknocking reicht. http://de.wikipedia.org/wiki/Portknocking

Da ich meistens nur nginx nutze, es sein den ich brauche Hochleistungswebserver, hat sich ein 404 bei den ganzen gängigen Pfanden und Programmen bewährt. Ich muss meine Resourcen ja nicht verschenden, in dem ich auch noch korrekt antworte.