Topics

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

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

[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

Hallo zusammen,

morgen wollte ich die OPNsense online nehmen und dafür heute noch IDS/IPS mit suricata konfigurieren und testen.

Derzeit gehe ich über das LAN Interface über unsere Firewall ins Internet. WAN Gateway ist deaktiviert, da dieses erst morgen angeschlossen wird.

Suricata ist folgendermaßen Konfiguriert:
Enabled [X]
IPS mode [X]
Promiscuous mode [ ]
Enable syslog alerts [ ]
Interfaces [LAN]

Bei Pattern matcher [Hyperscan] wird der Dienst einfach beendet ohne einen Eintrag im Log

Code Select Expand


Oct 31 10:58:29 suricata: [101386] <Info> -- 37291 signatures processed. 3063 are IP-only rules, 6190 are inspecting packet payload, 29960 inspect application layer, 103 are decoder event only
Oct 31 10:58:28 suricata: [101386] <Info> -- Threshold config parsed: 0 rule(s) found
Oct 31 10:58:28 suricata: [101386] <Info> -- 60 rule files processed. 37286 rules successfully loaded, 0 rules failed
Oct 31 10:58:16 suricata: [101383] <Info> -- Found an MTU of 1500 for 'lagg0'
Oct 31 10:58:16 suricata: [101383] <Info> -- Found an MTU of 1500 for 'lagg0'
Oct 31 10:58:16 suricata: [101383] <Info> -- Found an MTU of 1500 for 'lagg0'
Oct 31 10:58:16 suricata: [101383] <Info> -- Found an MTU of 1500 for 'lagg0'
Oct 31 10:58:16 suricata: [101383] <Info> -- Netmap: Setting IPS mode
Oct 31 10:58:16 suricata: [101383] <Info> -- CPUs/cores online: 8
Oct 31 10:58:16 suricata: [101383] <Notice> -- This is Suricata version 4.0.5 RELEASE


Mit Aho-Corasick läuft d er Dienst und legt auch ein Logfile für die Alerts an.
Testweise habe die Rulesets von abuse.ch sowie ein paar von emergingthreats.net auf drop gestellt.
Wenn ich jetzt versuche eine Adresse von https://urlhaus.abuse.ch/browse aufzurufen ist dies Problemlos möglich. Die IP wird im Log auch gar nicht angezeigt, dafür ein paar andere Einträge mit "allowed".

Fehlt hier noch irgendwas, damit auch alles geprüft wird?

I tested opnsense on the weekend and found some problems. I would like to write the questions from yesterday (irc) again here

Hello guys, im testing opnSENSE for our company this weekend. Currently I have a problem with HAProxy + letsencrypt. I have created a public service listening on port 80. Here are two rules stored: redirect_acme and redirect_to_https.
In this combination, I can not create certificates with lets encrypt and get an error. If I remove the rule "redirect_to_https" it works fine.
Is it possible to build in any kind of priority so that the lets_encrypt rule
is always checked first? with "test syntax" I receive the following message: a 'http-request' rule placed after a 'use_backend' rule will still be processed before.

In addition, subfolders are not externally accessible. Is it possible to configure HAProxy in such a way that subfolders are always used internally and externally same?

domain.com -> server.local
domain.com/sf1 -> server.local/sf1
domain.com/sf2 -> server.local/sf2

Nachdem ich alle schwereren Probleme behoben habe, wollte ich noch ein simples Port-Forward einrichten.

Leider klappt dieses momentan nicht, wie es soll.

Interface: WAN
TCP/IP: IPv4
Protocol: TCP/UDP
Destination: 86.167.153.109 (externe IP als Virtual IP angelegt)

Destination port range
from: SSH to: SSH
(optional habe ich es auch mit http versucht)

Redirect target IP: Single host or Network
172.16.18.41
Redirect target port: SSH

NAT reflection: Disable
Filter rule association: Pass


Egal ob mit SSH oder HTTP die Anfragen kommen bei den Servern nie an, in den OPNsense logs sehe ich immer nur folgenden Eintrag:
Interface: lan
Source: 1.2.3.4:####
Destination: 86.167.153.109:22
Proto: tcp
Label: let out anything from firewall host itself

[Real Servers]

ich habe mich jetzt schon durch einige Beiträge hier im Forum und Netz geschlagen, leider habe ich aber meine Lösung noch nicht gefunden, daher versuche ich es nochmal mit einem eigenen Thread.

Folgende Ausgangslage: OPNSense 18.1.6 (LibreSSL)

WAN Netz: 86.167.153.104/29
.105 & .106 sind durch die Telekom blockiert, somit bleiben mir aktuell folgende IP Adressen:
86.167.153.107 (Zugang ins Internet funktioniert bereits)
86.167.153.108 (hierüber sollen zwei Websites erreicht werden, https://file.domain.com und https://wiki.domain.com)
86.167.153.109 (vorerst nicht benötigt)
86.167.153.110 (vorerst nicht benötigt)
(ich nutze bewusst nicht pro domain eine IP, da es sich hier um ein LAB handelt und wir später auch mehrere Domains pro IP haben)


Zugriff soll so ablaufen

Zugriff per Browser auf 86.167.153.108 per HTTPS (HTTP redirect HTTPS) -> OPNsense -> HAProxy -> Server (Port 80)


Folgendermaßen habe ich versucht den Zugriff einzurichten:
Firewall - Rules - WAN
Source *
Port *
Destination 86.167.153.108/29
Port 443

Source *
Port *
Destination 86.167.153.108/29
Port 80

Firewall - Virtual IPs - Settings
Virtual IP address 86.167.153.108/29
Interface WAN
Type IP Alias

HAProxy
Real Servers
Name file
FQDN or IP file.locale.lan
Port 80

Name wiki
FQDN or IP wiki.locale.lan
Port 80

Backend Servers
Enabled (x)
Mode: HTTP (Layer 7)
Servers: file
Rules: file-rule

Enabled (x)
Mode: HTTP (Layer 7)
Servers: wiki
Rules: wiki-rule

Public Services
Enabled (x)
Listen Addresses: file.domain.com:443 file.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: file
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: file-rule

Enabled (x)
Listen Addresses: wiki.domain.com:443 wiki.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: wiki
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: wiki-rule


Rules & Checks
Condition
Name: file-condition
Condition type: Host starts with
Host Prefix: file

Name: wiki-condition
Condition type: Host starts with
Host Prefix: wiki

Rules
Name: file-rule
Test type: IF
Select condition: file-condition
Execute function: Use specified Backend Pool
Use backend pool: file

Name: wiki-rule
Test type: IF
Select condition: wiki-condition
Execute function: Use specified Backend Pool
Use backend pool: wiki

Im Log erhalte ich nur folgende Mitteilung
haproxy[95545]: Connect from 1.2.3.4:21630 to 86.167.153.108:443 (wiki.domain.com/HTTP)

Hello guys,

fresh install of OPNsense last friday, now i wanna update to 18.1.6 but squid isnt able to reinstall:

Code Select Expand

[1/37] Fetching squid-3.5.27_3.txz: .......... done
pkg-static: cached package squid-3.5.27_3: size mismatch, fetching from remote
[2/37] Fetching squid-3.5.27_3.txz: .......... done
pkg-static: cached package squid-3.5.27_3: size mismatch, cannot continue

I tried "pkg update -f" and upgrade but it didnt help


fixed by changing Firmware Mirror from dns-root.de to (default)

Hallo zusammen,

aus einem kleinen Testprojekt soll nun doch ein Liveprojekt werden -> OPNsense soll die aktuelle Firewalllösungen ablösen

Wir besitzen bei der Telekom 3 IP Netze mit /29-Gateway, die wir so auch auf der OPNsense nutzen wollen. Derzeit wird ein Netz von der Watchguard für den Zugang nach außen und ein Netz auf dem TMG für den Zugang nach innen (die Lösung habe ich bei Arbeitsbeginn so "übernommen" - daher kann ich nicht beantworten, warum man sich für so eine Lösung entschieden hat)

Nun stellt sich mir aber die Frage, ob wir alle 3 Netze an einem NIC nutzen können? Wie wäre hier die sinnvollste Lösung?
Derzeit haben wir eines der Netze an die Test OPNsense angebunden, wenn wir raus gehen erhalten wir aber nicht immer die gleiche IP Adresse sondern unterschiedliche aus dem jeweiligen Netz.
Für den Zugang nach innen muss ich vermutlich 1:1 NAT nutzen, wenn ich das richtig gelesen habe? Zumindest arbeitet auch der TMG mit diesem Prinzip, hier wird nur angegeben von welcher externen IP die Anfrage kommt und an welchen Server diese dann übermittelt wird.
Wäre es hier sinnvoller/einfacher die Konfiguration komplett in der OPNsense zu machen und zwischen den beiden Geräten der Telekom (failover) nur einen unmanaged Switch (aktuelle Lösung) zu klemmen, oder das NAT in einem Switch zu konfigurieren?


In Zukunft soll dann auch noch eine zweite OPNsense als Failover dazu kommen. Ist es hier nötig die komplett gleiche Hardware zu nehmen? Wir haben uns jetzt für die "viel zu große Lösung" entschieden, 16GB RAM, XEON-1230, 2x 240GB SSD, damit wir auch gar keine Performanceprobleme bekommen, da die ersten Dienste am besten sofort über die neue Firewall laufen sollen.
Für das Failoversystem würde ich aber, wenn es keine Probleme geben würde, die Minimallösung nehmen: 4GB Ram, Intel Pentium G4600