Welche Firewall (Snort)

T

tux972

Member
Hallo!

Bin gerade am ueberlegen welche FW ich aufsetzen soll Snort od. Snort_inline od. Snortsam.
Kennt ihr noch eine IPS (Intrusion Prevention System) fuer FreeBSD?
Leider kann man Snort nicht als IPS unter FreeBSD einsetzen oder?

DANKE!
 
Ist Snort nicht per Definition eine IPS?

Dadurch natürlich auch nur ein Teil des Sicherheitskonzepts "Firewall"...
 
hi
also snort kann mit pf und ipfw2 bzw ipfw nicht direkt umgehen .

snort_inline gibt es mit 2.9.0 nicht mehr , da es dort eine neues modul gibt welches das inline
ersetzt .

der einfachste weg das ganze zum laufen zubekommen ist der weg

snort -> syslog -> ossec -> pf

ossec ist ein hids weches echt gut funktioniert und client server basierend ist.

vorteil ist so das man snort auf einer seperaten maschine ( mit viel ram ! )
laufen lassen kann .
nun verbindet man das 2te ethernet interface via mirror port an die wan oder
dmz seite des ethernet interface der fw .

auf beiden maschinen laeuft ossec (server auf dem snort client auf der fw )
der server koennte aber auch komplett auf einer dritten maschine laufen.

der ossec ist ein u.a. syslog-server wohin man nun den snort output hinleitet.

ist nun eine alarm level1 das reagiert der ossec so wie man es moechte.
z.b. ip block auf der firewall , email notification was auch immer , das ist frei konfigurierbar.

site ossec -> www.ossec.org

holger
 
OT

Kann man damit auch Bittorrent oder KaZaa aussperren ohne Ports zu schliessen?
Angenommen auf 8080 läuft ein Tomcat. Der Traffic ist legitim
Angenommen auf 8080 läuft Bittorrent. Der Traffic soll gesperrt werden.
Ich weis nur wie man das mit IPtables macht.
 
hi

also je mehr ram destso besser , kommt darauf an wieviel traffic analysiert werden muss.
wenn 1 server nur vorhanden ist dieser aber volle 1Gb traffic hat sollte man mal von
4 GB ram ausgehen.

wichtig hierbei ist folgendes snort erkennt nicht wieviel ram vorhanden ist und nutzt
dieses, sondern man muss ich via config sagen wieviel er wo verwenden soll.

wenn snort kaza erkennt , bzw man sich regeln dafuer baut ja .

ossec kann nur logfiles auswerten bzw das was er via syslog bekommt.

und da snort die alarme entsprechend klassifiziert und diese via syslog ausgeben kann
ist die folge kein problem.

@minimike da ich jetzt nicht weiss wie du bittorrent oder kazaa erkennst , frage ich mich wie das mit pure iptables gehen soll.

in kombination mit einem proxy oder snort sollte es gehen.
z.b.
http://www.sans.org/reading_room/whitepapers/detection/detecting-torrents-snort_33144

somit kann man wieder entsprechend mit ossec agieren.

holger
 
Hallo mark05
Das macht man mit Rope http://www.lowth.com
Läuft testweise in einer DomU. Diese hat 1024 MB Ram und eine VCPU sowie habe ich mit PCI Passthrough eine NIC durchgeschleift. Nur mir schmeckt der ganze Aufwand hierfür nicht. Vor allem will ich von Linux weg weil ich aufgrund Securitykernelupdates im Schnitt zwei mal im Monat die Kiste neu starten muss
 
minimike schrieb:
OT

Kann man damit auch Bittorrent oder KaZaa aussperren ohne Ports zu schliessen?
Angenommen auf 8080 läuft ein Tomcat. Der Traffic ist legitim
Angenommen auf 8080 läuft Bittorrent. Der Traffic soll gesperrt werden.
Ich weis nur wie man das mit IPtables macht.
Zum Vergrößern anklicken....

tomcat im LAN/DMZ? Dann halt alles nach draußen verriegeln und 8080 nur intern und von außen erlauben.
 
oenone schrieb:
tomcat im LAN/DMZ? Dann halt alles nach draußen verriegeln und 8080 nur intern und von außen erlauben.
Zum Vergrößern anklicken....
Es geht mehr darum das ich nicht administrativ für jeden Rechner verantwortlich bin. Allerdings für das gesammte Netz habe ich Mitverantwortung. Darum ist das wilde Sperren von Ports suboptimal. Man kann ja auch Filesharing auf Port 80 legen. Wenn da ein Clientserver aus der Reihe tanzt möchte ich schon vorher was haben.
 
minimike schrieb:
Hallo mark05
Das macht man mit Rope http://www.lowth.com
Läuft testweise in einer DomU. Diese hat 1024 MB Ram und eine VCPU sowie habe ich mit PCI Passthrough eine NIC durchgeschleift. Nur mir schmeckt der ganze Aufwand hierfür nicht. Vor allem will ich von Linux weg weil ich aufgrund Securitykernelupdates im Schnitt zwei mal im Monat die Kiste neu starten muss
Zum Vergrößern anklicken....


im kern ist das ein proxy den man programmieren kann .
fuer http gibt es dafuer relayd , fuer smtp z.b. spamd beidens im openbsd
system enthalten.

altq ist drin und pf.os ( tcp fingerprint )

somit kann man eingentlich eine kazaa was auch immer loesung
mit boardmittlen bauen.

fuer firewalls ist es eh besser openbsd zu verwenden da der pf code
hier entwickelt wird und selbst wenn freebsd es schafft den stand von 4.5

zu implementieren so sind sie dann immer noch 1,5 - 2 jahr hinterher.

und gerade die letzen beiden versionen 4.7 und 4.8 haben massive
perfomance verbesserungen gebracht.

ich meine es muesste sogar einen aehnlichen proxy geben fuer openbsd.

holger
 
mark05 schrieb:
fuer firewalls ist es eh besser openbsd zu verwenden da der pf code
hier entwickelt wird und selbst wenn freebsd es schafft den stand von 4.5
Zum Vergrößern anklicken....
*seufz* pf ist ja nun auch nur eine von drei Paketfiltern unter FreeBSD. Da haben wir IP Filter und pf als die beiden externen. Und wie ich immer so gern schreibe, pf ist unter FreeBSD eine schöne Technik um kleine Heimnetzwerke zu filtern. Aber wer mehr will, sollte tunlichst IPFW nehmen. Ich will nun nicht diskutieren, ob IPFW oder pf generell besser ist, denn das ist durch die sehr unterschiedlichen Konzepte auch eine sehr subjektive Sache. Die Sache ist halt die. Zu sagen "pf unter FreeBSD ist nicht so dolle" ist vielleicht irgendwo die Wahrheit. Aber daraus zu schließend, dass man für Paketfilter generell OpenBSD nehmen sollte, ist schlicht die falsche Folgerung. Denn IPFW ist a) extrem schnell und b) in Features extrem mächtig. Das Ding wird sicher nicht ohne Grund von mehreren großen bis sehr großen kommerziellen Netzwerktechnik-Anbietern eingesetzt, wurde auf Linux und Windows portiert, ist zentraler Gegenstand mehrerer europäischer Forschungsprojekte in dem Bereich, etc...
 
@yamagi d hast in sofern recht als das ipfw fuer und mit freebsd entwickelt wird und somit
es mit dem kernel besser verzahnt ist .
jedoch ist gibt es ja noch ein par andere gruende die eher fuer openbsd sprechen an der stelle.

u.a. verzahnung carp + pfsync mit pf , stichwort hochverfuegbarkeit.

und auch hier ist freebsd hinterher da carp nur ein import ist und pfsync kommt jetzt erst
und ist in den kinderschuhen und vermutlich erstmal nur mit pf zu verwenden.

holger
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben