Hallo Leute, Ich möchte meine RPI3 ein wenig sicherer gegenüber dem bösen Internet machen. Daher habe ich mir die IP Table im Anhang abgetippt. Ich führe die sh file aus und starte danach die sh file, bei jedem startup. Dazu habe ich folgende Befehle ausgeführt: sudo touch /etc/network/if-pre-up.d/iptables sudo chmod +x /etc/network/if-pre-up.d/iptables sudo nano /etc/network/if-pre-up.d/iptables Die Datei beiinhaltet folgendes: #!/bin/sh /sbin/iptables-restore /etc/network/iptables AAABER: Mache ich einen Portscan, werden noch alle Ports angezeigt :-O Wie kann ich Diesem entgegenwirken?
Portscan auf welche Adresse? localhost? ipv4? ipv6? Welche Ports?
Nur kurz überflogen, aber ich schätze du willst DROP anstatt REJECT. Drop ist aber böse für harmlose Clients, also wenn das Ding nicht direkt am Internet hängt (alle Ports von aussen erreichbar), dann solltest du bei reject bleiben.
Habe es jetzt so probiert: # reject incomming connections if ports are not opened iptables -A INPUT -p udp -m recent --set --rsource --name UDP-PORTSCAN -j DROP --reject-with icmp-port-unreachable iptables -A INPUT -p udp -j DROP --reject-with icmp-port-unreachable iptables -A INPUT -p tcp -j DROP --reject-with tcp-reset ip6tables -A INPUT -p udp -j DROP --reject-with icmp6-port-unreachable ip6tables -A INPUT -p tcp -j DROP --reject-with tcp-reset iptables -A INPUT -j DROP --reject-with icmp-proto-unreachable ip6tables -A INPUT -j DROP Aber auch nicht erfolgreich :-O
1 | -j DROP --reject-with tcp-reset |
Das passt auch nicht zusammen. Entweder du DROPst Pakete, oder du antwortest dem Client mit einem reject+reset.
Wie gesagt. Habe ich abgetippselt und wollte es um eine PortScan Option erweitern. Leider bin ich dafür zu schwach auf der Brust :-/ Wer kann mir sagen, was ich ändern/ergänzen muss
Wie hängt denn dein RPi im Netz? * Direkt? Wohl eher nicht. * Über einen Router? Dann hat der sehr wahrscheinlich eine Firewall die dazwischen funkt. Starte mal auf dem RPi "sudo tcpdump", starte dann den Portscan und schau ob überhaupt irgendwas ankommt.
T.roll schrieb: > * Über einen Router? Dann hat der sehr wahrscheinlich eine Firewall die > dazwischen funkt. Eher eine NAT-Instanz?
devzero schrieb: > Er sagt doch, das alles durchkommt.. Nein. Siehe → iptabler schrieb: > Mache ich einen Portscan, werden noch alle Ports angezeigt :-O Das kann so gut wie alles bedeuten. Weder weiß man, mit welchem Programm scannt, noch was hier beim Scan wirklich antwortet.
Sven L. schrieb: > T.roll schrieb: >> * Über einen Router? Dann hat der sehr wahrscheinlich eine Firewall die >> dazwischen funkt. > > Eher eine NAT-Instanz? Firewall und Nating schliessen sich gegenseitig nicht aus.
Sven L. schrieb: > Eher eine NAT-Instanz? Gut möglich. Der RPi hängt sicher bei ihm im Heimnetz mit einem 0815-Router als Internetzugang.
Wie er scannt wurde ja nicht vernuenftig beantwortet - Antwort von extern auf alle Ports. Was auch immer das genau bedeutet. Oder von einem Rechner aus dem LAN auf den LAN Port? Da sollten die Regeln ziehen und die Fritzbox oder was auch sonst noch so gibt keinen Einfluss haben.
T.roll schrieb: > devzero schrieb: >> Er sagt doch, das alles durchkommt.. > > Nein. > > Siehe → > > iptabler schrieb: >> Mache ich einen Portscan, werden noch alle Ports angezeigt :-O > > Das kann so gut wie alles bedeuten. Weder weiß man, mit welchem Programm > scannt, noch was hier beim Scan wirklich antwortet. Hae? Er schreibt die Ports sind noch zu sehen und Du empfiehlst tcpdump mit den Worten ob ueberhaupt was durchkommt..
devzero schrieb: > Er schreibt die Ports sind noch zu sehen und Du empfiehlst tcpdump > mit den Worten ob ueberhaupt was durchkommt.. Ja welche Ports! Die vom RPi? Die vom Router davor? Wenn er seine externe IP scannt, dann bleibt der Portscan zu 99,9% im Router hängen. Mit tcpdump auf dem RPi sieht er, ob er den mit dem Portscan überhaupt erreicht. (T.roll nun angemeldet wegen Spamsperre "3 Beiträge pro Stunde")
Bitteschön. Anbei ein Screenshot meines Portscanns. RPI hängt per Eth0 am Router. Ich hänge mim Läppi im Wlan vom Router.
TE soll mal schreiben, was er zum Portscan eingibt, und was genau ausgegeben wird. Möglicherweise ist’s einer dieser überraschend häufig auftretenden Fehler der Art „Portscanner falsch bedient“, oder einer Unterart davon, nämlich „Ausgabe falsch interpretiert“.
iptabler schrieb: > /sbin/iptables-restore /etc/network/iptables Muss das nicht /sbin/iptables-restore < /etc/network/iptables heissen?
iptabler schrieb: > Bitteschön. Warum schreibst du oben "extern" wenn du nur im internen LAN bist? Die Ports gehören zu einem Mailserver. Aber unten kann er sich nicht zum Mailserver verbinden. Ich glaub daher, dass der Portscanner hier Mist baut. Hast du einen Mailserver auf dem RPi laufen?
Ich meine "extern" vom RPI aus gesehen. Habe nochmals geportscannt. Und siehe da: Port 5020 wird auch angezeigt. Das Port 5020 ist definitiv mein SSH Port. (JA, ich habe es geändert!)
Geraten, nicht getestet: > # set TCP_IN and UDP_IN chain as INPUT chain > iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP_IN Du stopfst neue TCP Pakete aus INPUT also in die Chain TCP_IN versuchst dann aber in INPUT statt TCP_IN zu filtern: > iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset Evtl. liegt es daran?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.