Hallo reale und virtuelle Persönlichkeiten
Mich beschäftigt folgendes Problem: auf einem älteren Rechner läuft Debian woody als DSL-Router. Ich habe ein selbstgeschriebenes iptablesscript, das mich ein wenig vor der Welt hinter ppp0 schützt. nmap mit meiner dyndns.org adresse aufgerufen liefert mir aber offene ports unter anderem ssh. Es ist auch möglich mich mit ssh "name.dyndns.org" einzuloggen. Als ich dann mit poff -a die DSL Verbindung trennte blieb auch ssh hängen.
Ein who ergab eine Anmeldung (localhost). Ein who, wenn ich mich direct über das LAN anmelde (ssh auf private IP im LAN) ergab auch das normale (ip-adresse).
Ein Scan von einer dieser Webseiten mit portscanner ergab keine offenen ports (ports 1-100 getestet).
Irgendwie scheint er zu erkennen, daß ich aus dem LAN komme. Bin ein wenig verwirrt darüber. Vielleicht ist hier ja der richtige Ort um ein wenig zu diskutieren.
Vielen Dank schonmal.
seltsames verhalten von offenen ports nach ppp0
- mistersixt
- Beiträge: 6601
- Registriert: 24.09.2003 14:33:25
- Lizenz eigener Beiträge: GNU Free Documentation License
Schau mal hier:
http://www.auditmypc.com/
oder auch hier:
http://www.dslreports.com/scan
Da kann man seine IP mal scannen lassen - von "aussen" natürlich. Ist dann ssh immer noch offen?
Gruss, mistersixt
http://www.auditmypc.com/
oder auch hier:
http://www.dslreports.com/scan
Da kann man seine IP mal scannen lassen - von "aussen" natürlich. Ist dann ssh immer noch offen?
Gruss, mistersixt
> Da kann man seine IP mal scannen lassen - von "aussen" natürlich.
> Ist dann ssh immer noch offen?
Habe ich vielleicht unglücklich geschrieben. habe ich schon und jetzt wieder gemacht. keine offenen ports von außen zu sehen.
ein nmap auf die IP von ppp0 (allerdings aus dem lokalen netz):
PORT STATE SERVICE
9/tcp open discard
13/tcp open daytime
22/tcp open ssh
25/tcp open smtp
37/tcp open time
irgendwie muß es ja einen unterschied geben zwischen "von außen" und "aus dem lokalen netz auf die externe ip von ppp0".
Die Lösung ist wahrscheinlich: Mein Router sieht einen Ping (oder scan) vom lokalen Netz auf die externe IP. Noch bevor NAT gemacht wird, wird das wohl beantwortet. Sonst würde er die Anfrage ja als von "außen" ansehen. Ich dachte immer, da meine externe IP von ppp0 ja nicht von meinem lokalen Netz erreicht werden kann, er die Anfrage (ping oder scan) erst mal durch NAT läuft.
> Ist dann ssh immer noch offen?
Habe ich vielleicht unglücklich geschrieben. habe ich schon und jetzt wieder gemacht. keine offenen ports von außen zu sehen.
ein nmap auf die IP von ppp0 (allerdings aus dem lokalen netz):
PORT STATE SERVICE
9/tcp open discard
13/tcp open daytime
22/tcp open ssh
25/tcp open smtp
37/tcp open time
irgendwie muß es ja einen unterschied geben zwischen "von außen" und "aus dem lokalen netz auf die externe ip von ppp0".
Die Lösung ist wahrscheinlich: Mein Router sieht einen Ping (oder scan) vom lokalen Netz auf die externe IP. Noch bevor NAT gemacht wird, wird das wohl beantwortet. Sonst würde er die Anfrage ja als von "außen" ansehen. Ich dachte immer, da meine externe IP von ppp0 ja nicht von meinem lokalen Netz erreicht werden kann, er die Anfrage (ping oder scan) erst mal durch NAT läuft.
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
nmap aus dem lokalen Netz geht immer über das lokale Netz, und damit nicht durch die Firewall Regeln für das externe Netz. So funktioniert das mit dem Netzwerk Routing halt (Wenigstens bei Ethernet / IP). Die externe IP Deines ppp0 ist auch intern sichtbar: Der Kernel auf dem Router bekommt ein Paket mit der Destination Adresse 123.123.123.123. Er schaut dann in seine Routing Tabelle, was er mit einem Paket für diese IP machen muss, und stellt fest, dass die IP zu seinem eigenen ppp0 Interface gehört. Damit ist die Routing Entscheidung gefallen: Das Paket ist für die lokale Maschine bestimmt und durchläuft den Netzwerkstack, auch wenn sie nicht über das eigentliche ppp0 Interface hereingekommen ist...
Der Unterschied zwischen von innen auf die externe IP und von aussen ist also das "inbound interface" also das Netzwerkinterface, über das das Paket hineingekommen ist. Firewalls von innen testen ist unabhängig von der verwendeten IP immer ein Test "von innen".
Klärt das Deine Frage?
Patrick
Der Unterschied zwischen von innen auf die externe IP und von aussen ist also das "inbound interface" also das Netzwerkinterface, über das das Paket hineingekommen ist. Firewalls von innen testen ist unabhängig von der verwendeten IP immer ein Test "von innen".
Klärt das Deine Frage?
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
ja, danke.
Ich vermute mal, der ssh-login ist deswegen hängengeblieben weil die externe ip von ppp0 nicht mehr da war. Nicht wie ich vorher gedacht habe, die Verbindung getrennt wurde.
was mir noch nicht klar ist, bei einem "who" wird unter fast allen arten des ssh-logins (auf externe ip oder auf die lokale LAN-IP) nur ein (localhost) angegeben. Sollte da nicht die IP von der der login herkommt stehen?
Lars
Ich vermute mal, der ssh-login ist deswegen hängengeblieben weil die externe ip von ppp0 nicht mehr da war. Nicht wie ich vorher gedacht habe, die Verbindung getrennt wurde.
was mir noch nicht klar ist, bei einem "who" wird unter fast allen arten des ssh-logins (auf externe ip oder auf die lokale LAN-IP) nur ein (localhost) angegeben. Sollte da nicht die IP von der der login herkommt stehen?
Lars