Forum: PC Hard- und Software Problem mit iptables -> Experte gesucht


von iptabler (Gast)


Angehängte Dateien:

Lesenswert?

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?

von devzero (Gast)


Lesenswert?

Portscan auf welche Adresse? localhost? ipv4? ipv6? Welche Ports?

von iptabler (Gast)


Lesenswert?

Von extern auf alle Ports.

von c.m. (Gast)


Lesenswert?

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.

von iptabler (Gast)


Lesenswert?

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

von c.m. (Gast)


Lesenswert?

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.

von iptabler (Gast)


Lesenswert?

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

von T.roll (Gast)


Lesenswert?

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.

von devzero (Gast)


Lesenswert?

Er sagt doch, das alles durchkommt..

von Sven L. (sven_rvbg)


Lesenswert?

T.roll schrieb:
> * Über einen Router? Dann hat der sehr wahrscheinlich eine Firewall die
> dazwischen funkt.

Eher eine NAT-Instanz?

von T.roll (Gast)


Lesenswert?

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.

von René H. (Firma: anonymous) (hb9frh)


Lesenswert?

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.

von T.roll (Gast)


Lesenswert?

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.

von devzero (Gast)


Lesenswert?

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.

von devzero (Gast)


Lesenswert?

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..

von K. L. (trollen) Benutzerseite


Lesenswert?

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")

von iptabler (Gast)


Angehängte Dateien:

Lesenswert?

Bitteschön.

Anbei ein Screenshot meines Portscanns.
RPI hängt per Eth0 am Router.

Ich hänge mim Läppi im Wlan vom Router.

von Jack V. (jackv)


Lesenswert?

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“.

von Sven L. (sven_rvbg)


Lesenswert?

iptabler schrieb:
> /sbin/iptables-restore /etc/network/iptables

Muss das nicht

/sbin/iptables-restore < /etc/network/iptables

heissen?

von K. L. (trollen) Benutzerseite


Lesenswert?

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?

von iptabler (Gast)


Lesenswert?

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!)

von Sven L. (sven_rvbg)


Lesenswert?

was zeigt deinn iptables -L an?

von Sascha H. (salat)


Lesenswert?

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
Noch kein Account? Hier anmelden.