Messages

16

German - Deutsch / Re: Hilfe! HAProxy und ACLs funktionieren nicht so, wie ich will

« on: October 31, 2018, 01:17:13 pm »

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 die info hatte ich aber auch hier aus dem forum)

17

German - Deutsch / Re: Gibt es irgendwo ein umfassendes Tutorial zur Einrichtung?

« on: October 31, 2018, 01:12:57 pm »

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/

18

German - Deutsch / Suricata probleme

« on: October 31, 2018, 11:16:19 am »

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]

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?

19

18.7 Legacy Series / HAProxy Subfolder and HAProxy + Lets Encrypt

« on: September 03, 2018, 03:50:00 pm »

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

20

German - Deutsch / Re: HaProxy SSL mehrere Server und Domains

« on: September 03, 2018, 02:59:18 pm »

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

21

German - Deutsch / Re: IPsec mit Multiwan

« on: August 29, 2018, 01:55:30 pm »

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

22

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 05:33:51 pm »

 
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

23

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 05:11:53 pm »

>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

24

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 04:45:18 pm »

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]

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

25

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 04:15:05 pm »

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.

26

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 04:01:38 pm »

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.

27

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 11:25:05 am »

Das war die ubuntu VM (172.16.18.144:22)

28

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 17, 2018, 11:07:21 am »

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.

29

German - Deutsch / Re: NAT Port-Forward will nicht

« on: April 16, 2018, 03:12:14 pm »

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.

30

German - Deutsch / NAT Port-Forward will nicht

« on: April 13, 2018, 04:02:57 pm »

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