Page 1 of 1

SSH-Zugriff mit Dynamischem DNS-Alias und Logging-Problem

Posted: 20. Sep 2006 17:34
by Cougar
Servus

ich hoff mal, dass der Beitrag hierhin gehört und nich ins allgemeine Netzwerk Forum.

Habe das rc.firewall Skript von http://www.router-piewie.de.tf verwendet und an meine Bedürfnisse angepasst. Funktioniert soweit auch alles gut bis auf den SSH-Zugriff vom internen Netz (habe im Skript die IPs und das Netzwerkinterface geändert, wie es eben bei mir sein muss).
Zudem möchte ich noch einen SSH-Zugriff von extern, der allerdings nur von einer bestimmten Adresse "irgendwas.dyndns.org" zulässig ist. Ich erhoffe mir dadurch, erhöhte Sicherheit und da ich mit meinem Notebook unterwegs ja nicht garantieren kann, immer dieselbe IP zu haben, hatte ich die Idee mit dem DynDNS-Alias. Weiterhin sind Wartungsarbeiten oder sonstiges im laufenden Betrieb unmöglich, da die Firewall alle möglichen Meldungen auf der Console ausgibt. Ich möchte die Meldungen zwar im Logfile haben aber nicht andauernd auf dem Bildschirm ausgegeben. Oder halt zumindest nicht in der Console in der ich gerade arbeite.
Ich hoffe ihr könnt mir dabei jetzt irgendwie weiterhelfen, denn ich komm nicht mehr wirklich weiter und auch die Suchfunktion hat mir nicht unbedingt weitergeholfen.

cya

Posted: 20. Sep 2006 18:30
by Janka
Matching auf Hostnamen ist von Kernel-Seite aus nicht möglich. Wenn man beim iptables-Kommando einen Hostnamen angibt, wird dieser einmalig beim Aufruf des Kommandos aufgelöst.

Zudem ist diese Methode *unsicher* Wer garantiert dir, dass ein Angreifer nicht zuerst die DNS-Pakete manipuliert? Wenn du Sicherheit vor Skriptkiddies willst, leg' die SSH auf einen anderen als den Defaultport, oder verwende Portknocking.

Wo Logmeldungen erscheinen, kannst du in der Datei /etc/syslog-ng/syslog-ng.conf einstellen.

Janka

Posted: 21. Sep 2006 9:42
by Cougar
Damit wäre aber das Problem mit der dynamischen IP Adresse vom Notebook nicht gelöst. Deswegen kam mir die Idee mit dem dyndns Namen.

Das Hauptsächliche Problem ist momentan aber auch der SSH-Zugriff vom internen Netz. Das will ja auch nicht funktionieren.

Posted: 21. Sep 2006 10:29
by Janka
Cougar wrote:Damit wäre aber das Problem mit der dynamischen IP Adresse vom Notebook nicht gelöst. Deswegen kam mir die Idee mit dem dyndns Namen.
Wie ich schon sagte, das geht so nicht. Der Kernel kennt keine Hostnamen, das wird alles eine Ebene darüber (nämlich von libc) gelöst. Damit ist deine Idee, mit iptables nach einem DynDNS-Hostnamen zu filtern, hinfällig. Es sei denn, du schreibst ständig die Firewall-regeln um oder implementierst einen Paketfilter im Userspace.

Mir wäre das zu umständlich, zumal der Sicherheitsgewinn minimal ist.

Janka

Posted: 21. Sep 2006 17:10
by Cougar
Wo Logmeldungen erscheinen, kannst du in der Datei /etc/syslog-ng/syslog-ng.conf einstellen.
... diesen Ordner geschweige den die Datei darin kann ich auf meinem System nicht finden.

Ok. Auf Kernelebene lässt sich das nicht realisieren. Und alles andere zu umständlich. Welche Möglichkeiten hab ich aber dann aus dem Inet auf meinen Server zuzugreifen, wenn die FW so konfiguriert ist, dass nicht jeder darauf zugreifen kann sondern SSH Verbindungen nur von einer bestimmten Adresse (nämlich meiner die sich ja ständig ändert) möglich sind??

Und das Problem mit dem SSH-Zugriff aus dem internen Netz heraus besteht auch immernoch.

Trotzdem danke schonmal für die bisherigen Antworten. Vllt kannst du mir noch weiterhelfen.

cya

Posted: 21. Sep 2006 17:54
by Janka
Dann hast du vielleicht noch das alte syslog? Guck mal, ob es /etc/syslog.conf gibt.

Stell die Firewall so ein dass Verbindungen von jeder Adresse *möglich* sind. Punkt. Wenn du verhindern willst, dass dir die Skriptkiddies das Log vollmüllen, ändere die sshd-Konfiguration (/etc/ssh/sshd_config) dahingehend ab, dass er nicht mehr auf Port 22 lauscht, sondern auf einem anderen Port. Die Firewall ebenfalls so einstellen. (Bei der Gelegenheit kannst du übrigens auch SSHv1-Unterstützung ausstellen.)

Für deinen Test mit dem internen Netz stellst du die Firewall am besten erst einmal ab, um den Fehler einzugrenzen.

Janka