• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

ssh nur aus bestimmtem IP-Range

tsk

Member
Moin in die Runde,

man sollte ja regelmässige seine Sicherheitsstrategien überdenken, und ich frage mich gerade, wie ich bestimmte Serverdienste hochgradig einschränken kann.

Ein Beispiel: ssh
Natürlich ist der Zugang beschränkt. Key Auth only. Gegebenenfalls verlegter Port. fail2ban etc. Noch schöner wäre es, den Zugang nur für bestimmte IP zu erlauben. Aber genau das hat mich mal ein schlafloses Wochenende gekostet, als mein heimatlicher Provider meine seit 5 Jahren feste IP Adresse geändert hat - geräuschlos und ohne Ankündigung.

Meine erste Idee war, den gesamten IP Range meines Providers (KPN) per ufw/iptables bei ssh zu erlauben (81.205.0.0/16). Dummerweise haben die deutlich mehr als einen, und dann auch noch Kooperationen mit diversen anderen Anbietern. Ist zu heikel.

Die zweite Idee war, Zugriff nur aus Europa zu gestatten. Aber leider hat Ripe keinen homogenen IP Block.

Mir geht es um Sicherheit und Ruhe in den Logs, bei gleichzeitig minimaler Serverbelastung. GeoIP wäre sicherlich schick, erzeugt aber zuviel Last auf einem vServer.

Irgendwelche Ideen?

Grüße,

Thomas
 
Hallo marce,

danke für den Hinweis. Ich mache mir auch weniger Gedanken um die Sicherheit. Die ist mit Key Auth schon weitreichend. Mir geht es aber auch ein bisschen um die Logs bzw. Serverlast. Alles was am Firewall bereits abgewiesen wird, beschäftigt den Server weniger. Macht hier ein Portknocker eventuell Sinn?
 
Was soll es noch für Ideen geben wenn du Zugriffe (Geo-) Lokal beschränken willst ausser IP-Blocks/GeoIP? Es gibt auch externe Geo-APIs aber wenn die gerade nicht erreichbar ist bringt das auch nichts.

Meiner Meinung nach ist das vorsorgliche IP geblocke, auser von bekannten immer wiederkehrenden Blöcken, übertrieben und unnütz. Wenn man an Key-Auth vorbei kommt hat man sowieso ein Problem an anderer Stelle, und wenn es kein Key Leak/Weak-Key ist dann ein SSH exploit die dann meist sowieso schon vor jeglicher Form der Validierung einsetzen.
 
Wenn es darum geht, dass man die Logs sauber hält, reicht es bereits aus, wenn man einen sehr exotischen Port wählt.
Ich hatte innerhalb eines halben Jahres keinen einzigen unberechtigten Loginversuch mehr im Log stehen.
Davon abgesehen setze ich auch auf ein key pair.

Sicherheit bringt das natürlich nicht, da man per Portscan den Port finden kann. Das Grundrauschen (sprich: der Logspam) wird aber fast auf 0 reduziert.
 
Ok, prima. Ich fühle mich schon stark beruhigt. Will kurz erklären, warum ich immer noch ein Restrisiko in Key Auth only sehe.

Ich bin gezwungen, auf meinem heimischen PC eine Boot Partiton für Windows zu haben (also Dual Boot mit Linux). Derzeit kommt meine Linux Büchse an alle Windows Daten, aber nicht umgekehrt. Es mögen aber Gründe kommen, bidirektionale Zugriffe zu gestatten. Ab diesem Moment wäre mein Privat Key (derzeit ausschließlich auf NIX) nicht mehr unantastbar. Andererseits. Jemand der soweit kommt, kann sicher auch über meinen Linux PC direkt auf den Server.

Mein letzter live Server ist 2 Jahre her, aber ich erinnere mich an viele Portscans und auch ein gut beschäftigtes fail2ban. Mit einem Portknocker gibt es viele Ports (virtuell) gar nicht, und jeder Portscan sollte bescheiden enden, und dem Pack vielleicht die Lust nehmen, weiter zu graben. Spräche da was gegen?
 
Dass Du mit fail2ban die Last grundsätzlich stark erhöhst statt sie zu senken ist Dir aber bewusst?
Schmeiss fail2ban komplett weg und konfiguriere stattdessen die Dienste vernünftig.
 
Ja, ich möchte tatsächlich fail2ban überflüssig machen, und die maximale Absicherung meiner Dienste ist ja gerade meine Absicht. Habe mich heute neben den Port Knockern auch in SinglePacketAuthorization eingelesen, und das Konzept gefällt mir. Die angenehmen Features des Port Knockers, ohne dessen Nachteile. Werde es morgen mal testen.
 
Dass Du mit fail2ban die Last grundsätzlich stark erhöhst statt sie zu senken ist Dir aber bewusst?
Schmeiss fail2ban komplett weg und konfiguriere stattdessen die Dienste vernünftig.

Doch nur beim dDoS. Würde ein Angriff von einer einzigen IP kommen, wird die IP via iptables gesperrt. Bekommt man sehr viele Login-versuche von unterschiedlichen IPs, könnte die Last steigen. Signifikant? Hat das schon mal jemand probiert?
 
IP-Pakete die schlicht am Kernel (kein lauschender Dienst) oder der App (lauschender Dienst) abprallen erzeugen per se weniger Last, als wenn diese Pakete zusätzlich auch noch durch diverse Subsysteme wie Netfilter und natürlich fail2ban samt fettem Python wandern müssen. Das ganze Logparsen habe ich dabei noch gar nicht mitgerechnet...

Sorry, aber zum Senken der Systemlast kann fail2ban maximal vor einem Java-basierten Dienst nutzen, sofern dieser mindestens zu 50% mit unerwünschten Paketen beglückt wird, in nahezu allen anderen Fällen erzeugt es per Design nur unnötige zusätzliche Last.

fail2ban gehört zu den dümmsten und überflüssigsten Apps dieses Jahrtausends.
 
Back
Top