Portscans mit PF vermeiden: Welche TCP Flags?

Vektoren

Member
Hallo liebe BSD-Gemeinde :)

Einer meiner FreeBSD 10.1-Server wird immer mal wieder für Portscans missbraucht :rolleyes: Scheinbar lassen sich diese Angriffe nicht 100% ausschließen aufgrund der Funktionsweise von TCP/UDP...

Anyway: Ich habe jetzt, zusätzlich zu meinen bisherigen Vorkehrungen, einige weitere Regeln für PF gefunden, die es nmap und Co. weiter erschweren sollen. Allerdings basieren diese auf TCP-Flags und ich bin ich in dieser Hinsicht nicht ganz sicher, welche Auswirkungen diese genau haben. Daher möchte ich sie nicht wahllos aktivieren ;) Zudem sich verschiedene Quellen bezüglich ihrer "Anti-nmap-Regeln" zum Teil wiedersprechen:

Quelle 1:
Code:
set block-policy return
block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF

Quelle 2:
Code:
set block-policy return
set fingerprints "/etc/pf.os"
block in log quick on $ext_if os NMAP
block in log quick on $ext_if inet proto tcp from any to any flags FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags /SFRA

Ist eine der beiden Varianten vorzuziehen? Warum unterscheiden die beiden sich so stark bezüglich der Flags? Kann mir einer von euch erklären, was genau diese Angaben machen um die Unterschiede zu verstehen?

Ich möchte nur vermeiden, dass mein Server nach Aktivierung der Regeln nicht mehr erreichbar ist ;)

Dankeschön :)


Viele Grüße,
Thorsten
 
hi


du kannst keine portscans verhinder das sie ja von aussen kommen .

es macht auch keinen sinn tcp/udp flgs im block zu setzen da sie ja fuer den verbindungsaufbau gebracht werden und die session selbst beeinflussen.

einzigist dern fingerprint block fuer namp mancht sinn-

ich persoenlich setzte meine return policy auf reject statt deny ...... und gut ist. ( was mittlerweile bei openbsd 5.6 default ist )


holger
 
Auch wenn es offensichtlich ist aber, wird jetzt dein Server für Portscanns benutzt oder wird dein Server gescannt?
Immerhin schriebst du [...]Einer meiner FreeBSD 10.1-Server wird immer mal wieder für Portscans missbraucht[...] was mich ein wenig verwirrt.

Das Server gescannt werden ist m.M.n. ganz normales Hintergrundrauschen im Netz (leider) und solange das nicht zu viel Bandbreite einnimmt/Traffic produziert, sehe ich kein wirklichen Handlungsbedarf.
Vorausgesetzt, dass der Server/die Dienste uptodate ist/sind *sollte selbst verständlich sein* und weitere Sicherheitsmaßnahmen ergriffen wurden (sshd: public key authentication etc.).
 
natürlich haben mark05 und gadean vollkommen recht. Scans sind tatsächlich etwas derart normales dass man es als Hintergrundrauschen bezeichnen kann.
Wenn sich jemand mit dem Blocken der Scans sicherer 'fühlt', kann er ja eine Art Trap bauen. Ein typischer Port der auf dem Zielsystem nicht produktiv benutzt wird, z.B. TCP/22. Dort läuft kein echter sshd, sondern nur ein Daemon der verifiziert dass die Quell-IP nicht gefaked ist, und dann selbige in eine Tabelle für die pf Blocklist einfügt...
 
Zurück
Oben