Messages

Wenn beide Frontends auf den gleichen Port hören musst du eines der beiden Frontends löschen und bei dem anderen beide Regeln und Zertifikate hinterlegen. (muss hört sich jetzt so nach wissen an, bei mir hat es zumindest funktioniert nachdem ich alle frontends gelöscht habe und nur noch mit einem gearbeitet habe :D die info hatte ich aber auch hier aus dem forum)

Das Wiki von OPNsense und Youtube Videos helfen schon sehr, alternativ kann ich das Buch "Der OPNsense-Praktiker" empfehlen: https://der-opnsense-praktiker.github.io/

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

Folgendermaßen habe ich es vor kurzem konfiguriert:

1x Public Service  (Frontend)
Hier sind dann alle Certificate hinterlegt

Für jede Website gibt es eine eigene Regel (die auch jeweils einzeln in dem Public Service hinterlegt sind)

Die Regeln sind so aufgebaut:
Test type IF
Select conditions: condition_"SITE" (z.B. condition_alexa)
Logical operator: AND
Execute: use specified backend pool
use backend pool: backend_"SITE" (z.B. backend_alexa)

condition_alexa
type: host matches
host string: alexa.domain.com

backend_alexa
mode: http
servers: alexa (der interne elexa server unter real servers)

bisher funktionieren leider subfolder noch nicht, das liegt aber vermutlich an der condition, hatte noch keine zeit das weiter zu prüfen

Würde mich hier gerne mit einklinken, da ich den gleichen Fehler erhalte.

86.167.153.108 ist unsere externe IP
86.167.153.109 ist als VirtualIP eingetragen und ist auch von extern erreichbar (zumindest werden Logs angezeigt)

86.167.153.109 soll für das VPN (IPSEC mobile clients) genutzt werden

Ich habe die IPSEC Roadwarrior Anleitung genutzt mit folgenden Ändernungen:
Phase 1
Key Exchange version: v2 (der VPN soll auch für Windows Clients erreichbar sein)
My identifier: IP address 86.167.153.109
Unter Advanced ist alles auf disable

Phase 2
Type: LAN subnet
Protocol: ESP
Encryption: AES 256bits
Hast: sha256; sha384; sha512
PFS key group: off
Lifetime: 3600sec

Bei der Verbindung über zwei iPhones (iOS 11 und 12 beta 8 ) erhalte ich den gleichen Fehler wie oben angegeben

 :-[
Ich habe schon die IP der VHID Group eingestellt (die noch nicht konfiguriert ist und daher natürlich nicht erreichbar war)
Vielen dank für die Unterstützung, ich komm jetzt endlich auf den Server  ::)

Jetzt fehlt mir nur noch die Konfiguration vom VPN

>Nein, nicht "WAN net", das ist quark. "This Firewall" solltest du beim Port Forward auswählen. Und die Destination ist nicht /21 sondern nur diese IP (/32 also genau dieser Host).

Umgestellt, am Log und Packet Capture ändert sich allerdings nichts

>Aber ja, was Fabian sagt: dein Request kommt rein und geht wohl auf dem LAN wieder raus und durch. Wenn der dann beim Host nicht ankommt, ist auf deiner LAN Seite was schief. Kann die Sense überhaupt 172.16.18.144 pingen etc.?

Ping geht, über port probe erhalte ich auch eine Rückmeldung wenn ich als Source "any" oder die Virtual IPs auswähle. Nur wenn ich als source address "WAN" nutze bekomme ich einen Fehler: Connection failed (Refused/Timeout)

Gleiches übrigens auch mit RDP(3389) auf einem anderen Server

Jetzt nochmal die Screenshots mit weniger Schwarz
Die Regel konnte ich nicht bearbeiten, habe diese daraufhin manuell neu angelegt, und die automatisch erstellt deaktiviert, dadurch kam ein neuer Eintrag im Log pro Zugriffsversuch
Die Regeln habe über die Spamhaus listen gelegt, damit diese nicht geprüft werden

Leider funktioniert der Zugriff immer noch nicht, den Tipp von fabian werde ich noch nachgehen

Packet Capture am WAN gibt folgenden Eintrag:

Code Select Expand

16:59:25.138164 00:a0:c8:e8:27:gb > ac:1f:6b:63:6g:21, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 126, id 10997, offset 0, flags [DF], proto TCP (6), length 52)
    62.25.178.21.24901 > 86.167.153.109.22: Flags [S], cksum 0xead8 (correct), seq 1894655469, win 65535, options [mss 1400,nop,wscale 7,nop,nop,sackOK], length 0

Auf dem LAN ist das File leer

Ich habe jetzt nochmal die Screenshots mit jeweils gleicher IP angehangen (172.16.18.144)

Die Regel wird mit "Add associated filter rule" erstellt (3. Screenshot beinhaltet die aktuelle Regeltabelle)

Ich habe zwischenzeitlich auch versucht ein Port Forward mit Port 3389 zu erstellen, hier zeigt sich allerdings das gleiche Bild wie bei Port 22. Daher habe ich noch irgendwo einen Fehler in der OPNsense Konfiguration.

ich habe die screenshots etwas zeitversetzt erstellt. Zu dem Zeitpunkt stand im NAT auch die 172.16.18.144.
Andersrum stand zu dem Zeitpunkt des Screenshot des NAT die andere IP im Log.

Das war die ubuntu VM (172.16.18.144:22)

Gerne, hier mal als Screenshot und ein Screenshot vom Log beim versuchten Zugriff.

Unter Source steht die externe IP über die ich reinkomme, als Destination wird der Server angezeigt. Auf dem Server sehe ich aber keine Zugriffsanfrage. Ich habe auch eine neue ubuntu VM getestet, auf die ich, über das port-forward, auch nicht zugreifen kann.

Ich gehe zum testen über die aktive Firewall (und nicht die opnSENSE) raus, daher kommt der Zugriff auf die OPNsense auch aus dem Internet (so wie es in der Zukunft auch passieren) wird.

Zusätzlich habe ich zur Sicherheit aber auch den Zugriff von einem anderen Standort und dem mobilen Netz versucht.

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