Messages

106

German - Deutsch / Re: admin user cli update hat keine Rechte

« on: May 10, 2023, 01:04:38 pm »

Hi,

visudo ist dein Freund, nichts anderes als. "vi .../sudoers"

sudoers liegt unter /usr/local/etc/sudoers

Alleine schon für das

 

Code: [Select]

visudo

gibt's nen Daumen hoch Sowas freue ich mich immer zu sehen

Cheers

107

German - Deutsch / Re: Web-Proxy Problem

« on: May 10, 2023, 01:02:30 pm »

> Mein Problem ist, dass ich bei der Web-Proxy Konfiguration im Reiter Weiterleitungsproxy beim Proxy Interface nur Loopback auswählen kann.

Hi,

ich denke da müsste man genau an der Stelle schonmal ansetzen. Warum kannst du in diesem Reiter nur Loopback auswählen? Kannst du davon nen Screenshot machen und zeigen? Ich vermute du meinst da den Dialog "Proxy Interfaces" - da sollten aber alle Interfaces mit IPs etc. im System auftauchen in einem Dropdown zur Auswahl - so ist das zumindest auf den Testsystemen hier. Andernfalls ist vielleicht deine Interface Konfiguration des LANs irgendwie nicht ganz korrekt?

Cheers

108

German - Deutsch / Re: Client sendet jede menge DNS Anfragen

« on: May 10, 2023, 12:56:20 pm »

> Seit Wochen schau ich drauf, ich konnte nichts erkennen.

Kein Problem, darum frag ich nach

> Hab jetzt alles in Adguard geblockt (sehr lange liste), es geht anscheinend nix mehr raus.

Will dich nicht enttäuschen aber das war vergebene Liebesmühe und unnötig. Das wäre eh nicht rausgegangen (der Großteil zumindest) da der Großteil im Screenshot einfach nur simple Abfragen für Reverse IP sind und das noch gegen 192.168er IPs - was eh nicht raus gegeben wird. Und die anderen Anfragen sind alles in-addr.arpa (reverse) Anfragen zu irgendwelchen dynamic IP Ranges - genau daher würde ich nachhaken/-forschen wo die herkommen. Den DNS zu verbieten ist die Auswirkung zu eliminieren aber nicht das Problem zu finden

Wenn deine Kiste bspw. nen DNS von 222.0.114.46.in-addr.arpa verlangt versucht er nur 46.114.0.222 Rückwärts aufzulösen (also Hostnamen rauszufinden). Also will irgendwas auf der Kiste den Hostnamen zu der IP wissen - wahrscheinlich deshalb weil es entweder ne Anfrage gab oder die Kiste dahin reden will (warum auch immer). Und dann würde ich das mal versuchen durch die Logs zu stiefeln und schauen, ob die IP mal irgendwann über die Firewall reinkam oder auf der Kiste irgendwo ne Anfrage gestellt hat.

Aber joa, wenn man auf dem Gerät selbst das nicht findet, wird das schwierig zu analysieren. Da kann man dann nur Logging für die IP anmachen, filterlog etc. und dann mal sehen wann irgendwelche seltsamen Reverse Abfragen von der Kiste wieder kommen und dann zeitnah die Logs durchkrempeln ob man was findet.

Cheers

109

German - Deutsch / Re: Externer DNS Server (AdGuard) wie am besten konfigurieren?

« on: May 10, 2023, 12:49:56 pm »

Na dann Bestens

110

German - Deutsch / Re: Externer DNS Server (AdGuard) wie am besten konfigurieren?

« on: May 08, 2023, 04:02:04 pm »

Und was hatte gefehlt?

111

German - Deutsch / Re: Internen Server über HAPROXY mit SSL von intern erreichen ?

« on: May 08, 2023, 03:59:50 pm »

Kommt darauf an, wie ist der Zugriff auf den HAproxy freigegeben? Nur am WAN? Am LAN auch? Was ist denn die Fehlermeldung/das Problem wenn von intern auf die externe Domain zugegriffen wird?

Hier ist ja gerade kein Port Forwarding aktiv, somit sollte es also auch eigentlich kein NAT (reflection) Problem sein und von innen sollte man natürlich genauso auf den Namen/die IP des Exc zugreifen können. Wie liegt die IP denn auf der Sense an? Statisch am WAN? Ändert sich? Steht noch ein Router davor?`

Sind leider viel zu wenig Infos für eine genaue Bestimmung des Problems.

Cheers

112

German - Deutsch / Re: Client sendet jede menge DNS Anfragen

« on: May 08, 2023, 03:56:44 pm »

> Es gibt keinen Traffic auf das Gerät, es sei den, ich greife darauf zu.

Weißt du oder behauptest du? Ich behaupte, wenn ein Device lang genug mit einem Webserver im Netz hängt, egal welcher Port, dann gibt es DEFINITIV Zugriffe darauf. Egal ob da ein PW Prompt dahinter hängt, allein was an Scannern durchs Netz wackeln, lösen trotzdem Zugriffsversuche aus.

> Meine IOS App funktioniert nicht über OPNVPN und auch nicht über WireGuard. Anfragen kommen rein und werden auch verarbeitet, bekomme aber kein Bild. Deshalb habe ich es mit Portweiterleitung gemacht. So ein Schei..

Eventuell mal nachhaken/-forschen, warum da kein Bild kommt? Macht ja keinen Sinn, dass das über ne stumpfe Portweiterleitung geht, aber per VPN wo es technisch nicht mal gefiltert ist nicht gehen sollte?

Cheers

113

German - Deutsch / Re: Inbound NAT ohne Maskierung

« on: May 08, 2023, 03:54:17 pm »

Bitte mal nachschauen in den erweiterten Optionen bezüglich NAT Reflection ob da irgendwas angeschaltet wurde (in der Regel selbst ja nicht, aber generell) und ob das ggf. auf NAT via Proxy steht. Sofern nicht gebraucht darf Reflection gern auf "nope" stehen oder auf PureNAT was eigentlich genügt.

Prinzipiell hat Marc aber recht - und @meyerguru nicht - dass beim simplen Port Forwarding eigentlich die Source IP des Absenders nicht verändert wird. Die Firewall proxy'ed hier nicht einfach und macht eine neue Verbindung auf, sondern schreibt die Ziel IP um, die Source bleibt aber gleich. Daher würde sich mir auch nicht erschließen, warum du Verbindungen von der Firewall bekommen solltest statt von der Quelle im Internet.

Wäre es anders, könnten ja sämtliche Pakete der Verbindung entweder nach Verbindungsaufbau nicht mehr zugestellt werden oder müssten immer durch einen Proxy der Firewall laufen (mit entsprechend Overhead). Das macht so keinen Sinn...

Cheers

114

German - Deutsch / Re: Externer DNS Server (AdGuard) wie am besten konfigurieren?

« on: May 04, 2023, 05:15:16 pm »

> Mir fehlt jetzt nur noch das Captive Portal auf der GAST Schnittstelle um Zusammenspiel mit einem Adguard auf Proxmox, also NICHT auf der OpnSense. Die Umleitung zu Adguard mit Port 53 funktioniert per NAT. Aber das Captive Portal will noch nicht ;-)

Ich sehe da ehrlich gesagt nicht so ganz den Bezug zur OPNsense - also was das Problem angeht.

Das Captive Portal ist ja aktiv auf einem Interface und fängt Zugriffe ab und redirected die zum Portal. DNS ist meistens dabei erstmal nebensächlich. Man definiert im Portal den Hostnamen und muss dann in PiHole, Adguard oder was man sonst an DNS nutzt sicherstellen, dass der Name dann auch aufgelöst werden kann. Zusätzlich muss die IP zum DNS (Adguard in dem Fall) dann

a) per Regel auf dem CP Interface erlaubt sein
b) die IP des/der DNS(e) muss in den allowed addresses vom Portal stehen, damit Zugriffe darauf nicht gefiltert und abgefangen werden.

Wenn das der Fall ist, ist dem Portal eigentlich relativ egal wo DNS herkommt. Daher sehe ich das Problem nicht so ganz

Ansonsten würde ich den DNS Zugriff nach Upstream nie an einen Forwarder schicken - Zentralisierung macht es nur einfacher, dass Dinge upstream sinnlos geblockt werden. Entweder via Unbound über Roots auflösen lassen (sowas macht man sinnvollerweise meist am "Edge" des Netzwerks und nicht hinten auf dem DNS jeder für sich wenn man von mehreren DNSen ausgeht) oder wenn mans noch weiter spinnen möchte, kann man mehrere (nicht ein zwei, sondern wirklich MEHRERE) Server bpsw. via DNScrypt Proxy als Server reinhauen und diese dann round robin via DoH bspw. die Requests rausschicken um die Anfragen auf mehrere 'vertrauenswürdige' DNSe zu verteilen aber niemand dabei die volle Liste an DNS Anfragen rauszugeben.

Cheers

115

German - Deutsch / Re: HA Setup / Backup FW bekommt ARP Eintrag?

« on: May 04, 2023, 05:01:13 pm »

> Habe daher das Teil gelöscht, eine weitere Hardware mithilfe des XML Backups hochgezogen und nun läuft das Cluster erstmal wieder stabil.

Ah fein. Hätte bei Switch Stack sonst geraten, dass die ggf. auch VRRP/HSRP sprechen und du einen VHID Konflikt mit den Kisten hast. Hatten wir im RZ auch schon, da tauchen dann plötzlich die fiesesten schlecht debugbaren Probleme auf.

Darum aufpassen bei mehreren Clustern im gleichen Netzwerksegment mit der VHID!

Cheers

116

German - Deutsch / Re: Client sendet jede menge DNS Anfragen

« on: May 04, 2023, 04:59:41 pm »

> Ja sind von extern erreichbar, sind aber nicht offen. O2 ist mein Anbieter für Handy

Den Satz verstehe ich nicht ganz Also sind sie erreichbar von extern. Eben nur aus DE (je nach GeoIP blah aber egal). Heißt dass jede IP in DE auf das Türdingsi drauf kommt. IPv4 Adressraum ist klein, der wird mit Tools heut sehr schnell abgescannt und wenn da diverse Scanner einfach mal stumpf alle Ports durchgrasen gibts hinterher ne Liste an der die sehen "aha da war was auf Port 23456". Port Obscurity ist heute eine Sache von Minuten bis Stunden, kein Versteck mehr. Daher vermute ich stark, dass eben die Zugriffe auf das Gerät, was die DNS Anfragen macht, irgendwas versucht zu triggern oder zu loggen und beim Log dann ggf. sowas wie DNS Auflösung an ist - also versucht wird mitzuloggen, welcher DNS Name zur IP vorliegt und deshalb die ganzen Anfragen an den AdGuard gestellt werden.

Ich würde mir dazu mal den Traffic auf das Gerät anschauen, da müssten die IPs zu den DNS Namen auftauchen (und einige kann man ja ganz gut im Klartext aus dem DNS ableiten wie 87.236.176.67 bspw.)

Warum muss das eigentlich via Port Forwarding immer im Netz hängen und nicht simpel einfach via VPN erreichbar?

Cheers
\jens

117

German - Deutsch / Re: HA Setup / Backup FW bekommt ARP Eintrag?

« on: May 04, 2023, 03:41:27 pm »

Hi,

kann man so ohne weiteres nicht sagen. Entweder gibts nen Fehler/Problem im CARP Setup oder der Core Switch hat ne Meise (oder hält seinen ARP Cache zu lange fest) oder hat ggf. ein Problem. Der Core ist nicht zufällig auch redundant ein Cluster?

Cheers

118

German - Deutsch / Re: Client sendet jede menge DNS Anfragen

« on: May 04, 2023, 12:13:38 pm »

Moin,

* von was sind denn die Screenshots? Adguard?
* sind die Türdinger von extern erreichbar? Es würde mich sehr wundern, wenn die einfach aus Jux und Dollerei irgendwelchen Random IP DynDNS Namen versuchen aufzulösen (pool.telefonica ist der DynDNS Adressbereich von Tel/O2, dito mit t-ipconnect und der Telekom) denn da wird kein Service/Server stehen.
* aus Versehen ggf. einen davon per Port Forwarding o.ä. erreichbar gemacht?

für mich sieht das aus, als würde jemand (wer sieht man im Screenshot ja nicht) einfach versuchen die PTR Records zu anfragenden IP Adressen aufzulösen. Und deine Liste sieht nach dem typischen Netzgrundrauschen/Scannen aus. Die Censys Dinger sind bspw. Scan-Services die gern mal den ganzen IP Space abgrasen für Shodan und Co um IP/Ports zu sammeln, wo Dinge offen im Netz stehen. Und dass da auch dynamic IP Ranges mit dabei sind würde heißen, dass die Firewall oder dein Türgerät irgendwelche Anfragen bekommt die sie via Adguard auflösen lassen.

Sicher dass es das Türgerät ist, dass die DNS Anfragen stellt? Dann würde ich mal nachforschen ob das nicht versehentlich offen im Netz steht über einen Port und dadurch Anfragen bekommt und diese dann einfach versucht, reverse DNS aufzulösen.

Cheers

119

General Discussion / Re: Host on VLAN A can't ping VLAN B within same router

« on: March 29, 2023, 12:25:44 pm »

Indeed they do
That's what's called policy (as in rules) based routing. You force the traffic that matches a specific rule through the attached gateway - even if it wouldn't go there in the first place. That's why PBRs should be handled with care as they can leak or expose information that was to go into another VLAN through a WAN per accident. Normally that should be blocked upstream but a few ISPs or cloud providers take that as a kinda serious offense if they catch RFC1918 packets travelling upstream as they should not be routed

Cheers

120

General Discussion / Re: Host on VLAN A can't ping VLAN B within same router

« on: March 28, 2023, 12:16:13 pm »

Could you please show both interface configurations? They are using different VLAN IDs, correct?
Could you add screens of your ruleset, too?

As per the ICMP: do you have another rule on Floating or the interface they are originating that has the WAN interface enforced as Gateway? I don't suppose so but let's just check.

Cheers