Linearer Modus

08.09.2015 10:07

Um besagten Angreifern klar zu machen, dass es dort nichts gibt auf dem jeweiligen Port. Sonst probieren die es später erneut (Paket ging ja verloren, eventuell ist das ielsystem ja nur ausgelastet).

Zumal Drop nicht RFC-Konform ist.

Zitat dazu aus dem Arch-Wiki: We use REJECT rather than DROP here, because RFC 1122 3.3.8 requires hosts return ICMP errors whenever possible, instead of dropping packets

Sehr gute Zusammenfassung: http://www.chiark.greenend.org.uk/~peter...-vs-reject

***DosAmp*** · 08.09.2015 10:15

(08.09.2015 09:54)mrshadowtux schrieb: Weil du sonst Timeouts verursachst. Das wirkt auf User verwirrend, da sie warten und warten und warten. Aus Sicht eines Angreifers sieht es dann so aus, als sei deine Kiste überlastet. Resultat kann dann sein, dass er es erneut probiert.

Auf einen Dienst, dessen Existenz Benutzern nicht vertraut sein muss, verbindet sich auch keiner. Und Angreifer sind im Internet ohnehin vollständig automatisiert (Portscans, Botnets), sie werden z. B. trotz allem fortfahren, deinen Server stumpf mit SSH-/RDP-Anfragen zu behämmern.
Es spricht nichts dagegen, Verbindungen von „feindlichen“ Clients zu droppen anstatt zurückzuweisen, da es sie im besten Falle wie beschrieben ausbremst. Das echte Internet hält sich auch nicht immer an deine gedruckten Regelwerke.

(08.09.2015 09:54)mrshadowtux schrieb: Besser ist hier Reject, was das Paket ebenso verwirft, ihm dann aber über ICMP unmissverständlich klar macht, dass er hier nicht weiter kommr ("Connection Refused", auch ein paar andere Fehler sind wählbar)

Du denkst jetzt an andere Protokolle wie UDP und die ICMP-Antwort Destination Unreachable bzw. Port Unreachable. Bei TCP würgt der Netzwerk-Stack den einkommenden Verbindungsversuch einfach per RST ab, außer man definiert in iptables explizit --reject-with icmp-port-unreachable. Das wäre dann aber bereits wieder deutlich unterscheidbares Verhalten zu einem gar nicht geöffneten Port.

08.09.2015 10:20

Die meisten Angreiferscripte gehen eben anders vor. Sie führen eine Art Blacklist mit IP/Port-Kombis wo sie nicht reinkamen (Da landet man dann bei nem Reject direkt). Bei anderen IP/Port-Kombis probieren sie weiter für zig mal, bevor sie aufgeben.

Standardmäßig nutzt iptables ein Port Unreachable. Man kann aber auch einen TCP Reset übers Reject senden. Das ist dann auch absolut regelkonform.

Die RFCs haben schon ihre Gründe, wer sagt die seien unnötig hat das Internet nicht so recht verstanden.

CHRiSNEW · 08.09.2015 10:51

(08.09.2015 10:20)mrshadowtux schrieb: Die meisten Angreiferscripte gehen eben anders vor. Sie führen eine Art Blacklist mit IP/Port-Kombis wo sie nicht reinkamen (Da landet man dann bei nem Reject direkt).

Naja, schön wär's. Ich sehe zu oft die gleichen Idioten mehrmals antanzen. Egal, was man antwortet.

***Alpha*** · 08.09.2015 10:54

(08.09.2015 10:51)CHRiSNEW schrieb:
(08.09.2015 10:20)mrshadowtux schrieb: Die meisten Angreiferscripte gehen eben anders vor. Sie führen eine Art Blacklist mit IP/Port-Kombis wo sie nicht reinkamen (Da landet man dann bei nem Reject direkt).

Naja, schön wär's. Ich sehe zu oft die gleichen Idioten mehrmals antanzen. Egal, was man antwortet.

Genau meine Erfahrung..

tk1908 · 12.09.2015 23:11

Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code:

root@beer:/home/tkoehler# ip route

default via 192.168.178.1 dev wlan0

10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1

10.24.0.0/16 via 10.0.0.2 dev eth0

172.16.1.0/24 via 10.0.0.2 dev eth0

192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22

root@beer:/home/tkoehler#

iptables:

Code:

root@beer:/home/tkoehler# iptables -L

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

ACCEPT     icmp --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

root@beer:/home/tkoehler#

echo Firewall wird gestartet.

# Erstmal die alten Regeln rauswerfen

iptables -F

iptables -X

# ...und Forwarding aktivieren

echo 1 > /proc/sys/net/ipv4/ip_forward

# Routing/NAT

iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE

# Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen)

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Eingehende Pings erlauben

iptables -A INPUT -p icmp -j ACCEPT

# Eingehendes ssh erlauben

iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT

# Eingehendes nfs erlauben

iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT

# Eingehendes dns erlauben

iptables -A INPUT -p udp -m --dport 53 -j ACCEPT

# Auf Loopback darf alles rein und raus

iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

 # Auf dem Quellinterface ist alles erlaubt

iptables -A INPUT -i $SOURCE -j ACCEPT

iptables -A OUTPUT -o $SOURCE -j ACCEPT

# Auf dem Zielinterface ist auch alles erlaubt

iptables -A INPUT -i $TARGET -j ACCEPT

iptables -A OUTPUT -o $TARGET -j ACCEPT

 # Policies setzen

 iptables -P INPUT DROP

NFS-Exports:

Code:

/data/save      10.24.0.0/16(rw,no_subtree_check)

/data/save      172.16.1.0/24(rw,no_subtree_check)

/data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900

/data/nfs/grml32 10.18.1.1/16(ro)

/data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

(12.09.2015 23:11)tk1908 schrieb: Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code:

root@beer:/home/tkoehler# ip route default via 192.168.178.1 dev wlan0 10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1 10.24.0.0/16 via 10.0.0.2 dev eth0 172.16.1.0/24 via 10.0.0.2 dev eth0 192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22 root@beer:/home/tkoehler#

iptables:

Code:

root@beer:/home/tkoehler# iptables -L Chain INPUT (policy DROP) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED ACCEPT     icmp --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere Chain FORWARD (policy ACCEPT) target     prot opt source               destination Chain OUTPUT (policy ACCEPT) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere root@beer:/home/tkoehler# echo Firewall wird gestartet. # Erstmal die alten Regeln rauswerfen iptables -F iptables -X # ...und Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Routing/NAT iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE # Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Eingehende Pings erlauben iptables -A INPUT -p icmp -j ACCEPT # Eingehendes ssh erlauben iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT # Eingehendes nfs erlauben iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT # Eingehendes dns erlauben iptables -A INPUT -p udp -m --dport 53 -j ACCEPT # Auf Loopback darf alles rein und raus iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Auf dem Quellinterface ist alles erlaubt iptables -A INPUT -i $SOURCE -j ACCEPT iptables -A OUTPUT -o $SOURCE -j ACCEPT # Auf dem Zielinterface ist auch alles erlaubt iptables -A INPUT -i $TARGET -j ACCEPT iptables -A OUTPUT -o $TARGET -j ACCEPT # Policies setzen iptables -P INPUT DROP

NFS-Exports:

Code:

/data/save      10.24.0.0/16(rw,no_subtree_check) /data/save      172.16.1.0/24(rw,no_subtree_check) /data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900 /data/nfs/grml32 10.18.1.1/16(ro) /data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

Kleiner EDIT:

Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"

tk1908 · 14.09.2015 13:28

(12.09.2015 23:11)tk1908 schrieb: Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code:

root@beer:/home/tkoehler# ip route default via 192.168.178.1 dev wlan0 10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1 10.24.0.0/16 via 10.0.0.2 dev eth0 172.16.1.0/24 via 10.0.0.2 dev eth0 192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22 root@beer:/home/tkoehler#

iptables:

Code:

root@beer:/home/tkoehler# iptables -L Chain INPUT (policy DROP) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED ACCEPT     icmp --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere Chain FORWARD (policy ACCEPT) target     prot opt source               destination Chain OUTPUT (policy ACCEPT) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere root@beer:/home/tkoehler# echo Firewall wird gestartet. # Erstmal die alten Regeln rauswerfen iptables -F iptables -X # ...und Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Routing/NAT iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE # Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Eingehende Pings erlauben iptables -A INPUT -p icmp -j ACCEPT # Eingehendes ssh erlauben iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT # Eingehendes nfs erlauben iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT # Eingehendes dns erlauben iptables -A INPUT -p udp -m --dport 53 -j ACCEPT # Auf Loopback darf alles rein und raus iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Auf dem Quellinterface ist alles erlaubt iptables -A INPUT -i $SOURCE -j ACCEPT iptables -A OUTPUT -o $SOURCE -j ACCEPT # Auf dem Zielinterface ist auch alles erlaubt iptables -A INPUT -i $TARGET -j ACCEPT iptables -A OUTPUT -o $TARGET -j ACCEPT # Policies setzen iptables -P INPUT DROP

NFS-Exports:

Code:

/data/save      10.24.0.0/16(rw,no_subtree_check) /data/save      172.16.1.0/24(rw,no_subtree_check) /data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900 /data/nfs/grml32 10.18.1.1/16(ro) /data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

(12.09.2015 23:11)tk1908 schrieb: Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code:

root@beer:/home/tkoehler# ip route default via 192.168.178.1 dev wlan0 10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1 10.24.0.0/16 via 10.0.0.2 dev eth0 172.16.1.0/24 via 10.0.0.2 dev eth0 192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22 root@beer:/home/tkoehler#

iptables:

Code:

root@beer:/home/tkoehler# iptables -L Chain INPUT (policy DROP) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED ACCEPT     icmp --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere Chain FORWARD (policy ACCEPT) target     prot opt source               destination Chain OUTPUT (policy ACCEPT) target     prot opt source               destination ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere ACCEPT     all  --  anywhere             anywhere root@beer:/home/tkoehler# echo Firewall wird gestartet. # Erstmal die alten Regeln rauswerfen iptables -F iptables -X # ...und Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Routing/NAT iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE # Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Eingehende Pings erlauben iptables -A INPUT -p icmp -j ACCEPT # Eingehendes ssh erlauben iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT # Eingehendes nfs erlauben iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT # Eingehendes dns erlauben iptables -A INPUT -p udp -m --dport 53 -j ACCEPT # Auf Loopback darf alles rein und raus iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Auf dem Quellinterface ist alles erlaubt iptables -A INPUT -i $SOURCE -j ACCEPT iptables -A OUTPUT -o $SOURCE -j ACCEPT # Auf dem Zielinterface ist auch alles erlaubt iptables -A INPUT -i $TARGET -j ACCEPT iptables -A OUTPUT -o $TARGET -j ACCEPT # Policies setzen iptables -P INPUT DROP

NFS-Exports:

Code:

/data/save      10.24.0.0/16(rw,no_subtree_check) /data/save      172.16.1.0/24(rw,no_subtree_check) /data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900 /data/nfs/grml32 10.18.1.1/16(ro) /data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

Kleiner EDIT:

Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"

Keiner ne Idee?

CHRiSNEW · 14.09.2015 13:35

Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.

tk1908 · 14.09.2015 13:41

(14.09.2015 13:35)CHRiSNEW schrieb: Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.

Rein von der Logik müsste 10.0.0.2 ankommen. Ich sniffe heute Abend mal den Traffic mit tcpdump.

CHRiSNEW · 14.09.2015 14:57

Wenn der von 10.0.0.2 ankommt, dann ist das klar, dass ein Access Denied fliegt.

Du müsstest noch

Code:

/data/save      10.0.0.2/32(rw,no_subtree_check)

hinzufügen