externes SSH verbieten

[Tunx]

Hi,
nachdem der Router jetzt erfolgreich seinen Dienst tut würde ich gerne die Angelegenheit noch verfeinern. Für die Fernwartung benutze ich SSH (OpenSSH). Dieser Dienst ist zur Zeit auch von aussen, also übers Inet erreichbar und dies würde ich gerne unterbinden. Meine Milchmädchenrechnung á la

Code: Alles auswählen

$IPTABLES -A INPUT -i eth2 -m state --state NEW -p tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -i ppp0 -j DROP

hat leider nicht so recht funktioniert.
Wäre supi, wenn mir das jemand weiterhelfen könnte und dann würde mich interessieren, ob es sinnvoll ist privat und public Keys zu generieren (RSA / DSA ?) oder ob beim internen Zugriff der normale Passwortschutz reicht.

MFG

Tunx

[k-pl]

Wie faängst Du mit den Einträgen an? Verbiete erstmal alles:

Code: Alles auswählen

  iptables -P INPUT DROP
  iptables -P FORWARD DROP
  iptables -P OUTPUT DROP

Dann machst Du die Ports die Du brauchst wieder auf:

Code: Alles auswählen

iptables -A OUTPUT -o eth2 -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth2 -p TCP -m multiport --dport 22,80,443 -j ACCEPT

Jetzt darfst Du von eth2 auf Port 22,80 und 443 zugreifen. Von und nach ppp0 geht überhaupt keine Verbindung. NAT ist auch nicht aktiv.

[De Kus]

nichts gegen eine firewall, wäre es nicht NOCH sicherer in der /etc/ssh/sshd.config die ListenAddress auf interne anschlüsse ähnlich zu setzen wie:

Code: Alles auswählen

ListenAddress 127.0.0.1
ListenAddress 192.168.0.4

[k-pl]

Als Ergänzung sicher nicht schlecht. Das schützt Dir halt deine übrigen Ports nicht.

[De Kus]

Für die Fernwartung benutze ich SSH (OpenSSH). Dieser Dienst ist zur Zeit auch von aussen, also übers Inet erreichbar und dies würde ich gerne unterbinden.

nichts gegen eine firewall

Firewall ist ja gut und schön, aber wenn einfach das ssh über ppp0 verbieten willt, ist das sicehr die bessere und elegantere lösung. da er scheints noch etwas unsicher mit seiner firewall ist, könnte ja ma passieren, dass er sie verconfiguriert und sie doch wieder was durchlässt. er kann es ja zusätzlich über die firewall nochmal abblocken, nach dem motto, doppelt hällt besser .

[k-pl]

Und ohne Firewall bleibt z.B. der telnet-Port auf, da er aus versehen den telnetd instaliert hat. Deshalb sage ich "als Ergänzung".

[De Kus]

ich sage ja nichts gegen die Firewall, un wenn man telnet auch weghaben will, kommentiert man es in der inetd.conf raus (glaub in /etc), dann is telnet überhaupt net geladen un wer auf ein nicht geladenes telnet zugreifen kann, der bekommt von mir den nobelpeis .

aber mein motto ist: warum ein brett vor das lochen nageln, wenn man das loch auch wegmachen kann?

[pdreker]

Erste Grundregel der Netzwerksicherung: "Verteidigung muss Tiefe haben" (das englische Original heisst "Defense in Depth"). Warum nur das Loch wegmachen, wenn man es ausserdem noch mit Stacheldraht und einer Alarmanlage ausstatten kann?

Beispiel: SSH nur mit PublicKey Crypto mit Trusted Keys und nur von bestimmten IPs auf bestimmten Netzwerkdevices in der sshd.conf, wobei die Regeln ausserdem noch von der Firewall durchgesetzt werden. (Okay, das ist die Paranoia Variante, aber die Idee kommt glaube ich rüber )

Niemals auf einzelne Sicherheitsmassnahmen vertrauen, denn das bedeutet, dass ein einzelner Fehler evtl. das gesamte Konzept aushebelt.

Patrick

[k-pl]

pdreker bringst auf den Punkt. So habe ich das gemeint.

[Tunx]

hi,
jetzt habe ich mich übers Wochenende doch etwas intensiver mit iptables auseinander gesetzt und die Firewall komplett neu auf deny-Basis aufgebaut. Brauchte zwar alles etwas länger aber sie macht nun einen weitaus vernünftigeren Eindruck als zuvor.
Der interne ssh Zugang ist jetzt per Regel nur fuer interne NICs möglich.
Für morgen steht dann noch eine Lehrstunde ssh auf dem Plan, damit zusätzlich noch keys angelegt werden .
Eine letzte Frage hätte ich jedoch noch, bei den bekannten "Firewall Online Scans" werden alle Ports bis 1024 zwar schon als "stealth" ausgewiesen, schon mal nicht schlecht, jedoch kann die IP der internen Clients ausgelesen werden. Wie kann ich das interne Netz noch zusätzlich schützen ?

MFG

Tunx

[pdreker]

Die IPs der internen Clients???? Das sollte mit Masquerading eigentlich unmöglich sein. Befindet sich Dein internes Netz im RFC1918 Space (192.168.0.0/24, 172.16-31.0.0/16 oder 10.0.0.0/8)?

Kannst Du 'mal ein Beispiel für so einen Online Scanner bringen URL)? Wenn ich den sehe, kann ich mir eher ein Bild machen, wie der das schaffen könnte, und entsprechend Tipps geben...

Am Rande: wenn so ein Scanner "stealth" sagt, meint er normalerweise, dass der Port gar nicht antwortet. Wenn man jetzt aber auf einen anderen Port connected, der von der Firewall nicht gefiltert ist, dann weiss man, dass da mit hoher Wahrscheinlichkeit ein Firewall am Werke ist. Normalerweise antworten Ports auf denen kein Programm läuft nämlich mit einem RST Paket (ReSeT, das berühmte "connection reset by peer" Paket) auf ein SYN (SYNchronize, Verbindungsaufbau). In Wirklichkeit ist das also nicht so stealth, wie man sich das vorstellt... Trotzdem ist DENY besser als REJECT, weil man damit Deine Firewall nicht zwingen kann Pakete zu versenden (IMNSHO).

Patrick