Messages

16

Documentation and Translation / Re: Does the OPNsense manual come in PDF format ?

« on: April 20, 2018, 06:57:03 pm »

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]

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

17

Documentation and Translation / Re: Dockerized "buildsys" for the docs (Sphinx)

« on: April 20, 2018, 06:22:13 pm »

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

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

18

18.1 Legacy Series / Re: .localdomain not being picked up by unbound DNS

« on: April 20, 2018, 12:25:36 pm »

does "system" resolve without the .localdomain suffix?

19

Hardware and Performance / Re: Netgate SG-3100 for 100Mbit WAN

« on: April 20, 2018, 07:50:08 am »

What's your budget? 

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.

20

Documentation and Translation / Dockerized "buildsys" for the docs (Sphinx)

« on: April 19, 2018, 05:18:55 pm »

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]

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

21

General Discussion / Feature request: DHCP options per client MAC address

« on: April 19, 2018, 02:17:24 pm »

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

22

General Discussion / Re: Syslog over TLS

« on: April 19, 2018, 02:02:11 pm »

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.

23

German - Deutsch / Re: PBX-Plugin

« on: April 14, 2018, 03:42:41 pm »

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

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 

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.

24

German - Deutsch / Re: PBX-Plugin

« on: April 13, 2018, 04:51:12 pm »

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.

25

German - Deutsch / Re: Downgrade auf 18.1.5

« on: April 13, 2018, 04:25:40 pm »

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.

26

German - Deutsch / Re: VoIP / siproxd

« on: April 13, 2018, 04:18:16 pm »

Hallo Emma,

zufällig komme ich aus der Branche

<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.

27

German - Deutsch / Re: Log Analyse

« on: April 13, 2018, 04:16:52 pm »

@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

28

Web Proxy Filtering and Caching / Re: OpnSense 8.1.4. - TransparentProxy and SELF-SIGNED certs on Internet web pages

« on: April 01, 2018, 03:01:34 pm »

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.

29

18.1 Legacy Series / Re: CUPS print server for Opnsense

« on: April 01, 2018, 02:35:58 pm »

It is probably not the best idea to install cups on your firewall, given the attack surface it presents.
cups track record doesn't look pretty either.

Your firewall is very much the last thing that you want compromised. Please put cups on a different host.

30

18.1 Legacy Series / Re: IPV6: whats that in squid? dead:beef...

« on: April 01, 2018, 02:29:18 pm »

That address is assigned to the University of North Carolina and resolves to fedoraproject.org:

Code: [Select]

dig fedoraproject.org ANY | grep "dead:beef"
fedoraproject.org. 55 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed3
fedoraproject.org. 55 IN AAAA 2605:bc80:3010:600:dead:beef:cafe:fed9
fedoraproject.org. 55 IN AAAA 2604:1580:fe00:0:dead:beef:cafe:fed1

ERR: (65) No route to host

That is most likely an issue with your v6 gateway.