Unitymedia KabelBW-Modem + FritzBox: Ports werden nicht geöffnet

[Momro]

Hallo zusammen,

ich habe ein KabelBW-Modem (Arris Touchstone TM602B) und dahinter eine FritzBox 3272 für das Netzwerk. Daran hängen mehrere PCs, Notebooks, Konsolen etc. und ein Raspberry Pi. Auf dem Pi läuft unter anderem ProFTPD.

Nun habe ich in der FritzBox Port 321 (FTP im Pi) und 22 (SSH) geöffnet und auf den Raspberry Pi weitergeleitet, weil ich gerne von außen zugreifen möchte.

Hier die Config aus dem Pi/FTP:

# Server Information
ServerName "Pi-Kodi"
ServerType standalone
DeferWelcome off
DisplayLogin welcome.msg
DisplayChdir .message true
# Server Settings
Port 321
PassivePorts 49152 65534
MasqueradeAddress <mypublicIP>
TransferLog /var/log/proftpd/xferlog
SystemLog /networkshare/log/proftpd.log
# Prevent DoS attacks
MaxInstances 30
# Set the user and group that the server normally runs at.
User proftpd
Group nogroup
[...]

In der FritzBox habe ich schon einiges rumprobiert. In einer Anleitung von AVM stand, man solle einiges deaktivieren und überprüfen:

• Änderungen über UPnP nicht zulassen
• Es ist kein Dual Stack oder IPv6-Anschluss
• NetBIOS-Filter ist deaktiviert
• Kindersicherung ist aus :-D
• Der Pi sollte eigentlich keine Firewall auf den Ports haben. Von allen PCs aus kann ich korrekt zugreifen auf, sowohl auf FTP an Port 321 als auch SSH auf 22.

AVM hat mir bestätigt, dass meine Ports korrekt freigegeben sind, mir aber jeglichen weiteren Support versagt, weil es nicht ihr Problem sei. Im Kabelmodem kann man ja nun nicht wirklich was einstellen, sodass ich jetzt wirklich nicht mehr weiterweiß.

Falls es interessant sein sollte, noch einige Details zum Aufbau:

• PCs mit Windows 7 und Windows 8
• Statische Adressen in der FritzBox verteilt
• Pi lauscht auf 321 -> FTP und 22 -> SSH
• Pi-OS ist RaspBMC mit aktueller Kodi-Distribution
• FritzOS 06.20
• Pi ist über WLAN verbunden

Ich freue mich über jeden Ratschlag und bedanke mich schon im Voraus für eure Tipps!

Beste Grüße,
Achim

 

[tq1199]

[*]Der Pi sollte eigentlich keine Firewall auf den Ports haben. Von allen PCs aus kann ich korrekt zugreifen auf, sowohl auf FTP an Port 321 als auch SSH auf 22.[/list]

[*]Pi ist über WLAN verbunden[/list]
Achim

Wie greifst Du von außen (d. h. aus dem Internet) auf deinen Pi (Ports 22 und 321) zu? Wie sind auf deinem Pi, die Ausgaben von:

<i>
</i>ifconfig -a
arp -av
route -n
sudo iptables -nvx -L
sudo netstat -tulpen

?

 

[Momro]

Hallihallo,

danke für deine Antwort/Nachfrage!

Aus dem Internet habe ich mit WinSCP und PuTTY versucht zuzugreifen, bzw. einen Portscanner verwendet.

Nun zu den Log-Files.

1. arp:

Lore.fritz.box (192.168.0.101) at ac:22:0b:2c:9d:36 [ether] on wlan1
Nexus7.fritz.box (192.168.0.43) at 10:bf:48:f3:11:e9 [ether] on wlan1
Nexus9.fritz.box (192.168.0.44) at b4:ce:f6:08:d4:64 [ether] on wlan1
Lore.fritz.box (192.168.0.23) at 24:0a:64:1c:d5:ed [ether] on wlan1
Samsung-TV.fritz.box (192.168.0.62) at 8c:c8:cd:b0:6b:d1 [ether] on wlan1
Nexus5.fritz.box (192.168.0.41) at bc:f5:ac:f5:31:04 [ether] on wlan1
fritz.box (192.168.0.1) at 34:31:c4:33:48:f4 [ether] on wlan1
Jarvis.fritz.box (192.168.0.21) at 38:59:f9:26:79:85 [ether] on wlan1
Skynet.fritz.box (192.168.0.24) at e8:de:27:a6:32:d8 [ether] on wlan1
Entries: 9	Skipped: 0	Found: 9

2. ifconfig:

eth0 Link encap:Ethernet HWaddr b8:27:eb:5e:04:26 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:7878 errors:0 dropped:0 overruns:0 frame:0 TX packets:7878 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:571082 (557.6 KiB) TX bytes:571082 (557.6 KiB)
wlan1 Link encap:Ethernet HWaddr e8:de:27:15:2c:a2 inet addr:192.168.0.52 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::eade:27ff:fe15:2ca2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:253319 errors:0 dropped:643 overruns:0 frame:0 TX packets:64849 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:60489012 (57.6 MiB) TX bytes:17673765 (16.8 MiB)

3. iptables

Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 813660 813078716 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 468606 52274650 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 1640 385168 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 61020 packets, 14882838 bytes) pkts bytes target prot opt in out source destination

4. netstat:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:4713 0.0.0.0:* LISTEN 0 1726 473/pulseaudio
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 0 5403 1645/xinetd
tcp 0 0 0.0.0.0:1420 0.0.0.0:* LISTEN 1000 3640 760/kodi.bin
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1000 3587 760/kodi.bin
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 0 2362 720/cupsd
tcp 0 0 0.0.0.0:1978 0.0.0.0:* LISTEN 1000 3597 760/kodi.bin
tcp6 0 0 :::321 :::* LISTEN 104 367068 10004/proftpd: (acc
tcp6 0 0 ::1:9090 :::* LISTEN 1000 3800 760/kodi.bin
tcp6 0 0 :::80 :::* LISTEN 1000 3586 760/kodi.bin
tcp6 0 0 :::22 :::* LISTEN 0 5404 1645/xinetd
tcp6 0 0 :::631 :::* LISTEN 0 2363 720/cupsd
udp 0 0 0.0.0.0:9777 0.0.0.0:* 1000 3803 760/kodi.bin
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 395778 30792/dhclient
udp 0 0 0.0.0.0:1900 0.0.0.0:* 1000 3592 760/kodi.bin
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 2366 720/cupsd
udp 0 0 192.168.0.52:123 0.0.0.0:* 105 395900 6592/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 258866 6592/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 258859 6592/ntpd
udp 0 0 0.0.0.0:137 0.0.0.0:* 0 5402 1645/xinetd
udp 0 0 192.168.0.255:137 0.0.0.0:* 0 2804 1020/nmbd
udp 0 0 192.168.0.52:137 0.0.0.0:* 0 2803 1020/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 0 2784 1020/nmbd
udp 0 0 192.168.0.255:138 0.0.0.0:* 0 2806 1020/nmbd
udp 0 0 192.168.0.52:138 0.0.0.0:* 0 2805 1020/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 0 2801 1020/nmbd
udp 0 0 0.0.0.0:41877 0.0.0.0:* 102 4095 1541/avahi-daemon:
udp 0 0 0.0.0.0:44444 0.0.0.0:* 0 395765 30792/dhclient
udp 0 0 0.0.0.0:5353 0.0.0.0:* 102 4093 1541/avahi-daemon:
udp6 0 0 :::41987 :::* 0 395766 30792/dhclient
udp6 0 0 :::33293 :::* 102 4096 1541/avahi-daemon:
udp6 0 0 fe80::eade:27ff:fe1:123 :::* 105 395901 6592/ntpd
udp6 0 0 ::1:123 :::* 0 258868 6592/ntpd
udp6 0 0 :::123 :::* 0 258860 6592/ntpd
udp6 0 0 :::5353 :::* 102 4094 1541/avahi-daemon:

5. route:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1

Danke, dass du dir das alles durchliest Bin gespannt, ob dir etwas davon was sagt!

 

[tq1199]

Der Pi sollte eigentlich keine Firewall auf den Ports haben. Von allen PCs aus kann ich korrekt zugreifen auf, sowohl auf FTP an Port 321 als auch SSH auf 22

3. iptables

Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 813660 813078716 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 468606 52274650 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 1640 385168 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0

Bin gespannt, ob dir etwas davon was sagt!

Wer hat diese (3.) DROP-Regel (... siehe den counter dieser Regel) in der INPUT chain konfiguriert?

 

[Momro]

Öh, also ich war's nicht. Ich weiß nichtmal, was eine DROP-Regel sein soll :-/

Warum, was ist das? Muss ich die entfernen?

 

[tq1199]

Öh, also ich war's nicht.

War es dann evtl. dein kleiner Buder oder ist dein Pi gehackt worden? :zwinker: Wer hat dir den Pi eingerichtet/konfiguriert?

Ich weiß nicht mal, was eine DROP-Regel sein soll :-/

Dann solltest Du evtl. noch warten und deinen Pi noch nicht, als Server ins Internet stellen.

Warum, was ist das?

Das kann ein Script (oder gleichwertig) sein, denn aus der Ausgabe sieht man, dass die Regeln (... aber nicht die 1. state-Regel für RELATED- und ESTABLISHED-Verbindungen) acht mal aufgerufen worden sind ohne vorher die gerade noch aktiven Regeln (2 und 3) zu löschen (flush):

<i>
</i>813660 813078716 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 468606 52274650 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 1640 385168 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 0 0 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0

 

[Momro]

Na sowas. Außer mir hat niemand Zugriff auf den Pi, und die Einrichtung habe auch ich vorgenommen. Ich denke, ich werde am Wochenende mal die DROP-Regeln recherchieren.

Ansonsten ... Pi neu aufsetzen und nochmal versuchen? Oder hast du eine konkrete Idee, was ich machen sollte?

 

[tq1199]

Ansonsten ... Pi neu aufsetzen und nochmal versuchen? Oder hast du eine konkrete Idee, was ich machen sollte?

Wegen 2 iptables-Regeln muss man den Pi nicht neu aufsetzen. Welches Betriebssystem hast Du auf deinem Pi?

 

[Momro]

RaspBMC

Wegen Auto-Aktualisieren wahrscheinlich in der aktuellen Version.
"cat /scripts/upd_hist/build_info" sagt:

raspbmc-rls-1.0-hardfp-b20130208-u20150125

 

[tq1199]

RaspBMC
Wegen Auto-Aktualisieren wahrscheinlich in der aktuellen Version.

Nein, ... Du hast "den Knopf noch nicht gefunden", mit dem die Firewall deaktiviert wird. :zwinker: Poste mal die Ausgaben von:

<i>
</i>ls -la /etc/network/if-up.d/secure-rmc
sudo chmod 644 /etc/network/if-up.d/secure-rmc
ls -la /etc/network/if-up.d/secure-rmc

Evtl. ausführbar lassen und mit:

<i>
</i>sudo nano /etc/network/if-up.d/secure-rmc

vor einem evtl. "exit 0",

<i>
</i>/sbin/iptables --flush

eintragen und speichern. Ist aber erst nach einem reboot (oder gleichwertig wirksam), oder "sudo iptables --flush" manuell ausführen.

Oder wenn Du weiß was Du machst, kannst Du auch:

<i>
</i>service iptables status && sudo service iptables stop
sudo update-rc.d iptables disable
sudo iptables -nvx -L

probieren. Oder m. E. noch besser, dich einlesen und diese Firewall für deine speziellen Bedürfnisse anpassen/konfigurieren.

 

[Momro]

Hm, aber warum kann ich mich von intern mit dem Port verbinden und von extern nicht? Sollte das Port Forwarding nicht machen, dass es wie ein interner Zugriff "aussieht"?

Rückgabewerte:

pi@pi-kodi:~$ ls -la /etc/network/if-up.d/secure-rmc
-rwxr-xr-x 1 root root 2687 Sep 8 2013 /etc/network/if-up.d/secure-rmc
pi@pi-kodi:~$ sudo chmod 644 /etc/network/if-up.d/secure-rmc
pi@pi-kodi:~$ ls -la /etc/network/if-up.d/secure-rmc
-rw-r--r-- 1 root root 2687 Sep 8 2013 /etc/network/if-up.d/secure-rmc

In

sudo nano /etc/network/if-up.d/secure-rmc

hab ich gar kein 'exit 0' gefunden. Ein 'exit'-Statement scheint es nur in get_subnet() und in der letzten if-Schleife zu geben, beide sind aber 'exit 0'.

Ist ja alles sehr verworren. Ich kenne mich ja eigentlich mit Firewalls aus, aber nur auf GUI-Ebene und nicht mit den internen Mechanismen von Linux. Da wüsste ich gar nicht, wo ich anfangen sollte. Um nochmal auf meinen Anfang zurückzukommen: Warum sollte es von intern funktionieren, von extern aber nicht? Scheint mir eigentlich erstmal das gleiche zu sein ...

 

[tq1199]

... hab ich gar kein 'exit 0' gefunden.

Ja, und deshalb hatte ich (in meinem Beitrag) ja auch "evtl." geschrieben:

... vor einem evtl. "exit 0",

Um nochmal auf meinen Anfang zurückzukommen: Warum sollte es von intern funktionieren, von extern aber nicht? Scheint mir eigentlich erstmal das gleiche zu sein ...

Ist es aber nicht:

<i>
</i>468606 52274650 ACCEPT all -- wlan1 * 192.168.0.0/24 0.0.0.0/0 1640 385168 DROP all -- wlan1 * 0.0.0.0/0 0.0.0.0/0

Du hast eine ACCEPT-Regel, die Alles was aus dem Subnet 192.168.0.0/24 über das input-Interface wlan1 kommt, durchlässt und danach hast Du einen DROP-Regel die Alles (source-net 0.0.0.0/0) was über das input-Interface wlan1 kommt, blockt. Der counter der DROP-Regel (1640 385168) zeigt, dass durch diese Regel auch geblockt wird. Das hat mit der Portweiterleitung nichts zu tun, denn dein Pi weiß trotz Portweiterleitung, wann die Anfragen aus dem Subnet 192.168.0.0/24 kommen und wann das nicht der Fall ist.

EDIT:

BTW: Versuch mal (temporär) im Terminal/Konsole deines Pi, Folgendes:

<i>
</i>sudo iptables -F && sudo iptables -X

und greife danach von außen auf deinen Pi zu.

 

[Momro]

Jetzt geht's :-D Vielen, vielen Dank!

Da weiß ich ja jetzt, worüber ich mich etwas mehr informieren muss

Soll ich da jetzt wieder was einstellen bzgl. DROP-Regeln, oder passt das so? - Weil du geschrieben hattest, ich solle die Chains temporär löschen ...

 

[tq1199]

- Weil du geschrieben hattest, ich solle die Chains temporär löschen ...

Ich habe "temporär" geschrieben, weil Du so und jetzt, den durch die standard-Konfiguration deines OS beabsichtigten Schutz nicht (mehr) hast. ... und btw., das was Du jetzt manuell gemacht hast (d. h. "sudo iptables -F && sudo iptables -X") ist nur bis zum nächsten reboot deines Pi wirksam.

 

[Momro]

Verstehe, verstehe. Ja, dann lese ich mich, wie gesagt, mal ein und schaue, dass ich das wieder richtig in den Griff bekomme. Vielen Dank nochmal!