Messages

Huhu und Willkommen an Board!

Unter OPNsense lässt sich das mit Squid realisieren:
https://docs.opnsense.org/manual/how-tos/proxywebfilter.html

I don't think that's possible on OPNsense, or advisable either.
Messing with the hosts file isn't a good idea IMHO, unless you absolutely want to hijack a hostname on one machine.

Resolving possible adverse domains as an loopback IP is a terrible idea, for many reasons. Letting your Firewall do that is even worse.
Loopback traffic is, more often than not, trusted absolutely.

Consider pi-hole (no, it does not require an raspberry pi).
It let's you use multiple upstream DNS providers (with DNSSEC *and* DNS-TLS no less), enables you to do extensive audits (names resolved per host), it imports pretty much any listformat you want to feed it. And as a cherry on top: you can actually analyse the traffic that would have went to the these domains otherwise.

It's absolutely marvelous. And has a very nice webinterface.

In my setup I use pi-hole as my only egress DNS service. Even my OPNsense resolves via pi-hole.
Unless an host in my domain is resolved. Then the pi-hole forwards the request to the OPNsense unbound.

I have two redundant pi-holes that are being offered as DNS servers via DHCP Options.

This has major advantages. Think about it this way: no program or app is actually forced to use the OS (and it's settings, i.e. hosts-file) for domain resolution. Sure it's best pratice. But if I wanted to exfiltrate your ... cat pictures from your network or serve you malware?
I'd implement an resolver in my program / dropper, rendering your hosts-file (or other DNS resolvers) moot.

With my setup I can block all DNS traffic to WAN, that doesn't originate from either pi-hole (and have Surricata block / flag traffic on non-standard ports). In fact, I treat that traffic as an IoC (indicator of compromise, i.e. active malicious program or actor on my network).

it may render PDF but for now we concentrate on the web export so no idea if it works as is.

No dice:

Code Select Expand

root@0d623f0a4bd5:/docs# make latexpdf
[...]
! LaTeX Error: Something's wrong--perhaps a missing \item.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
...                                             
                                                 
l.100 \subsection{Debunking the Myths}

EPUB works fine though. I converted that into PDF:
https://drive.google.com/drive/folders/1m6GPNF1L6jLF6XVL3rJUkl-9nQ5ORySd?usp=sharing

Actually I don't know the prerequisites, because I wasn't previously involved in the docs build process

I feel your pain  ;D
I just went for the latest stale stable Versions in the jessie repositories. Python 3.6 and Sphinx 1.7.2

does "system" resolve without the .localdomain suffix?

What's your budget?  ;D

I'd recommend taking a look at Deciso's appliances:
https://www.applianceshop.eu/security-appliances/19-rack-appliances/opnsense-based.html

They will be working "100%" with OPNsense, since Decisio is maintaining this fork  ;)

For a lower budget, take a look at the Desktop appliances, although I wouldn't recommend any of the dual-cores (they are single threaded):
https://www.applianceshop.eu/security-appliances/security-appliances-desktop-and-wallmountable/opnsense-based-desktop-9.html

Edit:
I'm currently running an Intel Atom 2x 1,8GHz (4 threads), 3GB RAM and 2x 1 GbE. My "edge" is VDSL with 100Mbit downstream and 40 up.
Currently I'm actively using:

• IDS only (IPS might be more taxing AFAIK)
• OpenVPN
• ZeroTier
• DHCPv4/6
• Squid
• and the mp5d as PPPoE dial-in (which I'm not happy about)

Over the past weeks my load avg was never above 1.5 during normal operations. It hit's ~3 on the nightly suricata definition updates though.
I've had to disable the local Netflow. The disk (mSata SSD) was the bottleneck here, creating IOWAIT-situations.

Heya!

So I wanted to give the documentation some love (sidenote: reStructuredText is an awful markup) but found myself unwilling to install Sphinx in order to get previews.
Then it hit me. This is what Docker was made for.

The result is this:
https://github.com/Alphakilo/opnsense-sphinx-doc-docker
https://hub.docker.com/r/alphakilo/opnsense-sphinx-doc/

Now instead messing around with python and its dependencies you can run

Code Select Expand

docker run --rm -v ~/src/docs:/docs alphakilo/opnsense-sphinx-doc:latest and enjoy your build.

I have a few questions about the "official" build process, since I couldn't find resources about that.
What version of Sphinx and Python is used to build for docs.opnsense.org?

I don't want nasty surprises regarding parsing or formatting that may be depending on the Sphinx version, or some stupid library.

Regards

Hi!

IDK if this is the right place to state a feature request, but I couldn't figure out where to do that, so here we go:

I'd like to serve DHCP clients different Options based on their MAC address. Specific addresses or parts ("begins with", i.e.: vendor prefixes).

My use case is this: I have VoIP-Phones from multiple vendors. They require different DHCP options to do auto-provisioning.
Sometimes the same option is used for different values by different vendors or models.

Right now I'm forced to use different interfaces (VLANs) in those cases, which I'm not happy about.

Regards

And do authentication for that matter?

That's one of my reoccurring nightmares: A compromised / spoofed syslog sink that gives adversaries real time feedback on their moves.

Full disclosure: Mein Arbeitgeber stellt eine kommerzielle VoIP/ISDN-Lösung auf Asterisk-Basis her. Das ist aber nicht der Hintergrund warum ich dich bitte dein Vorhaben zu überdenken. Ich bin hier in privater Funktion. FOSS ist mein kink ;D

Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.    :)

Ich habe es so Verstanden das du einen Kamalio vor einen Asterisk setzt um eine vollständige PBX (ohne DAHDI ;)) zu implementieren. Inklusive Provisioning von Endgeräten. Und Providertemplates. Im Kontext einer Firewall.

Ich warte auf dein Konzept, aber mein Bauchgefühl sagt mir das die Ziele sehr hoch gesteckt sind, unabhängig von deiner oder mimugmails Expertise (die ich nicht anzweifle). Es geht mir um die reinen Mannstunden. Und den Sicherheitsaspekt. Jail hin oder her, die Attacksurface vervielfacht sich. Müssen ja auch nicht direkt RCEs sein.

Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]

Das hat nur leider niemand den Providern erzählt  :P

So was wie RFC3261 und 3550 / 4566 wird (meist) eingehalten. Da gebe ich dir Recht. Mir geht es eher um die Vermittlung (pots / inter-provider) und Signalisierung.

Ein Beispiel das ich gerne nehme sind Nummernformate. Welches Format soll die Zielrufnummer haben? Wie unterscheidet es sich lokal, national, international (das Unterscheidet sich auch nochmal per Provider und Zielregion)? Der Brüller: Nationale Sonderrufnummern.

In welchem Header wird die CLIP erwartet? PAI? PPI? Oder doch lieber FROM?
Wie signalisiere ich CLIR? Redirection / reflection?

¯\_(ツ)_/¯

Und dann die Fehlermeldungen... Was kommt bei Besetzt / Rejected zurück? Ungültige Rufnummer? Gesperrtem Account?
Am tollsten sind die Provider die Munter im Fehlerfall mit 200 OK antworten und eine Sprachnachricht über RTP drücken.

Ich kenne keine zwei Provider welche identische Spezifikationen befolgen. Es ist nicht mal garantiert das die Spezifikation innerhalb des selben Providernetzes konsistent sind.
SIP INVITES kommen mit führender +49... von dem einen SBC, 49... von dem nächsten und drei Tage später mit 0..., dann komplett ohne Präfix vom dritten SBC.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Tun sie nicht! Warum? "Die PBX ist schuld!" Es ist immer, grundsätzlich die PBX.
"Oh. Keine Fritz- / Digitalisierungsbox? Kein Support. Ach du willst nur die Specs? Die kann ich dir nicht geben. Kauf dir lieber die supportete™ PBX©".

Selbst wenn man einen PCAP mit RFC violations (INVITE nach 407 ohne Hash wiederholt, 407 Response ohne NONCE, unilateraler Codecwechsel ohne SDP, COMEDIA ignoriert, ...) vorweisen kann wird es im besten Fall still und heimlich gefixt und ohne Ankündigung ausgerollt. Schuld bleibt *drumroll* die PBX. Es wird gelogen, getrickst und intrigiert. Bis jemand weint.
Zugegeben, es gibt Provider die sehr transparent Arbeiten. Mit denen es Spaß macht solche Fehler auszuräumen. Der staatlich geförderte Monopolist ist keiner davon.

So. Ich gehe jetzt erst mal einen Kaffee trinken um von meinem Nerdrage wieder runter zu kommen. Hoffe ich konnte meine Punkte rüber bringen. Ich will euch nichts böses.

Jungs... Ich will nicht meckern. Das wäre sicher Ruhmreich. Aber ihr übernehmt euch da gewaltig.
Ich kenne Firmen die eigene Teams allein für Providerintegrationen unterhalten.

Die VoIP-Protokolle (SIP / RTP) sind für fast alle Provider eigentlich nur lose Richtlinien. Je größer der Provider desto schlimmer der Protocolabuse.

Was ich sagen will: Das einmalig zu coden ist die eine Seite. Maintainen eine ganz andere Hausnummer.

Ich finde die Idee wirklich charmant, aber ich sehe keine Möglichkeit das in irgendeiner Weise sicher und langfristig stabil zu implementieren.

Falls ihr euch doch dazu entscheidet das durchzuziehen, meldet euch doch nochmal bei mir. @mimugmail hat meine Emailadresse.

Hi Pascal,

# opnsense-revert -r 18.1.5 opnsense

Das Fehlerbild klingt allerdings untypisch.


Grüsse
Franco

Ich habe etwas ähnliches beobachtet. Nach dem Update haben die verlinkten NAT Regeln nicht mehr funktioniert.
Sie waren wohl noch in der Übersicht des jeweiligen Interfaces, haben aber einfach nicht mehr funktioniert. Wurden auch brav als "blocked" geloggt.

Ich musste eine Änderung an den NAT Settings vornehmen, speichern, dann lief alles wieder.

Hallo Emma,

zufällig komme ich aus der Branche ;D

<OT>Mach' dir keine Sorge wegen der DTAG, ich kenne niemanden der keine Probleme mit denen hat.
Nach meiner Erfahrung sind weder die Spezifikation der Produkte noch deren Plattform stabil.</OT>

Deine Frage ist nicht trivial zu beantworten und ist stark abhängig von deiner Infra und deinen Providern.

Ich denke in deinem Setup dient der SIPROXD als Gegenmaßnahme zu NAT.
Ich muss an dieser Stelle gestehen das ich SIPROXD nie eingesetzt habe, da mein PBX völlig ausreichend ist.

Grob vereinfacht: Wenn du nur von einem einzigen Gerät in deinem Netzwerk eine SIP Registrierung durchführst, würde ein Port-Forwarding im NAT ausreichend sein. Dann musst du dich allerdings mit Angriffen direkt an deiner PBX rumplagen (SPAM-over-IP-Telephony aka SPIT, Callback Scams und Brute-Force-Angriffen auf deine Accountdaten um damit Premiumnummern anzurufen...).

Um dem entgegenzuwirken solltest du prinzipiell nur authentifizierte eingehende INVITES zulassen.

Als Hintergrund vom SIPROXD: deine Provider sehen ja alle nur die eine öffentliche IP von dir, welche im Register angegeben wurde.
Dorthin werden alle eingehenden Anrufe (SIP INVITES) gerouted. Der SIPROXD dröselt das jetzt auf, also welcher INVITE an welchen internen Host gerouted werden soll (nicht unähnlich dem was HAProxy macht  ;))

Das könnte man mittels der RPORT-Option im INVITE umgehen, a.k.a jedes Gerät benutzt einen anderen Port für SIP.
Dann hat man aber immer noch das Problem das die Mediastreams (RTP) auch noch Ports benötigen (welche während des SDPs dynamisch ausgehandelt werden)...

Bitte behalte auch noch im Hinterkopf das es absolut trivial ist VoIP-Traffic zu belauschen oder im Transit zu verändern.
Für ersteres braucht man nur Wireshark und eine lauschige Position im Netzwerk.

@Alphakilo tolles dashboard hast du da.
Würde mich darüber freuen, wenn du die Kibana-Konfigs dazu gibst und ggf. einen Artikel für docs.opnsense.org daraus machst.

Hi fabian!

Ich habe mich nun endlich dran gemacht mal meine ELK-Config zu bereinigen um sie als Beispiel zur Verfügung zu stellen.
Jetzt stehe ich vor einem Problem: deine GitHub-Repo von der ich ursprünglich angefangen habe verfügt über keine klare Lizenz...

Streng genommen hätte ich so nicht mal forken dürfen.  ::)
Wäre es ein Problem für dich eine Lizenz anzugeben?

LG

Unfortunately, true, but I can't force security over business demands, because it stops business in this case.
[...]
I have other layers of security that are in force, this is serving me only for web trafic filtering, so it is acceptable for me.

What's the business demand here? Getting pwned?
I suspect you're the sysadmin. So here's a word of unsolicited advise:

If your boss comes to you and asks you to implement shit like this, you tell her / him (in writing, i.e. email) what's it going to cause.
In this case: whatever security that may come from PKI being nullified. The TLS / SSL clients (browsers, email clients, updates, ...) will now happily accept anything *any* adversary will throw at them. There is no reliable "layer of security" that covers this. This is why TLS / SSL faults hurt that much.

Only after the boss fully acknowledges that and asks you continue (in writing) you do that.
Print the full conversation (including headers) and take it somewhere safe (i.e. home).

This is known in the industry as "cover your ass". For the setting you implemented you *need* to do that.
Godspeed.

Oh and if your intent is to only do filtering (no caching, no ICAP) please check if the forward proxy setting "Log SNI information only" without any other modification isn't exactly what you need.