• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Blocken einer IP mit pf.... :(

[KB]

Well-Known Member
Themenstarter #1
Hallo,

ich bin gerade am Verzweifeln.
Aktuell kämpfe ich an meinem Server mit massiven Scan-Attacken und versuche bestimmten IP-Adressen per pf den Zugang zu verweigern. Eine Adresse (hier die 172.245.177.162) scheint sich aber massiv zu weigern, sich an der Aussperrung zu halten.

Hier ein Auszug aus den Versuchen mit /etc/pf.conf:

#------------------------------------------------------------------------
ext_if_lan = "em0"

# Private Netzwerke
ext_priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

# Any host or range listed in this macro will be blocked.
badguys="{ 172.245.177.162 }"

# Regeln
#-------------------------------------------------------------------------

# Keine Rückmeldung bei Blockierungen
set block-policy drop

# Normalisierung
scrub in all

# Standardmäßig alles verbieten
#
block drop in log all
block drop out log all

# Wir wollen kein IPv6.0
block quick inet6

# über Loopback alles durchlassen
pass quick on lo0 all

# Blockiere den externen Verkehr mit privaten Adressen
block drop in log on $ext_if_lan from $ext_priv_nets to any
block drop out log on $ext_if_lan from any to $ext_priv_nets

# With logging ( chews up CPU during dDoS )
# block in log quick on $ext_if_lan from $badguys

# Without logging
block in quick on $ext_if_lan from $badguys

# sperre eine IP temporär
block drop in log quick on $ext_if_lan from 208.77.156.165 to any
block drop out log quick on $ext_if_lan from 208.77.156.165 to any
block drop in log quick on $ext_if_lan from 195.154.128.174 to any
block drop out log quick on $ext_if_lan from 195.154.128.174 to any
block drop in log quick on $ext_if_lan from 198.46.141.122 to any
block drop out log quick on $ext_if_lan from 198.46.141.122 to any
block drop in log quick on $ext_if_lan from 198.12.76.172 to any
block drop out log quick on $ext_if_lan from 198.12.76.172 to any
block drop in log quick on $ext_if_lan from 216.246.49.0/24 to any
block drop out log quick on $ext_if_lan from 216.246.49.0/24 to any
block drop in log quick on $ext_if_lan from 172.245.0.0/16 to any
block drop out log quick on $ext_if_lan from 172.245.0.0/16 to any

block drop in log quick on $ext_if_lan from 173.252.100.0/24 to any
block drop out log quick on $ext_if_lan from 173.252.100.0/24 to any​

...

pass ...
...
pass in log on $ext_if_lan proto tcp from any to ($ext_if_lan) port http flags S/SA synproxy state (max 200, source-track rule, max-src-nodes 100, max-src-states 3)
...
Wie man sieht versuche ich hier auf zwei Wegen die entsprechende IP daran zu hindern, meinen Server lahm zu legen. Das Ergebnis: Hier mal einen Auszug nach Aufruf von "netstat -l -finet -n":

Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 xx.xx.xx.xx.80 172.245.177.162.37588 SYN_RCVD
tcp4 0 0 xx.xx.xx.xx.80 172.245.177.162.37313 LAST_ACK
tcp4 0 0 xx.xx.xx.xx.80 172.245.177.162.37162 CLOSE_WAIT
tcp4 0 0 xx.xx.xx.xx.80 172.245.177.162.37022 CLOSE_WAIT
tcp4 0 558 xx.xx.xx.xx.80 172.245.177.162.36538 LAST_ACK​

Wie bekomme ich diese Flut an Request gestoppt bzw. wie muss ich meine pf.conf anpassen?
Könnte es an meiner pass ... http - Regel liegen?

Ich bin im Moment für jeden Hinweis dankbar...

Viele Grüße,
[KB]
 

[KB]

Well-Known Member
Themenstarter #2
Fehler gefunden!

Bin in eine kleine Falle getappt. Die Wartungsarbeiten erfolgen remote via SSH. Da der Befehl 'service pf restart' ständig die SSH-Verbindung beendete, versuchte ich den Restart von pf mit Hilfe des Befehls 'pfctl -d && pfctl -e'. Und diese Befehlsfolge führte scheinbar nicht zum Neuladen der Filter-Rules. Erst wenn man 'pfctl -e -f /etc/pf.conf' aufruft, werden die Filter-Rules neugeladen. Hat aber auch den Effekt, dass die SSH-Verbindung wieder abgebrochen wird. Dann kann man auch gleich wieder mit dem service-Befehl arbeiten. :)

Ich hoffe dieser Beitrag hilft anderen beim Verlassen des selben Denkfehlers. :)

Viele Grüße,
[KB]
 

gadean

Well-Known Member
#3
Wenn pf schon gestartet ist sollte 'pfctl -f /etc/pf.conf' reichen und dabei trennt er mir nicht die SSH-Session.
 
#4
Noch besser ist -m zu nehmen. Das lässt States in Ruhe. Allerdings muss man beachten, dass ein Angreifer States evtl. produziert hat.
 

foxit

Moderator
Mitarbeiter
#5
Hallo,

Irgendwie sind deine Regel sehr komisch. Ich verstehe folgendes nicht:
Code:
block drop in log all

# sperre eine IP temporär
block drop in  log quick on $ext_if_lan from 208.77.156.165 to any
Du blockierst alles was von aussen kommt mit der ersten Regel. Warum brauchst du noch die Zweite?

Weiter kenne ich das hier nicht so:
Code:
pass quick on lo0 all
Ich schreibe hier immer:
Code:
set skip on lo0
Gruss
 
#6
Fehler gefunden!

Bin in eine kleine Falle getappt. Die Wartungsarbeiten erfolgen remote via SSH. Da der Befehl 'service pf restart' ständig die SSH-Verbindung beendete, versuchte ich den Restart von pf mit Hilfe des Befehls 'pfctl -d && pfctl -e'. Und diese Befehlsfolge führte scheinbar nicht zum Neuladen der Filter-Rules. Erst wenn man 'pfctl -e -f /etc/pf.conf' aufruft, werden die Filter-Rules neugeladen. Hat aber auch den Effekt, dass die SSH-Verbindung wieder abgebrochen wird. Dann kann man auch gleich wieder mit dem service-Befehl arbeiten. :)

Ich hoffe dieser Beitrag hilft anderen beim Verlassen des selben Denkfehlers. :)

Viele Grüße,
[KB]
Es gibt für das pf rc Skript zumindest auf FreeBSD auch einen reload Parameter.
Code:
service pf reload
Lädt dir die Regeln neu, und wendet sie an, wirft dich aber nicht aus deiner SSH Session.
 

TCM

Well-Known Member
#7
Hallo,

Irgendwie sind deine Regel sehr komisch. Ich verstehe folgendes nicht:

Du blockierst alles was von aussen kommt mit der ersten Regel. Warum brauchst du noch die Zweite?
Weil er quick- und non-quick-Regeln mischt. Der erste Block ohne quick kann durch ein pass unten wieder aufgehoben werden. Dagegen sind wohl anscheinend die quick Blocks.

Ein sehr konfuses Ruleset.

Schon die Bezeichnung $ext_if_lan lässt mich kopfkratzen.
 

mark05

Well-Known Member
#8
wieso ist block drop $badguys auskommentiert ?

warum nicht alle ip die gedopt werden sollen , in eine tabelle die man dann von ussen
weiter befüllen kann ohne das regelwerk neu zuladen.

pfctl -t baddguys -Tadd boese_ip
holger