Messages

271

German - Deutsch / Re: Hardware Vergleich - Was ist für Euch zu Hause sinnvoll? Was nutzt ihr?

« on: January 25, 2017, 09:07:04 pm »

Ansonsten sind die APU2s sicher wohl das was man als günstigste Alternative zu Hause bekommen kann. Ein wenig kleiner und kompakter, dafür aber auch etwas teurer wäre da nur noch eine NCA-1010 von Lanner, die vergleichbar mit der APU2 arbeitet. Deren Nachfolger, die 1020 steht übrigens in den Startlöchern und bringt dann als SOC einen Braswell N3010er Zweikerner mit. Sollte sich dann doch etwas von der APU2/3 abheben können dadurch und ein wenig in die Lücke zu den Atom C2358/C2558 SOCs stoßen.

Ich hatte mir vor ca. 5 Jahren eine Lanner FW-7535 gekauft (viel zu teuer eigentlich aber 6 Intel Interfaces + Rackmount waren ZU verführerisch...) und die wird nun nach der langen Zeit wohl demnächst durch eine 7525 abgelöst - wieder mit 6 NICs und einem Atom C2558 drin. Der dürfte dann auch für Kabelnetze von 400MBit/s aufwärts keine Probleme bekommen Etwas übertrieben? Ja, für reinen Home-use schon, allerdings hab ich da tatsächlich auch mal Testnetze, Testsetups und mein eigenes Heimsetup dran, das etwas komplexer aufgebaut ist Daher durchaus legitim.

Gerade mal angeschaut und das 7525 is ja en absolutes Flaggschiff. Wenn Geld keine Rolle spielen würde und man für dieses Monster nicht jemanden für ausrauben müsste (600€ !!!) hätt ich das ohne mit der Wimper zu zucken gekauft, obwohl mich das "x86" und die Tatsache, dass keine SSD verbaut wurde schon etwas stutzig macht...

die NCA-1210 wär hammer mit 4x intel LAN Ports aber kein AES-NI
(Oder hab ich mich verlesen und das Ding kann Intel® AES-NI?)

NCA-1010 bzw NCA-1020 haben nur 3x intel LAN Ports ..... einer zu wenig

Ich möchte den Thread hier nicht klauen, bzw. an mich reißen, aber da ich wie ne0h wahrscheinlich auch an einer Hardware Lösung mit 4 LAN Ports interessiert bin.... kannst du da etwas empfehlen?

Was die Kiste können muss:
- Prozessor und LAN Ports von Intel
- Fanless
- Intel® AES-NI unterstützt
- SSD verbau und nutzbar
- 4x LAN Ports (LAN, WLAN, WAN, DMZ)

Einer ne Idee?

272

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 22, 2017, 02:59:22 pm »

Hey hey,

Fehlt da etwas "grundlegendes", das ich gerade vergesse?

Das kannst du nur herausfinden, indem du deine Regeln auf die Probe stellst.
Welche Verbindung sollte denn anhand deiner Regeln nicht mehr funktionieren?
Wenns dann doch klappt musst du dir überlegen warum.

1. Sollte man die Anti Lockout Rule nicht noch spezifischer machen? Die war ja standardmäßig angelegt. Sollte die nicht spezifisch als Source das LAN und WLAN Subnetz haben?

Die Antilockout Regel, also die Regel zum Schutz davor dich selbst auszusperren, hat nur einen Zweck.
Sie soll dafür sorgen, dass du aus deinem Management Subnetz, von welchem du auf die GUI zugreifst, immer Zugriff auf die Weboberfläche hast. Gerade am Anfang beim formulieren der Regeln, kann es schnell passieren, dass man eine Regel schreibt, die dich aussperren würde.
Im Idealfall hast du am Ende diese Regel deaktiviert und mit einer Regel ersetzt, die angemessener erscheint.

Beispiel Regel für das LAN Subnetz:
PASS --> KonfigurationsLaptop (statische IP) --> LAN Interface (WebGUI) --> Port 443 und 22
~ In diesem Fall würde dann nur noch ein Laptop aus deinem LAN Subnetz auf die Weboberfläche zugreifen können und über SSH auf die Shell.

hattest doch mal den Hinweis gepostet, dass man die NetBIOS Ports dicht machen sollte bei Windows Maschinen.

Genau. Innerhalb deines internen Netzes kann es ja gut und gerne sein, dass man die vielleicht mal braucht. Wichtig ist nur, dass diese nicht ins "äußere Netz / Internet" kommunizieren, was sie im Normalfall sonst machen.
Sind deine Regeln speziell genug formuliert hast du dieses Problem nicht.
In Firmennetzwerken schreibt man diese Regeln trotzdem hin,
einfach nur um sagen zu können: "ich hab sie hingeschrieben".

Ich überlege auch momentan, ob es jetzt Sinn macht, dass ich im WLAN Subnetz die Kommunikation auf Clients beschränke

Das ist abhängig von deiner Bequemlichkeit, davon abhängig wie oft dein Netzwerk sich ändert und ebenfalls davon abhängig wie groß dein Netz ist. Wenn es eine Regel gibt, die so oder so alle Geräte innerhalb eines Subnetzes benötigen, wäre es ja unsinnig diese eine Regel auf 20 Geräte zu verteilen.

wenn ich hier Gäste habe, die ich in mein WLAN lasse, müsste ich dann immer explizit freischalten. Was logischerweise dazu führt, dass man ein Gästenetz aufspannt.

Gäste haben in deinem WLAN nichts zu suchen. Die Frage nach Freischaltungen erübrigt sich dann.
Man macht ein Gästenetz auf, gibt ihnen einen Vouchercode und das wars. Das Gästenetz trennst du dann hart von deinen anderen Subnetzen und lässt ihnen da drinne ihren Freiraum für was auch immer.
(Um Quengeleien zu vermeiden)

Zum Thema Proxy hatte sich monstermania ja schon des öfteren zu geäußert.
Das ist abhängig davon, was du am Ende bei deinem Anwendungsfall bezwecken möchtest.
Das ist auch ein sehr OPNsense unspezifisches Thema.
Da gibt es sicher gute Pro/Contra Listen im Internet die dem Thema da kleinlichst auf die Spur gehen.
Mit nem Proxy kann man halt wieder zusätzlich viele "spaßige" Dinge machen um das Leben der Anwender "vielleicht" zu erschweren. Im Gegensatz dazu dient es als Möglichkeit der Überwachung (SSL-Proxy).
Wenn du alleine in deinem Netz bist, würde ich natürlich all das aufbauen, wozu ich Lust und Laune habe.
Mich selber Man-in-the-middle mäßig anzugreifen stört mich ja nicht.
Ob Freunde, WG Kumpels, Eltern oder wer auch immer noch in deinem Netz hängt davon so begeistert sind wage ich zu bezweifeln.

Schöne Grüße
Oxy

273

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 20, 2017, 08:50:37 am »

Ich habe z.B. gedacht, dass eine Firewall dann an letzter Stelle, also am Interface, an dem es raus ins Internet geht, eine Art Indextabelle (Lookup table) führt, die auf Basis der package inspection und der Details pro Paket entscheiden kann, ist das ein Datenpaket für das interne Netz (IP Bereich, Subnetzmaske, etc.) oder   geht es raus in ein "anderes" Netz. Aber das wird schon seinen Grund haben, warum das nicht geht.

Natürlich geht das. Du musst bloß deine Regeln dementsprechend formulieren...
Die "Lookup Tabelle" ist ja genau dein ausformuliertes Regelwerk.
ANY heißt halt nun mal ALLES...
Nich böse gemeint, aber wenn du selber nicht weißt wie dein Traffic ins interne Subnetz soll, woher soll die Firewall das dann wissen? Wenn du sagst "erlaube alles nach HTTP", kann die Firewall doch nich Gedanken lesen und "erahnen" was du wirklich meintest.
Deshalb sind die Formulierungen der Regeln ja auch mit das Schwerste und Wichtigste an einer Firewall.

Willst du noch mehr Kontrolle und tatsächlich in JEDES Datenpaket schauen um JEDEN Dateninhalt auszulesen, musst du dir eine Firewall suchen, die ein sogenanntes "Deep Packet Inspection" betreibt.
In der Türkei wird so zurzeit verhindert, dass Leute VPN Server oder Tor Services ansprechen können.
Ziemlich mächtiges Tool, mit der Einschränkung, dass du als Administrator so einer Firewall dann natürlich 24/7 arbeiten musst, um saubere Regeln zu formulieren.
Völlig sinnfrei also für ein Home Netzwerk. SPI ist schon das sinnvollste was man zurzeit machen kann.
Weiteres zum Nachlesen hier: http://www.itwissen.info/definition/lexikon/DPI-deep-packet-inspection.html

Jau. Ich werde mir das angewöhnen, so spezifisch wie möglich zu sein bei den Regeldefinitionen und dann (wie Du geschrieben hast), nach unten hin die "lockeren" Regeln zu schieben.

Genau. Die Chance, dass man dann was übersehen hat ist halt eingegrenzt.
Wichtig ist am Ende immer eine Art Testprotokoll zu führen. Du schließt also Geräte an die jeweiligen Subnetze an und versuchst deine eigenen Regeln auszutricksen/zu testen und schaust ob das erwartete Ergebnis rauskommt.
Falls nicht versuchst du deine Regeln so umzuformulieren, dass es passt.
(Diese Stelle hasse ich immer )

Zu Sonos kann ich dir leider gar nichts sagen, da ich da keine Erfahrungen mit machen konnte.
Kann dir also nich sagen was man da machen kann oder sogar sollte.
Wegen den Regeln würde ich erst einmal alle hinschreiben, probieren ob alles funktioniert und dann Regel für Regel deaktivieren und schauen, ob es immer noch funktioniert.

Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben?

Ich bin mal ganz frech und sage "na klar"
Das meintest du wahrscheinlich nicht, aber du kannst dir ja bei "Services > DHCP > Leases" die ausgegebenen IPs anzeigen lassen. Da müssten dann auch deine gemappten Einträge zu sehen sein z.B.

Wie seht/scannt/findet ihr denn alle eure Geräte, die in unterschiedlichen Subnetzen unterwegs sind?

Stichwort: Network Monitoring, bzw. Systembetriebs Überwachung.

Dafür gibt es zich Lösungen die eingesetzt werden um irgendeine Art "Übersicht" zu behalten.
Du könntest einen Syslog Server in dein Netz hängen, der alle Logs sammelt und verarbeitet.
In der Art weißt du zu mindestens etwas über deine Switche, Router und deine OPNsense Firewall.
OPNsense kannst du nämlich hier: "Services > SNMP" so konfigurieren,
dass es Nachrichten für deinen Syslog Server erstellt.

Dann gibt es noch Nagios (sehr wahrscheinlich viel zu umständlich für ein Home Netzwerk), mit welchem du echt ALLES bewerkstelligen kannst, wenns um Überwachung geht.
Eine einfachere Alternative wäre hier: Check_MK | siehe: https://mathias-kettner.de/check_mk.html

In Firmen kommt oft eine CMDB (Configuration Management Database) zum Einsatz:
"Ziele des Configuration Management sind:
Auskunft über alle IT-Komponenten und -Konfigurationen innerhalb des Unternehmens und seiner Services zu geben."
Auch das finde ich völlig sinn frei für ein Home Office, aber "möglich" wäre es.

Wie gesagt zum Rest kann ich nich viel sagen. Sorry!

Schöne Grüße
Oxy

274

16.7 Legacy Series / [SOLVED] NRPE 2.15 - Socket Timeout After 10 Seconds

« on: January 19, 2017, 01:46:53 pm »

Hey guys,

i am troubleshooting since 2 days now and i can't see the light at the end of the tunnel.

What i try to accomplish is to led my Nagios Server talk to my OPNsense over TCP 5666 and let the Firewall talk back and give some feedback about "average load", "root folder", tcp check and some other services like ntp, ssh and icmp.

What i did was the following:
- install nrpe out of the repository.
- cp /usr/local/etc/nrpe.cfg-sample /usr/local/etc/nrpe.cfg
- changed allowed hosts inside of nrpe.cfg and put in the ip of my Nagios Server + 127.0.0.1.
- created a firewall rule (floating Rule - first match) accepting incoming traffic on port 5666
(To make sure that rules are not the problem, i kinda changed the rule to "PERMIT ANY ANY port 5666" over time)
- enable NRPE by doing: ee /etc/rc.conf --> nrpe2_enable="YES"
(Btw... is it normal that the file was not there from the beginning?)
- chown -R nagios:nagios /usr/local/libexec/nagios/
- insert into /etc/services --> nrpe     5666/tcp  # NRPE
- inside /etc/hosts.allow i put in two rules (because i wasn't sure about the syntax)
nrpe : xxx.xxx.xxx.xxx/255.255.255.0 : allow
and
nrpe : xxx.xxx.xxx.xxx/24 : allow
- sudo /usr/local/etc/rc.d/nrpe2 start
- ps 40630
output:  PID   TT  STAT    TIME           COMMAND
            40630  -     Is       0:00.00     /usr/local/sbin/nrpe2 -c /usr/local/etc/nrpe.cfg -d

Things i did to troubleshoot my problem:
- From Nagios: telnet <remote_ip> 5666 ---> worked
- From Nagios: nmap <remote_ip> ---> was able to see open Port 5666
- tried doing the "-t 20" trick which did not change anything.
- From OPNsense: /usr/local/libexec/nagios/check_nrpe2 -H localhost ---> "NRPE 2.15" as response
- ps -aef | grep nrpe --> gives me no response
- ps ax | grep nrpe --> gives me:
40630  -  Is     0:00.00 /usr/local/sbin/nrpe2 -c /usr/local/etc/nrpe.cfg -d
44893  0  S+     0:00.00 grep nrpe
- From Nagios: using a check command while watching the traffic with Tcpdump.
Nagios sends 4 packets but is not getting any answers back from OPNsense.
- i watched the Firewall Log while Nagios was sending the packets but there were no entries made in the meantime.

My Problem:
- Socket Timeout After 10 Seconds

Nagios is able to check_<anything> from other remote Hosts already. For the other clients they are all using 2.13 instead of 2.15, which OPNsense is using. The issue must be something regarding the OPNsense version 2.15 which i can't find...

Did anyone ever had any trouble installing NRPE into OPNsense and can tell me what i may forgot to configure?

Best regards and thank you very much in advance
Oxy

275

German - Deutsch / Re: traffic shaper: Reihenfolge wird nicht beachtet

« on: January 19, 2017, 08:18:57 am »

Hey hey,

Ich hab auch nicht wirklich ne Idee woran es liegen könnte, aber bei mir konnte ich eine 5 Mbps Limitierung für den Download und den Upload gewährleisten.

Da die Sequences bei dir überhaupt nicht greifen, kann es sein, dass du vielleicht noch überhaupt gar keine Pipes erstellt hattest? Viel mehr musste ich nämlich auch nicht machen. 

Für einen 5 Mbps Download Limit hab ich also folgendes gemacht:

Für die Pipe:
Enabled: check
Bandwidth: 5
Metric: Mbit/s
Mask: source
Description: 5 Mbps Limit Download

Für die Rule:
Sequence #: 11   
Interface: WAN   
Protocol: ip
Source: any   
Destination: any   
Target: 5 Mbps Limit Download   
Description: Download Rule

Wenn du das schon bereits hast dann weiß ich leider auch nicht weiter. Sorry!

Schöne Grüße
Oxy

276

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 18, 2017, 01:12:46 pm »

Sprich, vereinfacht sieht das so aus:

1. DENY source:WLAN net -> destination: LAN net -> port: any
2. PASS source:WLAN net -> destination: any -> port: HTTP/HTTPS

Korrekt?

Genau. Die Firewall vergleicht Source und Destination IP im ankommenden Paket und sieht das du z.b. auf Port 443 zugreifen möchtest. Dadurch, dass du vor der Destination ANY Regel aber diese durch die Regel davor eingegrenzt hast, würde diese DANN nicht greifen WENN im Destination Feld eine IP aus dem LAN Netz steht.

Darauf folgt dann die Regel Nr. 2, die Firewall lässt die Kommunikation vom WLAN Netz über Port 80 und 443 in ALLE Netze zu (destination: any, damit der Datenverkehr ins Internet durchgelassen werden kann), aber die vorherige Regel wird damit nicht wieder aufgehoben. Korrekt soweit?

Regeln werden nicht "aufgehoben". Entweder sie "matchen" oder eben nicht. Falls die DENY WLAN Subnetz --> LAN Subnetz nicht matched, weil im Destination Feld keine IP aus dem LAN Netz steht, greift diese auch nicht und die Regel danach, die Destination: ANY Regel erlaubt dann die Verbindung zu jeder anderen IP auf Port 80 oder 443 die du in diesem Moment angewählt hattest.

...wird danach nicht durch eine allgemeine Freischaltung aufgehoben.

Richtig. Wenn eine Regel gematched hat, ist die Suche vorbei und alle anderen Regeln werden nicht mehr betrachtet.

Die DENY ANY ANY Regel am Schluss verbietet doch erst mal alles. Wieso kann man nicht eine einzige Regel schreiben, die ausschließlich den Traffic von WLAN Subnetz ins Internet (destination: internet) erlaubt auf Port 80/443 und fertig? Oder andersrum gefragt, warum gibt es als Destination kein "internet" oder wie auch immer man es nennen würde?

Genau das is das Problem. Wie würdest du denn "Internet" definieren? Eine Firewall is doof wie Stulle.... die hat zwei IP (Source und Destination), hat zwei Ports (Source und Destination Port) und weiß ob outbound oder inbound. Anhand dieser Dinge entscheidet sie JA oder NEIN. Deine Aufgabe als Netzwerk Admin ist es nun durch clevere Regelformulierungen der Firewall "Intelligenz" beizubringen.
Besser gesagt.. welche IPs hat denn "Internet"?
Woher soll die Firewall wissen, welche IPs nicht das Internet sein sollen?

Man müsste sich doch gar nicht erst um das Blockieren der Subnetze untereinander bemühen, um danach den Traffic auf "any" zu erlauben. Man müsste doch nur noch den Traffic ganz spezifisch erlauben und der Rest wird eh geblockt.

Genau... aber das Internet ist eben nicht Spezifisch.. es gibt ja keine "Internet-IP"
Sobald du keine "PERMIT Source:irgendwas --> Destination: ANY" schreibst, brauchst du dir auch weniger Gedanken um das Blocken machen.
Außerdem musst du auch immer davon ausgehen, dass Firewalls in Firmen uuuunzählige IPs/Subnetze und Dienste zu laufen haben. Dementsprechend müssen die Regeln einfach von Hause aus offener formuliert werden um nicht 1000 Regel-Einträge zu haben. Um dann aber trotzdem die Freischaltungen eingrenzen zu können, blockt man so "großflächig" wie es geht... Subnetz zu Subnetz...... Inbound gar kein Traffic usw...

Sollte daher ein Ping vom WLAN Subnetz ans LAN Interface nicht schon funktionieren?

Wie war nochmal deine Regel formuliert?
Permit -> ICMP -> Source: WLAN Net -> Destination: LAN Net ??

277

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 17, 2017, 10:59:48 pm »

Ein paar Sachen kann ich vielleicht noch erklären. Den Rest macht dann sicher monstermania morgen.
"WLAN Net" ist das WLAN Subnetz was am WLAN Interface der Firewall hängt.
Also (wahrscheinlich) ist WLAN Net in deinem Fall einfach nur dein WLAN Netz 192.168.1.0/24.
WLAN address hingegen ist die IP des WLAN Interfaces an deiner Firewall.
An dieser Stelle hast du sozusagen "Glück",
dass das WLAN Interface logischerweise Teil deines WLAN Subnetzes ist,
weshalb NTP und DNS funktionieren.
Besser wäre es jedoch die Destination auf die WLAN Interface IP zu beschränken...
also: <hier IP eingeben>/32 oder WLAN address.

Ich hatte ja schon mal erklärt, dass die Clients im Netz alle Informationen über NTP, DNS und Gateway von dem DHCP Server kriegen,
welcher auf dem WLAN Interface läuft.
Demnach ist es wie gesagt völlig ausreichend wenn die DNS und NTP Verbindungen "nur" bis zum WLAN Interface reichen für die Clients, denn nur dahin sollen die Clients kommunizieren dürfen um mit dem DNS oder NTP Dienst sprechen zu können.

Wegen deiner WAN Idee:
Die Server die du ansprechen möchtest stehen ja nicht innerhalb deines WAN Subnetzes, dass ist ja sozusagen noch Teil deines privaten Netzes. Das ist anders nicht umsetzbar. Deshalb muss man bevor man diese PERMIT HTTP ANY Rule am Ende setzt vorher überlegen inwieweit man diese einschränken kann, wie z.b. durch diese Spamhaus Listen usw.

Denn bedeutet das im Moment nicht auch, dass ein WLAN Client über Port 80 oder 443 auch auf mein LAN zugreifen kann (also auf z.B. meine NAS auf Port 443) ?

Genau das bedeutet es. Deshalb blockt man sämtliche Verbindung vom WLAN Netz ins LAN Netz und andersherum und überlegt sich dann, welche Geräte sollen denn miteinander kommunizieren dürfen?
Dann fängst du an z.B. eine Regel zu schreiben die einem bestimmten Gerät aus dem WLAN Netz über 443 die Kommunikation mit dem NAS im LAN Netz erlaubt.
So wie du jetzt die Regeln formuliert hast, hättest du auch bei der Bridge Idee bleiben können.
 
Diese Regeln die du da geschrieben hast, kannst du "so" in der Art nur so frei formulieren, weil monstermania keine Trennung zwischen den beiden Interface Subnetzen gemacht hatte.
Bei ihm bedeutet die HTTP Freischaltung nach ANY halt tatsächlich die Freischaltung ins Internet.

Was bedeutet das also:
Du musst noch vor dieser Rule aber sagen:
DENY Source: WLAN Net Destination: LAN Net Prot: ANY
Auf der LAN Seite natürlich andersherum.
Dadurch hast du sichergestellt, dass diese DENY Regel vor der HTTP Freischaltung greift.
Fängst du vor dieser DENY Regel jetzt an spezielle Kommunikationen zwischen deinen beiden Subnetzen zuzulassen,
greifen diese immer zu erst, noch bevor am Ende dann HTTP nach ANY (also auch ins Internet) erlaubt wird.
Also:
Die Reihenfolge ist super wichtig damit du nicht ausersehen zu viel erlaubst.
1) spezielle Regeln -> z.b. Gerät A im WLAN Netz darf mit dem NAS im Lan Netz reden auf Port 443
2) Deny Regel die sämtlichen anderen Traffic vom WLAN Netz ins LAN Netz blockiert
3) andere Block Regeln die sinnvoll sein könnten
4) Dann erst die sehr "offen" formulierte "erlaube HTTP Traffic nach ANY" Regel

HTTP/HTTPS -> Source: 192.168.0.1/24 -> Destination: 192.168.192.65/32
192.168.192.65/32 ist ja die statische WAN Interface IP.
Oder wird das nicht funktionieren?

Mir hilft es immer wenn ich die regeln laut ausspreche und mir überlege, was ich damit denn überhaupt aussagen will. Was diese Regel nun sagt ist, dass innerhalb des 192.168.0.1/24 Subnetzes über HTTP und HTTPS auf dein WAN Interface zugegriffen werden kann und somit die GUI Einlogg Oberfläche einsehbar ist.
Nicht mehr und nicht weniger.

"This Firewall" würd ich auch gern mal wissen, was da dahinter steckt. :-/

278

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 17, 2017, 09:47:30 pm »

@ne0h
Weil du vorhin gefragt hattest hier nochmal zur Vollständigkeit meine Antwort.
Diese hijacked Webseiten, werden als .txt Liste voller IPs in die Firewall eingehämmert.
Da gibt es zum einen die DROP Liste von Spamhaus, die "Spammer/Spambots" jedoch ausschließt
und wirklich nur übernommene, Bot-Rechner und gehackte Server usw. blockt.
Die EDROP Liste ist sozusagen noch ein Zusatz für die zurzeit bekannten Spambots.
Diese Listen sollte man täglich updaten.

Alles weitere zur Einrichtung und Tipps dazu findest du hier:
https://docs.opnsense.org/manual/how-tos/edrop.html

In deinem Fall musst du diese Listen also outbound (Destination: diese Listen als Alias)
in deine LAN und WLAN Regeln mit einfließen.
Ggf. noch auf dem WAN Interface inbound (Source: Alias), so wie ich das gemacht hatte.
(Ist aber wie gesagt nur notwendig, wenn du mal vorhast einen Server aus deinem internen Netz öffentlich zugänglich zu machen.)

Zum SD Karten Thema kann ich leider nix beisteuern.

279

German - Deutsch / Re: OPNsense installation schlägt fehl

« on: January 17, 2017, 09:37:59 pm »

Bei Github ein Ticket/Post aufmachen. Die sind da schnell mit der Beantwortung.
Kannst ja darauf verweisen, dass du den Bug gern bis 17.1 gefixed haben möchtest.
Ich drück dir die Daumen.

280

German - Deutsch / Re: [GELÖST] Rekonfigurieren des Keyboard Layouts in der Shell

« on: January 17, 2017, 09:34:36 pm »

hey hey,

besser als nix. "Sysinstall" wurde bestimmt raus genommen das kann sein.
Mit Umlauten haben alle zu kämpfen. "ß" geht bestimmt auch nicht.
Das sind Buchstaben die anscheinend niemand kennt.
Am wichtigsten sind ja eh "/" und "\". Hauptsache das funktioniert ordentlich.

Schöne Grüße
Oxy

281

German - Deutsch / Re: OPNsense auf SD Card (Zotac Nano CI323)

« on: January 17, 2017, 09:31:35 pm »

Hey astronach,

alles klar!
Danke dir trotzdem vielmals. Ich werde mal sehen, was ich am Ende nun nehme für mein Modem.
Bin da noch super unschlüssig. :/
Die Fritzbox 6360 schau ich mir aber mal an.

Schöne Grüße
Oxy

282

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 17, 2017, 03:52:11 pm »

DENY ANY ANY bedeutet dann auf jedem interface:
Blockiere jeden Datenverkehr von jedem Ziel zu jeder Quelle auf jedem Port, also inbound und outbound, nichts geht rein oder raus.

Genau so siehts aus
blockiere -> IPv4+IPv6: alle Transportprotokolle source: alles Port: alles destination: alles Port: alles

Jap. Wenn ich richtig verstanden habe, dann ist jedes Interface komplett dicht im Werkszustand. Wobei ich mich dann in dem Fall frage, warum diese beiden Standard Regeln für das WAN Interface explizit geschrieben sind, die man auf dem Screenshot sieht, den ich mal gepostet habe zuletzt (Beitrag 35, Seite 3).

Die kann man für jedes Interface festlegen. Block Bogon Networks hab ich zum Beispiel auf jedem Interface aktiviert.
Hier zum einstellen: Interfaces > [WAN] Dort kann man dann Häkchen rein oder raus machen.

Ich hab sie drinne gelassen, falls ich dann doch mal etwas aus meinem internen Netz vom Internet her erreichen möchte. Bevor man da also auf dem WAN Interface (Inbound) einen Port öffnet, damit man auch aus Spanien auf den eigenen internen Webserver zugreifen kann (nur mal als Beispiel), will ich vor der "Erlauben" Regel alles blocken was nicht sicher ist.

In deinem Fall könntest du aber selbst diese beiden Regeln rausnehmen, da du auf der WAN Seite keine Erlauben Regel geschrieben hast. Das ist von dir abhängig.

Zum Thema Bogon Netzwerke: "Bogon ist ein Jargonausdruck für ein IP-Datenpaket im öffentlichen Internet, das vorgibt, von einer gültigen Adresse des Internetprotokolls zu stammen, tatsächlich aber noch nicht durch die Internet Assigned Numbers Authority (IANA) oder eine beauftragte Regional Internet Registry (RIR) zugewiesen wurde. Die Gesamtheit nicht zugewiesener Adressen wird bogon space genannt."
Siehe: https://de.wikipedia.org/wiki/Bogon

Aber das fällt doch auch unter die DENY ANY ANY Regel, die hardcoded in der Firewall steht. Wofür sind die beiden Regeln explizit eingetragen und warum nur im WAN Interface?

Du kannst wenn du Lust hast auch alle privaten Adressbereiche im LAN blockieren. Ob das sinnvoll ist, ist die andere Sache ;-D
Im Grunde sind diese beiden Regeln aber NICHT NUR auf das WAN bezogen.

Das bedeutet, in deinem WAN Tab in der GUI steht auch keine Regel, ja?

Was in meinem WAN steht häng ich dir mal in den Anhang. Wie gesagt, theoretisch kann die leer sein.
Ich will bloß im Falle nichts vergessen haben oder nachtragen müssen, wenn ich dann mal nen Webserver aufbauen möchte und dann unter Firewall > Rules > WAN auf Port 80 freischalten muss.
Hast du nichts davon vor können deine WAN Interface Rules leer sein.

Dann muss ja zwischen WAN und Internet (oder Kabelmodem, ich habs einfach nur Internet genannt)
 ja doch nochmal die Firewall sitzen.

Wenn du die Firewall in deinem Gedankengang nicht als Gerät/Server siehst sondern als eine Art Tor, dann ja kann man sich das so gut vorstellen mit der "zweiten Firewall" zwischen Modem und tatsächlicher Firewall.

Kurz gesagt, im Log landet das, was von LAN/WLAN Interface am WAN Interface ankommt und darum steht dort die WAN IP statt der eigentlichen Client IP aus dem Netz (weil das WAN Interface das dann weiterleitet)? Ich finde es immer noch Konfus... Dann dürfte doch eigentlich nie als Source ein anderes Interface außer dem WAN da auftauchen, weil doch im Endeffekt alles über das WAN läuft. 

so habe ich das auch verstanden. Die Sache ist halt ja auch, dass da nie "WAN" steht, sondern stets "WAN(out)". Es ist also (laut meiner Auffassung) nie das WAN Interface sondern nur der Traffic gemeint, der aus dem WAN Interface durchgereicht wurde.
Vielleicht kann man sich das so vorstellen? Leider keine Ahnung. :-/

283

German - Deutsch / Re: OPNsense auf SD Card (Zotac Nano CI323)

« on: January 17, 2017, 02:49:04 pm »

Hey astronach,

alles perfekt danke für deine Antwort, nur würde mich es interessieren, ob man die "Routerfunktion" von der Fritzbox quasi ausschalten könnte um doppel-NAT zu vermeiden. Der Support angestellte von AVM meinte mal das ginge bei den neueren Geräten nicht mehr, deswegen ging ich davon aus du besitzt noch ein älteres.

Vielen Dank

Schöne Grüße
Oxy

284

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 17, 2017, 02:40:41 pm »

Auszug aus meinem Log.
1.) Ich bin mit meinem Handy mit dem WLAN verbunden.
2.) ich öffne reddit von meinem Handy
3.) Ausgabe siehe Log

WLAN Handy IP = Die lokale IP die mir der DHCP Server auf dem WLAN Interface der OPNsense Firewall vergeben hatte.
WAN Int IP = die statisch vergebene IP, die ich dem WAN Interface der Firewall vergab.

285

German - Deutsch / Re: Best practices/Standards für Heimnetzwerk

« on: January 17, 2017, 02:18:34 pm »

oha... ich hätte meine Tests die ich gemacht hatte um das Firewall-Log zu verstehen nicht unbedingt aufschreiben sollen.
Das hat ja jetzt mehr Verwirrung erzeugt als gedacht.
Okay... ich versuche nochmal klar zu machen was ich meinte.
Hoffentlich krieg ich das gut erklärt ohne alles zu verkomplizieren. (so schwer ist es "eigentlich" nich).

No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule.

Das ist die sogenannte "DENY ANY ANY" Regel. Sie sorgt dafür, dass deine Firewall nach der Installation nicht sofort alles durchlässt. Du musst diese also nicht explizit noch hinschreiben, sie ist sozusagen "hart eingetragen vom Werk aus".

Das war von mir falsch an dieser Stelle. Da hatte ich nur halbherzig gelesen.
Diese DENY ANY ANY Regel existiert und ist auch von OPNsense hart eingetragen, muss demnach von dir nicht extra hinzugefügt werden. Sie ist immer die allerletzte Rule.
Der Text auf der unteren Seite der Rules Seite verdeutlicht das. In diesem heißt es:
Everything that isn't explicitly passed is blocked by default.
Der Text den du meinst, also folgenden: No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule. den haben die OPNsense Entwickler noch zusätzlich dazu geschrieben um es dem User offensichtlicher zu machen, dass ohne Firewall Regeln, möglicherweise bestimmte "erhoffte" Kommunikation noch nicht funktioniert.
Wichtig ist aber: Die Default Regel am Ende des Regelwerks ist automatisch immer DENY ANY ANY

Jetzt hattest Du vorhin aber geschrieben:

Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite (Alles müsste daher geblockt werden, auch der Zugriff auf den DNS oder NTP Server). Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Das war mein Problem, als ich versuchte die "Logik" hinter dem Firewall Log zu verstehen.
Ich habe jetzt zwar irgendwie verstanden wie anscheinend die Regeln im Log angezeigt werden, aber in Verbindung mit den tatsächlich angelegten Rules verwirrt einen das nur.

--> Ich hoffe ich konnte bis hier die Verwirrung erst einmal irgendwie etwas lösen. Sorry dafür!

Die Firewall trennt alle Interfaces.
Die Kommunikation zwischen LAN und WLAN lasse ich komplett außen vor.
Also, im Initialzustand (nach der Installation von OPNsene) ist die Firewall an und blockt ALLE eingehenden UND ausgehenden Verbindungen, richtig?

Ich habe zwar schon länger meine OPNsense nicht von null neu aufbauen müssen, aber ja, sofern keine "erlauben" Regeln von dir in den unterschiedlichen 3 Interface Tabs angelegt wurden, blockt jedes Interface erst einmal alles.
Es existieren jedoch zwei Ausnahmen:
1.) Ausnahme ist hierbei die Anti Lockout Rule auf der LAN Seite.
Diese wird standardmäßig angelegt, damit man überhaupt auf die Weboberfläche kommt.
2.) Traffic der "von der Firewall" kommt wird auch nicht geblockt egal was für Regeln man auch immer selber erstellt. Mit "von der Firewall" ist dabei der Traffic gemeint der von der Firewall selbst kommt.
Das ist schwer zu erklären, das muss man selber mal gesehen haben.
Die Verbindung zu 37.48.77.141 (mail.opnsense.org) kann man zum Beispiel nicht blockieren, egal was für Regeln man formuliert. Der Traffic entsteht, wenn man nach Updates checked. (Kann man im Firewall Log nachlesen)

Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite

Was ist bei Dir die WAN Seite?

Alle Regeln die beim Interface Tab "WAN" formuliert werden.
Tut mir leid, dass hatte ich wohl unsauber formuliert.

Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Das ist das was ich meinte und bisher so verstanden hatte.

Die Sache, die einem vielleicht nicht ganz klar sein könnte ist, das theoretisch auch Traffic, am WAN Interface angeschlossen, an der Firewall starten könnte, ähnlich wie bei WLAN und LAN.
In deinem Fall ist die WAN Seite am Modem und das WAN Netz ist sehr klein. Oft hängt am WAN Interface vielleicht auch nur noch ein Router und das wars. Deswegen ist es üblich auf dem WAN Tab in Firewall > Rules > WAN keine Regeln zu formulieren. Man möchte also nicht, dass Das Interface eine Kommunikation startet oder ein Gerät innerhalb des angeschlossenen WAN Netzes eine Kommunikation startet. Ebenfalls möchte man nicht, dass ein potentieller Angreifer vom Internet auf deine WAN Schnittstelle zugreift. Um das alles zu unterbinden, schreibt man gar nichts in das WAN tab rein, denn dort wird nie eine Kommunikation gestartet. Pakete werden nur weitergereicht, denn die Source IP ist ja zum Beispiel die IP von deinem Laptop im LAN Netz gewesen.

--> Ich hoffe ich hab dich bis hier nich schon wieder verwirrt.
Wenn ich mir meinen Text durchlese hab ich bissel Angst dass ichs wieder verkompliziert hab.

Ein Paket startet im LAN Netz und die Firewall entscheidet, anhand der im LAN formulierten Regeln, was damit geschehen soll. Wenn es erlaubt wurde, wird das Paket durch das WAN Interface zum Modem weitergeschubst/durchgereicht. Deswegen ist es egal welche Regeln bei  Firewall > Rules > WAN formuliert werden, solange die Pakete im LAN starten.

Ich kann nur hoffen es ist jetzt nicht schlimm geworden mit dem Verständnis.

EDIT:

Das heißt, rein auf das Log bezogen, was im LAN/WLAN Interface erlaubt wird, wird nicht im LAN/WLAN Log sichtbar, sondern im WAN Log?

Ich schau mal ob ich was ausm Log heraus nehmen kann. Dann siehst du was ich meine.
Wie gesagt ich find es merkwürdig.