Messages

Wir haben hier eine OPNsense mit Xeon 1230, 16gig RAM und 100mbit symmetrischer Leitung.

openVPN ist von extern aber auch nicht so berauschend schnell, wir warten immer noch auf wireguard um das VPN für die MA anzubieten.

Moin moin,

aktuell gucke ich mir mal wieder das Thema URL Tables und blocklist an. Bisher hatten wir nur die spamhaus listen gesperrt (ausgehend und ankommend), heute habe ich zusätzlich blockhaus.de (all) ausgehend und eigehend gesperrt.
Beim suchen bin ich hier im Forum aber auch wieder auf firehol gelandet und habe mich heute das erste mal mit deren Websites und Listen beschäftigt. Gerne würde ich unsere Firewall mit den Listen weiter absichern. Meine Idee auf die schnelle ist folgende:
ausgehend:
1. firehol_webserver
2. firehol_level2 (level1 wird dann irgendwann mal am wochenende getestet)
3. spamhaus_drop
4. spamhaus_edrop

ankommend:
1. firehol_level2 (level1 wird dann irgendwann mal am wochenende getestet) - kann man ggf. direkt level1 nutzen?
2. spamhaus_drop
3. spamhaus_edrop

alternativ im live log gucken was passiert wenn du eine Seite öffnen willst (in der regel noch den haken setzen, dass die regel auch geloggt werden soll)

funktioniert ein Ping ins Internet? (ICMP Regel)

usr/local/bin/python2.7 speedtest.py

[nsbesondere welche Regeln loggen und welche nicht...]

Um dazu etwas sagen zu können müsste man das ganze Regelwerk auf WAN und LAN kennen, insbesondere welche Regeln loggen und welche nicht...

dieser satz war entscheidend. wir haben natürlich bei keiner regel das logging aktiv gehabt  ::)
jetzt bekomme ich beim zugriff auf heise.de auch mehrere IP Adressen zurück die von meiner lokalen IP als Source angezeigt werden! Vielen dank!

Spricht etwas dagegen bei allen Regeln das Logging zu aktivieren, oder sollte man dies wirklich nur für analyse zwecke machen?

Hallo zusammen,

im Log ist uns heute etwas merkwürdiges aufgefallen, Filtern wir nach unseren DHCP IP Adressen sehen wir quasi nur geblockte Verbindungen die per default deny rule geblockt werden.

Filter ich jetzt nach meiner internen IP habe ich quasi das gleiche Bild (mit ausnahme der anti-lockout rule).
Erlaubte Verbindungen werden uns immer nur mit der Source des der default Gateway IP angezeigt.

Daher ist es z.B. nicht möglich im Log nachzuverfolgen, wohin Verbindungen aufgebaut werden.
Klassisches Beispiel: Ich ping heise.de an, filter nach meiner IP Adresse und sehe den PING nicht. Filter ich nach der IP von heise.de sehe ich die PINGs, mit unserer externen IP als Source.


Bei den Logfiles ist mir außerdem aufgefallen, dass eine bestimmte externe IP alle 10-40 Sekunden unterschiedlichste Ports in unserem System prüft. Mit abuseipdb.com war schnell rauszufinden, dass wir nicht das einzige Ziel sind.
Ich habe hierfür dann einen Alias "blocked-IPs" erstellt (Typ: Host(s) und die IP Adresse eingetragen
Danach in den Firewall Rules für das Interface "allWAN" folgende Regel erstellt:
Action: Block
Interface: allWAN
TCP: IPv4
Protocol: any
Source: blocked-IPs
Destination: any

Dennoch wird die Verbindung im Log nur von der "default deny rule" geblockt

Moin,

leider noch nicht, momentan läuft IDS/IPS zwar, allerdings nur mit check auf WAN. Gestern habe ich es kurz auf LAN geändert, dann war das Internet weg, ich habe LAN schnell wieder raus genommen, und die firewall ist neu gestartet :/ Werde das ggf. nochmal an einem Wochenende im Februar testen können

@jinn, are you running Sensei on your LAN? Any chances that it might be on your WAN interface?

it is currently on LAN. The WAN interface is not displayed to me under available interfaces.

hey mb, ty for reply!

For reporting about application categories, yes you can do it. I guess you've started using it.

Not yet. At least not as detailed as I would like (facebook, online shopping, ...)

As for the egress connections report does not show anything. Is it just a single report or all reports which shows egress connections (i.e. local assets, remote assets, eggress conns by source ) do not show anything at all.

in fact, several do not work: Egress New Connections by App Over Time, Egress New Connections by Source Over Time, Egress New Connections Heatmap, Top Destination Locations Heatmap, Table of Apps (maybe this one is what im really looking for?), Table of Local Assets, Table of Remote Hosts

I tested sensei last week. after I activated it, however, access to the internet was barely possible (eg google was not available at all). since it was a productive system, I deactivated sensei for now and did not continue to use it. Nevertheless, I would like to know why it was located, how should I proceed best for analysis here?

In addition, I wanted to ask whether it is even possible, what I want to achieve: I would like an evaluation for special services (social media, online gaming, ...). Is sensei able to give me an evaluation of how much time / data was used for special services?

currently sensei works with deactivated cloud threat intel.
Unfortunately, "Egress New Connections by APP Over Time" and "Egress New Connections by Source Over Time" show no data:"no egress new connection" what do I have to configure to make it work?

super, vielen dank! dann kann ich mir die "doppelten regeln" ja sparen >_<

danke, tatsächlich ist noch eine any-to-any vom lan in die DMZ regel aktiv -.-*

müsste es nicht dennoch eine income regel für die DMZ geben?

I tested sensei last week. after I activated it, however, access to the internet was barely possible (eg google was not available at all). since it was a productive system, I deactivated sensei for now and did not continue to use it. Nevertheless, I would like to know why it was located, how should I proceed best for analysis here?

In addition, I wanted to ask whether it is even possible, what I want to achieve: I would like an evaluation for special services (social media, online gaming, ...). Is sensei able to give me an evaluation of how much time / data was used for special services?

[let out anything from firewall host itself]

Hallo zusammen,

ich bin gerade dabei die OPNsense um eine DMZ zu erweitern.

LAN: 172.16.0.0/21
DMZ: 172.16.18.0/23

Bei den Regeln hatte ich das Problem, dass der Server aus der DMZ nicht auf den DNS im LAN zugreifen konnte.
Regel hatte ich folgendermaßen erstellt:
Interface: DMZ
Prot: UDP
Source: DMZ_Net
Dest: DNS_Server (Alias Gruppe)
Dest_Port: DNS

Interface: LAN
Prot: UDP
Source: DMZ_Net
Dest: DNS_Server (Alias Gruppe)
Dest_Port: DNS

Über eine Floating Rule funktionierte es dann:
Interface: DMZ, LAN
Prot: UDP
Source: DMZ_Net
Dest: DNS_Server (Alias Gruppe)
Dest_Port: DNS

Was mich aber mehr überrascht ist die Tatsache, dass ich auf Port 8080 in der DMZ zugreifen kann ohne dafür eine Regel erstellt zu haben.
IP: 172.16.2.123
DMZ: 172.16.19.5

Log:
action: pass
dir: out
dst: 172.16.19.5
dstport:8080
interface: lagg1 (DMZ LAGG)
label: let out anything from firewall host itself
protoname: tcp
reason: match
src: 172.16.2.123

Woran kann das liegen? Das sollte so ja auf keinen Fall funktionieren

Wenns einfach sein soll nimm openVPN.

Ansonsten soll der wiki Artikel für IPsec demnächst aktualisiert werden ;)