openBSD: Paketfilter einrichten mit pf - wie sichere ich meinen Server

overflow

Member of Honour
Glaube mein Betreff ist aussagekräftig genug:

Informationen über den Server
- Server liegt bei hosteurope (gemietet)

Welche Dienste biete ich an:
- Port 22 (ssh)
- Port 80 (apache)

Anbei meine Config:

Code:
intif="bnx0"
inet="xxx.xxx.xxx.xxx" 

set skip on lo

block in
pass out

pass in on $intif proto tcp from any to any port {80}
pass in proto tcp from any to self port 22
Ich werde natürlich die Ports für die o.g. Dienste verlegen.

Reichen diese Vorkehrungen um den Server halbwegs vor Angriffen zu schützen?
Oder muss ich soweit gehen und Pakete mit bestimmten TTL Werten verwerfen?
Sollte ich mich auch vor internen Angriffen (innerhalb des Hosteurope Servers schützen)?
 

bitmuncher

Moderator
Du solltest dich vor allem vor eingeschleusten Bots schützen, wenn da ein Webserver läuft, der auch dynamische (d.h. via serverseitigem Skript) generierte Inhalte ausliefert. Da macht es durchaus Sinn den ausgehenden Traffic auch nur für die Verbindungen des Web- und SSH-Servers zuzulassen und weitere nur bei Bedarf händisch freizuschalten, so dass ein evtl. eingeschleuster Bot gar nicht erst Kontakt zu seinem Meister aufnehmen kann. Ausserdem gibt's so ein paar Standard-Sachen, die jede Firewall auf einem Server nutzen sollte:

Code:
# drop unwanted stuff, don't reject
set block-policy drop
# kick the IP spoofing shit
block in quick from urpf-failed
# make sure scrubbing is enabled
scrub in all
# make port scanning a little bit harder :P
block in quick on $localnet proto tcp flags FUP/WEUAPRSF
block in quick on $localnet proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $localnet proto tcp flags SRAFU/WEUAPRSF
block in quick on $localnet proto tcp flags /WEUAPRSF
block in quick on $localnet proto tcp flags SR/SR
block in quick on $localnet proto tcp flags SF/SF
block in quick on $localnet proto tcp from any to any flags FUP/FUP
Und nicht vergessen, dass auch einige sysctl-Werte durchaus für eine anständige Firewall relevant sind. So solltest du z.B. net.inet.ip.forwarding und net.inet6.ip6.forwarding deaktivieren u.ä.. Welche im Einzelnen relevant sind, hab ich für BSD leider gerade nicht parat.
 

overflow

Member of Honour
Logfile Analyse

Ich habe mal testweise den Server angepingt.

Wie man sieht, wird der ICMP-Paket geblockt.

Nach Eingang des Paketes werden umgehend vom Server Daten an eine andere IP verschickt. Wieso das?
Die Dst-IP ist doch in der von mir (Host) verschickten IP 87.78.49.156. Frage mich nun wieso der Server auf 80.237.128.114.53 versucht zu antworten.

Code:
$ sudo tcpdump -n -e -ttt -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Oct 27 22:55:48.776659 rule 6/(match) block in on bnx0: [B]87.78.49.156[/B] > xxx.xxx.xxx.xxx: icmp: echo request
Oct 27 22:55:49.092323 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.34009 > 80.237.128.114.53: 52232+[|domain]
Oct 27 22:55:49.092330 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.26211 > 80.237.128.145.53: 52232+[|domain]
Oct 27 22:55:49.092341 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.19009 > 80.237.128.114.53: 34255+[|domain]
Oct 27 22:55:49.092347 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.11179 > 80.237.128.145.53: 34255+[|domain]
Oct 27 22:55:49.092362 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.45426 > 80.237.128.114.53: 52316+[|domain]
Oct 27 22:55:49.092368 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.16270 > 80.237.128.145.53: 52316+[|domain]
Oct 27 22:55:49.092379 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.25897 > 80.237.128.114.53: 57495+[|domain]
Oct 27 22:55:49.092385 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.47983 > 80.237.128.145.53: 57495+[|domain]
Oct 27 22:56:04.102333 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.48548 > 80.237.128.114.53: 40993+[|domain]
Oct 27 22:56:04.102340 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.46342 > 80.237.128.145.53: 40993+[|domain]
Oct 27 22:56:04.102350 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.13528 > 80.237.128.114.53: 39876+[|domain]
Oct 27 22:56:04.102356 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.8033 > 80.237.128.145.53: 39876+[|domain]
Oct 27 22:56:04.102372 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.20705 > 80.237.128.114.53: 40632+[|domain]
Oct 27 22:56:04.102378 rule 6/(match) block out on bnx0: xxx.xxx.xxx.xxx.44360 > 80.237.128.145.53: 40632+[|domain]
 

mime

Stammuser
Code:
# make port scanning a little bit harder :P
block in quick on $localnet proto tcp flags FUP/WEUAPRSF
block in quick on $localnet proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $localnet proto tcp flags SRAFU/WEUAPRSF
block in quick on $localnet proto tcp flags /WEUAPRSF
block in quick on $localnet proto tcp flags SR/SR
block in quick on $localnet proto tcp flags SF/SF
block in quick on $localnet proto tcp from any to any flags FUP/FUP
Diese Regeln versuchen OS Fingerprinting durch z.B. nmap zu erschweren. Wie wird dadurch das System sicherer? Security by Obscurity funktioniert nicht wirklich...

@overflow:
80.237.128.114.53 <- .53 ist der Port. Also DNS. Alles klar?
 
Zuletzt bearbeitet:

overflow

Member of Honour
Port 53 habe ich übersehen =)
Also sollte ich Port 53 auch freigeben?!

Thema Regeln
Ja, dadurch wird das System sicherer.

Wenn man einen Teil der Angriffe in die Knie zwingen kann, dann hat es schon etwas gebracht.
 

mime

Stammuser
Nein, das Prinzip ist das Gleiche. Auch Bots versuchen das System ihres Opfers zu identifizieren. Schaffen sie das nicht erfolgreich, fahren sie die völlig falschen Einbruchsversuche und Vuln-Scans und scheitern.
Da bin ich bei dir. Bots und bestimmte automatisierte Angriffen kannst du damit ausbremsen. Der Punkt ist aber doch, dass ein *echter* Angriff sich dadurch eben nicht verhindern lässt. Dein System wird durch "security by obscurity" *kein* Stück *sicherer*.

Das entfernen/umbenennen bestimmter Binaries kann aber wirklich Sinn machen. Das aber hat eben nicht wirklich was mit "security by obscurity" zu tun...Daher IMHO am Thema vorbei...
 

SchwarzeBeere

Moderator
Mitarbeiter
Da bin ich bei dir. Bots und bestimmte automatisierte Angriffen kannst du damit ausbremsen. Der Punkt ist aber doch, dass ein *echter* Angriff sich dadurch eben nicht verhindern lässt. Dein System wird durch "security by obscurity" *kein* Stück *sicherer*.
Wenn du davon ausgehst, dass ein Angreifer über unendlich Ressourcen und Zeit verfügt und absolut objektiv einen Angriff durchzieht, dann hast du sicherlich recht. In der Praxis ist das aber nicht der Fall, d.h. meist stehen Angreifer unter zeitlichem und finanziellem Druck, gewürzt mit einer Prise Nervenkitzel und der Angst, dass der Angriff auffliegt und entsprechend reagiert wird. Das Herauszögern von möglichen Angriffen, bzw. im konkreten deren Information Gathering Phase, ist dabei imho ein probates Mittel zur Abwehr nicht nur von automatischen oder Skript-Kiddy-Angriffen, sondern auch von konkreten Bedrohungen, weil es erkennbare Fehler provoziert (z.B. Angriffe gegen Linux-Systeme, weil nmap statt Windows 2003 eben Linux 3.x ausgespuckt hat), weil es frustriert ("verdammt, jetzt muss ich zum 20ten Mal umdenken", "jetzt muss ich schon wieder danach suchen") und nicht zuletzt Ressourcen frisst (Keine Infos, keine Bezahlung). Das macht SbO gerade in Kombination mit vorhandenen technischen Abwehr- und vor allem Erkennungsmechanismen sehr wertvoll für einen Verteidiger und steigert damit auch die Sicherheit des kompletten Systems, wenn auch eher auf organisatorischer, als auf technischer Ebene.
 
Zuletzt bearbeitet:

mime

Stammuser
Ein guter Angriff kann sich über Wochen und Monate hinziehen bevor er abgeschlossen wird. "Zeitlicher Druck" sieht irgendwie anders aus...
 

bitmuncher

Moderator
Ein guter Angriff kann sich über Wochen und Monate hinziehen bevor er abgeschlossen wird. "Zeitlicher Druck" sieht irgendwie anders aus...
Ein solcher Angriff findet nur erfahrungsgemäss auf die wenigsten Server statt. Die meisten Angriffe (>90%) auf Server werden automatisiert durch Bots durchgeführt, die sich weiterverbreiten wollen.
 

SchwarzeBeere

Moderator
Mitarbeiter
Ein guter Angriff kann sich über Wochen und Monate hinziehen bevor er abgeschlossen wird. "Zeitlicher Druck" sieht irgendwie anders aus...
Es existieren zwischen - Vorsicht, Marketing-Begriff! - APTs und Bots/Skriptkiddies auch Angreifertypen, die versiert vorgehen können, aber nicht Wochen und Monate dafür Zeit haben, beispielsweise Insiderangriffe gekündigter oder unzufriedener Mitarbeiter, Wirtschaftsspionage einzelner Konkurrenzunternehmen, Hacktivismus (was gerade bei Banken und Unternehmen aus dem Militärumfeld stark zugenommen hat) oder einfach nur Vandalismus von übermütigen Studierenden. Hier hast du klare Zeit- und Ressourcengrenzen sowie psychologische Faktoren (Frustrationspotential, Lust, Hass, (Un-)Geduld, "Kick", ...), welchen du mit SbO begegnen kannst. Und genau diese Typen von Angreifern machen die Hauptarbeit aus, wenn wir von automatischen Bots und Tool-geilen Skriptkiddies absehen.

APTs dagegen sind sehr selten, auch wenn dies von der Sicherheitsindustrie, insbesondere der amerikanischen, getreu dem FUD-Ansatz gegenteilig suggeriert wird. Aber auch hier macht SbO Sinn, da es die Wahrscheinlichkeit, dass der Angriff entdeckt wird, steigert. Hier spielt der Ressourcenfaktor natürlich nur eine geringere Rolle. Eine Einschränkung gibt es: Die technischen Sicherheitsmaßnahmen müssen darauf ausgelegt sein, d.h. SbO muss bewusst eingesetzt werden und Teil eines ganzheitlichen Sicherheitskonzepts sein. Dies ist in vielen Unternehmen nicht der Fall.

Ein weiterer Aspekt - neben dem Verstecken von Informationen - von SbO, der mir sehr gut gefällt, den ich aber bisher noch nicht gesehen habe (oder vielleicht schon, man weiss es nicht :)), ist die bewusste Streuung von falschen Informationen. Im großen Stil kann das auch gegen APTs verwendet werden und damit zur Verteidigung eingesetzt werden. Gerade bei APTs steht die (passive) Informationssammlung im Vordergrund, d.h. soziale Kontakte von Mitarbeitern, Informationen aus öffentlichen Datenbanken (Shodan, Google, Monster.de, netcraft, ...) oder technische Informationen (Netzwerkverkehr, Architekturinformationen, whois, ...). Werden hier schon von Beginn an falsche Informationen nach außen getragen und veröffentlicht, kann auch hier wieder eine Brücke zur Angriffserkennung geschlagen werden.

Edit:
Es gibt einige Szenarien, in denen SbO wirklich keinen Sinn macht. Das bekannteste ist die Kryptographie, ein anderes die Veröffentlichung von möglichen Schwachstellen sowie von Angriff- und Bedrohungsstatistiken von "Endkunden" bzw. Unternehmen. Zur Kryptographie muss ich glaube ich nichts sagen. Die Veröffentlichung von Schwachstelleninformationen halte ich für essentiell für die Sicherheit, da dadurch öffentlicher Druck auf Hersteller erzeugt wird oder Unternehmen diese Lücken auch selbst schliessen können (jaja ich weiss, Praxis sieht anders aus..) bzw. ein Informationsgleichgewicht zwischen Angreifer und Verteidiger geschaffen wird. Angriffs- und Bedrohungsstatistiken halte ich gerade von großen Unternehmen und im internationalen Umfeld für wichtig, um "das große Ganze" zu schützen und die Verteidigung allgemein zu verbessern bzw. auf Bedrohungen schneller reagieren zu können. Ein Angriff auf eine Bank könnte so einen Angriff auf eine andere Bank nach gleichem Muster verhindern, da Informationen zu ersterem ausgetauscht und entsprechende Maßnahmen ergriffen wurden.
 
Zuletzt bearbeitet:
Ich habe eine Frage zum Paketfilter, deswegen hole ich diesen Thread wieder aus der Versenkung.
Will deswegen kein neues Thema erstellen.

Wie kann ich PF konfigurieren, damit nur eingehende Paket auf die IP-Adresse vom System (interface_ext) mitgeloggt werden?
Derzeit wird Alles bis auf SSH und HTTP mitgeloggt:
Code:
# Based on https://www.openbsd.org/faq/pf/example1.html

interface_ext="vio0"
port_ssh="xxxxx"
port_http="80"

table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
                   127.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
                   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
                   203.0.113.0/24 }

# Global settings
set block-policy drop
set loginterface egress
set skip on lo0

# Block RFC 1918 addresses
block in quick on egress from <martians> to any
block return out quick on egress from any to <martians>

# Global rules
block log all
match in all scrub (no-df max-mss 1440 random-id)
pass out quick inet

# Secure shell rules
pass in on $interface_ext inet proto tcp from any to $interface_ext port $port_ssh

# http rules
pass in on $interface_ext inet proto tcp from any to $interface_ext port $port_http
 
Zuletzt bearbeitet:
Oben