Messages

Für die Nachwelt: Ich habe jetzt glaub alle Varianten ausprobiert und bin zu dem Schluss gekommen, dass man für jedes Subnetz einen eigene Verbindung mit Phase1 und Phase2 bauen muss (so wie @cmu das bereits vorgeschlagen hat). Ich bekomme ansonsten nicht zwei Subnetze über eine Phase2 geschleust.

Die RemoteID und LocalID müssen pro Verbindung abweichend sein, damit OPNsense und Fritz!Box diese zuordnen können. Den PSK habe ich auch abweichend gemacht. Da bin ich mir aber nicht sicher, ob das seien muss.

Falls sonst noch jemand eine Idee hat, immer her damit  :D

Hi,
I switched back from a PPoE Connection and therefore I can use IDS/IPS again.
I noticed that Suricata fails to start when I activate the rule list "abuse.ch/URLhaus". The following error is shown in the logs:

Aug 24 14:03:22    suricata: [100180] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"URLhaus Known malware download URL detected"; flow:established,from_client; content:"GET"; http_method; content:"/url=http://wordpress.p364918.webspaceconfig.de/614tiscfz/com/us|26|data=02|01|rcorm1@jcp.com|ec2a6ed25318490bd27608d6077bf11e|9c0ac0b90217468aa4322649cd6ed297|0|0|636704626242706015|26|sdata=g3qlynktc59ma3fllqbbfs0uwnigsem1mwi/cdfotvu=|26|reserved=0"; http_uri; depth:250; isdataat:!1,relative; content:"na01.safelinks.protection.outlook.com"; http_host; depth:37; isdataat:!1,relative; metadata:created_at 2018_08_21; reference:url, urlhaus.abuse.ch/url/45633/; classtype:trojan-activity;sid:80908733; rev:1;)^M" from file /usr/local/etc/suricata/opnsense.rules/abuse.ch.urlhaus.rules at line 1595

I thougt "Okay, maybe there's a problem with the list. Wait some days and check again." But the issue still exist.

I've found only one other topic in this forum with nearly the same issue, but this was still unsolved. So I'm wondering why nobody else have this problem.
Is this an issue of Spamhouse or maybe OPNsense?

Jas

Hey,

I had nearly the same following error in my logs:

Jun 16 10:23:06
suricata[60613]: [100202] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"URLhaus Known malware download URL detected"; flow:established,from_client; content:"GET"; http_method; content:"/irs-letters-062018-956/""; http_uri; depth:25; isdataat:!1,relative; content:"www.estepona.dpsoft.es"; http_host; depth:22; isdataat:!1,relative; metadata:created_at 2018_06_14; reference:url, urlhaus.abuse.ch/url/19286/; classtype:trojan-activity;sid:80882386; rev:1;)^M" from file /usr/local/etc/suricata/opnsense.rules/abuse.ch.urlhaus.rules at line 934

The main issue seems to be a failure with the signature of the named rule list.
I've disabled the list "abuse.ch/URLhaus" and IDS/IPS comes up again.

According to your logs you have to disable the list "PT/Research" too to become IDS/IPS running.

Jas

Beides funktioniert.

Aus Performance Sicht ist es sicherlich besser die Lösung mit den wenigsten Einträgen zu wählen. In diesem Fall also ein "Allow" für Germany.
Bei einem "Block" für alle anderen Länder, würde der Alias einiges mehr an IP Adressen enthalten, und müsste diese bei jeder Anfrage abgleichen. Mit einem "Allow" für Germany ist die Anzahl der abzugleichenen IPs kleiner,  somit weniger Aufwand für die FW beim Check von eingehenden Verbindungen.

Aus der Sicht der Sicherheit sollt man immer nur das freigeben, was man auch benötigt. Sprich auch wenn Du alle Länder bis auf Germany freigeben willst, würde man einen Alias mit allen anderen Ländern anlegen und diesen "Allowen".

Jas

Hey,
just an idea: what happens when you create a new VLAN interface? Will this work or has it the same problem as the existing VLAN interfaces?

"no carrier" sounds like he's missing the binding to the physical interface or something like that.

Jas

 :)

I think I found out the root cause: It might be because of some bug with firewall aliases in OPNsense: an alias fails to be completely expanded (it's an network alias where members are also network aliases), thus the firewall rule that should tell OPNsense to use "gw=default" for this destination does not match and it's then the final "gw=multiwan_gateway_group" that matches, ignoring my routing table.

That sounds like a good explanation for this crazy behaviour.  :)
If the alias is not loading properly please check the system logs first.

Just some hints:
Another user in this forum have or had problems with an GeoIP alias which could not be loaded, and therefore all other following aliases were not loaded too.

Another reason could be the max. table entries for the firewall. If the max. count is reached, no more aliases can be loaded. You can rise the count in the firewall settings ( 'Maximum Table Entries' ).

Joh, hast Recht. Ich denke wir dachten beide "Internet" wäre das Ziel, also ein IP Bereich. Aber an der Stelle stehen ja die Services und wenn die kein DNS eingetragen haben, alles gut.  :)

Die Letzte Regel macht vermutlich die oberen zwei überflüssig, dazwischen musst du blockieren.

Nee, dat passt schon so.
Er will ja alle DNS Anfragen die nicht direkt an die OPNsense gehen auf die OPNsense umleiten, und die Redirect Rule steht ja ganz oben. D.h. die Anfrage wird niemals unten ankommen......naja, sollte niemals unten ankommen.

Nur die direkten Anfragen an die OPNsense sollen durchgelassen werden, was die zweite Regel macht.
Die letzte Regel sollte man auf jeden Fall verfeinern. Ein ANY -> Internet ist nicht gut.  :-X


BTW: Wieso nimmt man als Ziel "Firewall" bzw. 127.0.0.1? Der Verkehr bleibt doch eh in dem LAN. Richtg und sauberer wäre es m. E. das Objekt des LAN Adapters zu nehmen, oder?

Die Port-Forward Regel zieht nur, wenn jemand versucht einen anderen DNS Server als die der OPNsense anzusprechen. Daher das !LAN address, also alle Ziele außer der IP Adresse des OPNsense LAN Interface. D.h. wenn Du in Deinem Client die OPNsense LAN Interface als DNS Server eingetragen hast, matcht die PortForward Rule nicht. Somit brauchst Du noch eine Regel die den direkten DNS Traffic auf das Interface erlaubt.

So wie Du es jetzt hast sollte es funktionieren....aber sag Du es uns :)

Wenn Du den Dienst DNS (53) aus der dritten Regel entfernst und DNS danach nicht mehr funktioniert, zieht die zweite Regel aus irgendeinem Grund nicht.

Kontrollier mal die Redirect-Regel ob da alles korrekt ist (Interface, Destination, etc.).
Ansonsten poste mal einen Screenshot.

Hey Don,

wenn bei Dir die Meldung nicht kommt, könnte es ja vielleicht doch funktionieren.
Schau Dir mal die Regel an, die Du für die OpenVPN User angelegt hast. Dort darf kein Gateway angegeben sein da ansonsten der Verkehr nicht auf die Landing Page umgeleitet wird.
Gruß

Jas

Hey,
a host alias should be the appropriate object for your needs. Have you looked into this type of alias? If yes, what`s the error message?

Jas

Hab mal ein Screenshot meiner Regeln für mein GästeWLAN angefügt.

Ich beziehe mich auf die Regeln im Screenshot.
Wenn ein Client im Gäste LAN einen anderen DNS Server (z.B. 4.4.4.4) manuell eingetragen hat und sich die DNS Anfrage auf den Weg macht, passiert bei dem Regelwerk folgendes:

1. Regel matcht nicht, weil das Ziel nicht die OPNsense ist
2. Regel matcht nicht, weil der Service nicht passt.
3. Regel matcht nicht, weil das Ziel nicht passt (ist ja eine öffentliche IP).
4. Regel matcht, weil alle Services zu allen IP Adressen erlaubt wird.

Somit wird DNS ins Internet erlaubt.

Man könnte jetzt eine eine Regel vor der 4. Regel einführen die da lautet:
Source: Gäste LAN
Destination: *
Service: TCP/UDP 53 (DNS)
Action: Deny

Dann würde die DNS Anfrage in Richtung Internet oder auch in alle anderen Subnetze der OPNsense geblockt. Wichtig ist, dass diese Regel nach der 1. Regel kommt. Ansonsten matcht die neue Regel vor der 1. Regel mit dem Allow. Und dann geht gar kein DNS mehr.

Aber @Raccoon ist schon auf dem richtigen Weg. Einfacher ist es ein Portforwarding für DNS einzurichten, und als Ziel den PiHole einzutragen. Dann kann sich jeder DNS Server eintragen wie er will. Sobald eine DNS Anfrage auf der Firewall erscheint, wird die an den PiHole weitergeleitet. Damit erreicht man das gewünschte Verhalten mit nur einer Regel.

Hey,

if nobody has an idea how to solve this, could somebody confirm this behaviour please (in conjunction with OpenVPN and Unbound DNS)? Before I open a new issue, I'll want to ensure that this is not only a misconfiguration of my OPNsense.

Thank you.
Jas