OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of Reiter der OPNsense »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - Reiter der OPNsense

Pages: [1] 2 3 ... 6
1
German - Deutsch / Re: An API exception occured
« on: April 15, 2019, 06:19:24 pm »
Unter Services: IGMP Proxy ist die Meldung seit 19.1.6 weg, dort wirkt der Fix.

Gruss, Stefan

2
German - Deutsch / Re: Creating resolv.conf alle 15 min
« on: April 10, 2019, 07:08:14 pm »
Hallo Julian,

sieht hier ähnlich aus, ebenfalls mit init7:

Code: [Select]
root@OPNsense:~ # cat /var/log/system.log | grep dhc
[ ]
Apr 10 18:25:37 OPNsense dhclient: Creating resolv.conf
Apr 10 18:25:37 OPNsense dhclient[53161]: bound to XXX.XXX.XXX.XXX -- renewal in 900 seconds.
Apr 10 18:37:42 OPNsense dhcp6c[6317]: Sending Renew
Apr 10 18:37:42 OPNsense dhcp6c[6317]: unknown or unexpected DHCP6 option server unicast, len 16
Apr 10 18:37:42 OPNsense dhcp6c[6317]: Received REPLY for RENEW
Apr 10 18:37:42 OPNsense dhcp6c[6317]: status code for PD-0: success
Apr 10 18:40:37 OPNsense dhclient[53161]: DHCPREQUEST on igb0 to XXX.XXX.XXX.XXX port XX
Apr 10 18:40:37 OPNsense dhclient[53161]: DHCPACK from XXX.XXX.XXX.XXX
Apr 10 18:40:37 OPNsense dhclient: Creating resolv.conf

Ist das überhaupt ein Problem? Funktioniert alles einwandfrei.

Gruss, Stefan

3
German - Deutsch / Re: Suricata will nicht mit URLhaus?
« on: April 10, 2019, 10:44:32 am »
Jetzt geht es auf einmal. An was es genau lag weiss ich nicht.
In jedem Fall muss man nach einer Konfigänderungen immer schön geduldig warten, bis folgendes im LOG auftaucht:
Code: [Select]
suricata: [100145] <Notice> -- all [X] packet processing threads, [X] management threads initialized, engine started.Und nach einer Regeländerung:
Code: [Select]
suricata: [100145] <Notice> -- rule reload starting
URLhaus greift nicht auf WAN, sondern nur auf dem Interface auf welchem die URL aufgerufen wird, bei mir IGB1.

Was mir auch noch aufgefallen ist: Bei Konfigänderungen haut es auf meiner Box oft die WAN-IP raus. Das Gateway ist dann offline. Nur IPv4, die IPv6 überlebt's. Das passiert aber auch ca. bei jedem dritten Neustart. Auch schon vor aktiviertem Suricata.

Konfiguration als Referenz:

Interfaces: Settings
Hardware CRC[X] Disable
Hardware TSO[X] Disable
Hardware LRO[X] Disable
VLAN Hardware Filtering[Disable VLAN Hardware Filtering] (Wenn VLAN im Einsatz)

Services: Intrusion Detection: Administration
Enabled[X]
IPS mode[X]
Promiscuous mode[X] (Wenn VLAN im Einsatz)
Pattern matcher[Hyperscan]
Interfaces[IGB1, WAN]
Home networks[private IPv6-Netzwerke zusätzlich eintragen]

4
German - Deutsch / Re: Suricata will nicht mit URLhaus?
« on: April 09, 2019, 01:02:35 pm »
Vielen Dank, chemlud.
Hab’s jetzt noch mit Aho-Corasick versucht. Verhält sich genau gleich.
Irgendwelche Ideen an was das liegen könnte oder wie ich der Ursache auf die Spur kommen könnte?

5
German - Deutsch / Re: An API exception occured
« on: April 09, 2019, 09:34:45 am »
Hey franco, ich zumindest konnte gar nicht anders denken, weil mir hierzu das nötige Hintergrundwissen fehlte. ;)
Aber vielen Dank für die Info, schon wieder was über PHP gelernt.

6
German - Deutsch / Re: An API exception occured
« on: April 08, 2019, 07:10:16 pm »
Oh, das erklärt dann wohl auch folgende Meldung unter Services: IGMP Proxy?

Code: [Select]
Warning: count(): Parameter must be an array or an object that implements Countable in /usr/local/www/services_igmpproxy.php on line 121

7
German - Deutsch / [Solved] Suricata will nicht mit URLhaus?
« on: April 08, 2019, 07:08:17 pm »
Hallo Leute,
ich beschäftige mich gerade zum ersten Mal mit Suricata auf einer APU2 von PC Engines mit OPNsense 19.1.5_1 drauf.

Der Test mit dem Regelset OPNsense-App-detect/test funktioniert (WAN, Hyperscan, IPS, Alert und Drop). Die Eicar-Signatur wird erkannt, blockiert und unter Alarms erscheint ein entsprechender Eintrag.

Wenn ich das Regelset abuse.ch/URLhaus aktiviere und nach dem rule reload complete eine verseuchte Datei herunterlade (z. B. https://urlhaus.abuse.ch/url/1227/), dann wird diese URL vom IPS durchgelassen und es erscheint kein Eintrag unter Alarms.

Ich habe es auch mal nur im IDS-Modus und mit der LAN-Schnittstelle (IGB1) im promiscuous mode (wegen VLANs) versucht. Verhält sich auch nicht anders.

Funktioniert bei euch Suricata mit URLhaus?

Nach einem Reboot steht folgendes im Log:
Code: [Select]
suricata: [100237] <Notice> -- all 5 packet processing threads, 4 management threads initialized, engine started.
suricata: [100237] <Warning> -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(317)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.
suricata: [100135] <Notice> -- This is Suricata version 4.1.3 RELEASE

8
German - Deutsch / Re: Firewall "härten"
« on: April 07, 2019, 11:51:09 am »
Jetzt wo ich meine Zusammenfassung nochmals lese: ja, ist ziemlich verworren das Ganze. Sorry, dass ich dich zum Seufzen bringe, JeGr. :) Und ein herzliches Dankeschön für deine Zeit und Geduld.

Schwamm drüber und aus die Maus mit "härten". Rein nach dem Motto:
"Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP."
https://docs.netgate.com/pfsense/en/latest/book/firewall/configuring-firewall-rules.html

Und falls noch andere ICMP-Noobs wie ich hier mitlesen und eine Vorlage wünschen, hier bitte sehr:
Ich mach das jetzt so wie seit eh und je plus neu lasse ich auf dem WAN-Interface gewisse ICMP-Typen rein:

ICMP+ICMPv6-LAN-Regeln
Pass,LAN,IPv4,ICMP,Echo Request,Source: LAN net,Destination: LAN address *1
Block,LAN,IPv4,ICMP,Echo Request,Source: LAN net,Destination: RFC 1918 *1
Block,LAN,IPv6,ICMP,Echo Request,Source: LAN net,Destination: RFC 1918 *1
Pass,LAN,IPv4+6,ICMP,any,Source: LAN net,Destination: any

ICMP-WAN-Regeln
Pass,WAN,IPv4,ICMP,Echo Request,Source: any,Destination: WAN address
Pass,WAN,IPv4,ICMP,Destination Unreachable,Source: any,Destination: WAN address *2
Pass,WAN,IPv4,ICMP,Time Exceeded,Source: any,Destination: WAN address *2

ICMPv6-WAN-Regeln gem. https://tools.ietf.org/html/rfc4890#section-4.3
Pass,WAN,IPv6,ICMP,Destination Unreachable,Source: any,Destination: WAN address *2
Pass,WAN,IPv6,ICMP,Packet Too Big,Source: any,Destination: WAN address *3
Pass,WAN,IPv6,ICMP,Time Exceeded,Source: any,Destination: WAN address *2
Pass,WAN,IPv6,ICMP,Parameter Problem,Source: any,Destination: WAN address *2
Pass,WAN,IPv6,ICMP,Echo Request,Source: any,Destination: WAN address
Pass,WAN,IPv6,ICMP,Echo Reply,Source: any,Destination: WAN address *2

*1) Sofern man nicht will, dass lokal alles überallhin pingen kann, z. B. im Gästenetz und in der DMZ.

*2) Ob diese Regeln nötig sind oder durch das "state keeping" abgedeckt sind, kann ich immer noch nicht abschätzen. Zumindest die ICMPv6-Echo-Reply-Regel dürfte nicht viel bringen.
Beispielsweise ein IPv6-Test mit http://ipv6-test.com/ ergibt auch nur mit zugelassenem Echo Request die volle Punktzahl.

*3) Bei den ICMPv6-WAN-Regeln würde noch Packet Too Big (Type 2) dazu gehören, aber das steht bei OPNsense momentan nicht zur Verfügung. Das dürfte aber nicht tragisch sein, denn Type 2 (wie auch Type 1 Destination Unreachable) ist standardmässig frei gegeben, sofern ich die erste der folgenden Regeln richtig interpretiere:
Code: [Select]
root@OPNsense:~ # cat /tmp/rules.debug | grep ipv6-icmp
pass in log quick inet6 proto ipv6-icmp from {any} to {any} icmp6-type {1,2,135,136} keep state label "IPv6 requirements (ICMP)"
pass out log quick inet6 proto ipv6-icmp from {(self)} to {fe80::/10,ff02::/16} icmp6-type {129,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {ff02::/16} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"

9
German - Deutsch / Re: Firewall "härten"
« on: April 01, 2019, 04:46:26 pm »
Ich versuche mich mal mit folgender Zusammenfassung:
  • Man muss sich bei der Sense nicht um ICMP-Firewallregeln kümmern, weil sich das "state keeping" um alles Nötige kümmert. (Erlaubte, aufbauende Verbindungen erhalten allfällige ICMP-Antworten in jedem Fall.)
  • Einzige Ausnahmen sind "Echo request" zulassen, wenn ein Interface oder etwas in einem Netz pingbar sein soll und "ICMPv6 Router Advertisement" + "ICMPv6 Router Solicitation" zulassen, wenn IPv6 im Einsatz ist.
  • Die generelle Empfehlung (u. A. vom BSI) "ICMP redirect" ausgehend zu blocken, wird von der Sense per "tunables" umgesetzt. (Allerdings erst ab 19.1.3: https://forum.opnsense.org/index.php?topic=11941.msg54462#msg54462
    Ich musste unter System: Settings: Tunables noch auf Default klicken, damit dieses tunable angezeigt wurde.)
  • ICMP kann per Firewallregeln nicht geblockt werden.
Habt ihr Einwände oder Ergänzungen?

10
German - Deutsch / Re: Firewall "härten"
« on: March 27, 2019, 03:20:54 pm »
Oh, ich bin jetzt gerade noch über diesen Thread hier gestolpert:
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955

Wenn ich das richtig verstanden habe und die Analyse von @indyspeed stimmt, dann sind zumindest meine abgehenden Regeln eh für die Katz. :(

11
German - Deutsch / Re: Firewall "härten"
« on: March 27, 2019, 03:05:04 pm »
> Auf dem WAN würde ich Echo Request noch erlauben.

Für welchen Verwendungszweck? Die einzige Idee, die mir in den Sinn kommt, ist dass ich auf dem WAN-Interface nach Innen Pingen könnte und das will/brauch ich eigentlich nicht?

> Destination any würde nur etwas bringen, wenn du public IPs bspw. in einer DMZ oder so noch hättest, ansonsten würde ich das auf WAN Address oder This Firewall einschränken.

"Normale Rechner" im Netz profitieren davon nicht? Ich bin unsicher wie das BSI das genau meint. Eigentlich habe ich das so interpretiert, dass man Typ 3 und 11 komplett auf alle Rechner durchlassen darf/soll.

> Auf dem LAN: wenn du vorher explizit RFC1918 wegfilters durch Blocks und Passes, kannst du dahinter eigentlich "any" nutzen

Sorry, aber ich verstehe nicht was du meinst. Gibt es eine elegantere/bessere Lösung?

12
German - Deutsch / Re: IPv6: Wie kann man den aktuellen Präfix in Firewall-Regeln referenzieren?
« on: March 27, 2019, 12:16:03 pm »
Ich weiss nicht ob ich IPv6 als "richtig" bezeichnen will, wenn es NUR mit dynamischen Präfixen ausgeliefert wird. Das sieht mir eher nach von ISP-Marketingabteilungen kaputt gemacht aus. Aber um das soll sich die Diskussion hier nicht drehen.

Ist auf franco’s "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620

Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?

13
German - Deutsch / Re: IPv6: Wie kann man den aktuellen Präfix in Firewall-Regeln referenzieren?
« on: March 26, 2019, 07:06:14 pm »
Also kann man die Aussage wagen: Sobald mehrere Subnetze im Einsatz sind, dann ist "richtiges" IPv6 Pflicht? (Ausser man will basteln oder nur IPv4 verwenden.)

Man sollte die ISPs verpflichten, dass zumindest auf Anfrage ein statisches Präfix zur Verfügung gestellt werden muss. Und das kostenlos und nicht nur bei "Business-Anschlüssen". Hätte man gleich in den Standard mit einbauen sollen und bei Zuwiderhandlung muss der Laden schliessen oder so. :)

14
German - Deutsch / Re: Firewall "härten"
« on: March 26, 2019, 06:42:30 pm »
Vielen Dank, soweit begriffen. Sind folgende Regeln für die Umsetzung korrekt? Nur mal IPv4.

Pass,WAN,IPv4,ICMP,Destination Unreachable,Source: any,Destination: any*
Pass,WAN,IPv4,ICMP,Time Exceeded,Source: any,Destination: any*
*Oder Destination irgendwie einschränken?

Pass,LAN,IPv4,ICMP,Echo request,Source: LAN net,Destination: LAN address
Block,LAN,IPv4,ICMP,Echo request,Source: LAN net,Destination: RFC 1918*
Pass,LAN,IPv4,ICMP,any,Source: LAN net,Destination: RFC 1918
Pass,LAN,IPv4,ICMP,Echo request,Source: LAN net,Destination: ! RFC 1918
Pass,LAN,IPv4,ICMP,Destination Unreachable,Source: LAN net,Destination: ! RFC 1918
Pass,LAN,IPv4,ICMP,Time Exceeded,Source: LAN net,Destination: ! RFC 1918
*Sofern ich nicht will, dass lokal alles überallhin pingen kann.

15
German - Deutsch / Re: Firewall "härten"
« on: March 26, 2019, 11:53:17 am »
> Warum Kompromiss? Von außen mit v4 echoreq, timex, squench, unreach aufmachen IST ja "was gebraucht wird". Mehr brauchts nicht. Intern dann ggf. alles (oder viel) aufzumachen sehe ich als kein Problem an [ ]

Ich glaube ich hab’s jetzt begriffen (bitte nicht hauen und nicht lachen, ich sehe mich immer noch als Netzwerkanfänger): Bei den Empfehlungen in all den verlinkten Artikeln geht es immer nur um die Schnittstelle zwischen internem und externem Netz. Beim BSI ist das schön verständlich beschrieben, finde ich:
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05120.html

In diesem Artikel wird für öffentliche Server in der DMZ ebenfalls Source Quench (Typ 4) ankommend zulassen empfohlen. Gemäss Wikipedia (und OPNsens-WebGUI) ist das veraltet.
"Since research suggested that "ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion",[9] routers' creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633."
Quelle: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Source_quench

>>> Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.
>> Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?
>Mein Fehler, natürlich beim Traceroute bei der TTL. Genau, deshalb "timex" von außen erlaubt.

Ich war/bin verwirrt, weil ein Traceroute intern funktioniert (Host von einem VLAN auf Host in einem anderen VLAN), auch wenn ich ICMP Time Exceeded zu Testzwecken explizit blocke. Darum auch ich die Frage, ob die Sense standardmässig gewisse Dinge durchlässt. Allerdings sollte sie das ja spätestens bei einem expliziten Block nicht mehr tun, vermute ich jetzt mal.

Pages: [1] 2 3 ... 6
OPNsense is an OSS project © Deciso B.V. 2015 - 2021 All rights reserved
  • SMF 2.0.17 | SMF © 2019, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2