Menu

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.

Show posts Menu

Messages - Ben.

#31
German - Deutsch / Re: Absicherungsidee IP-Türklingel
January 17, 2022, 08:04:07 AM
Quote from: RicAtiC on January 16, 2022, 11:09:09 PM
was für ne Hütte hast Du, dass Du nicht mitbekommen würdest, dass da einer die Klingel raus reißt? Wenn Du im Urlaub bist vielleicht oder sowas, ok...
Durch die sinkenden Besucherzahlen war Schloss Schwanstein recht günstig abzugeben...

Quote from: RicAtiC on January 16, 2022, 11:09:09 PM
Da versucht dann aber glaub kaum jemand Deine Tür zu "hacken", sondern dringt wahrscheinlich anders ein. Ok egal, wollte jetzt nicht klug daher reden, Sinn macht eine Absicherung allemal.
Das habe ich mir auch schon überlegt, ob ich es ggf. übertreibe. Die Tür wird nicht das Haupteinfallstor sein, das ist mir klar. Meist reissen sie die Klingel raus, um ggf. die Drähte vom Summer kurzzuschliessen, wenn der schlecht angebunden ist (so wie bei unserer alten Tiefgarage mit dem Schlüsselschloss damals). Aber man schläft halt doch besser...

Quote from: RicAtiC on January 16, 2022, 11:09:09 PM
Würde das definitiv in ein separates VLAN packen ("IoT" oder "SmartHome", o.ä.). Erlaubte Zieladressen im Inet dann auf die vom Hersteller der Klingel empfohlenen Seiten beschränkt.
Ich habe bereits solch ein VLAN für Heizung, Smarthome-Server etc. Entweder packe ich es da dazu oder eben noch mal separat. Entweder baue ich entsprechende Regeln um Klingel und Steuergerät zu trennen oder ein komplett eigenes VLAN. Was findest du sinnvoller?

Quote from: RicAtiC on January 16, 2022, 11:09:09 PM
Von den zwei Clients wirst Du auch was freigeben müssen, wobei wohl eher vom neuen VLAN (Klingel) zu den Clients in den anderen VLANs, damit der Videocall funktioniert (SIP?). Auch hier nur mit Quelle und Ziel + Port.

Die Regel kann man dann vielleicht auch noch zeitgesteuert deaktivieren in der Nacht? Fällt mir gerade mal so ein...
Das kann ich noch nicht genau sagen, aber ich denke auch, dass eher von den Clients zur Klingel/Steuergerät was nötig wird, zwischen Klingel und Steuergerät, sowie Klingel und Internet (Push-Benachrichtigung). Aber das wird auf jeden Fall auf Portscan und Trafficmonitoring hinaus laufen, um das sauber einzugrenzen.

Weitere Ideen:
- simples Monitoring per ping: falls die Klingel länger als 30 Sekunden offline ist (wie lange dauert ein Neustart nach Update?), gibt es eine SMS, bei weiteren 30 Sekunden wird per SNMP der entsprechende Port auf dem Switch deaktiviert oder isoliert.
- MAC-Adressenfilterung ist klar
- Erschütterungssensor oder Reedkontakt in der Klingel, was allerdings für mich eher aufwändig ist
- Sicherheitsschrauben, die man aufbohren muss.

Danke für deinen Input!
#32
German - Deutsch / Absicherungsidee IP-Türklingel
January 16, 2022, 04:33:38 PM
Hallo,
Ich plane den Einsatz einer IP-Türklingel und denke gerade über die bestmögliche Absicherung nach.

Die Türklingel ist per Ethernet angebunden (PoE) und kommuniziert über einen Switch mit einem separaten Türsteuergerät, das am gleichen Switch hängt.

Die Klingel braucht Internetzugang und die Clients aus zwei verschiedenen VLANs brauchen Zugriff darauf (Gegensprechen mit Videobild).

Die Liste der Devices mit Zugriff wird per MAC-Adresse reguliert, was aber kein sehr hoher Schutz ist. Nun überlege ich, ob es Sinn macht die Klingel mit Steuergerät in ein separates VLAN zu legen. Ich denke aber, dass ich auch per einzelnen IP-Regeln eine ähnliche Absicherung hinbekommen sollte.

Habt ihr ähnliche Szenarien schon mal umgesetzt?

Mögliche Risiken (hauptsächlich):
1) Jemand reisst die Klingel raus und verbindet seinen Laptop. Dann darf er nur in einen kleinen Teil, eher unwichtigen Teil des Netzes gelangen. Allerdings bestünde natürlich auch Zugriff auf das Türsteuergerät. Im Idealfall kann ich den Port abschalten, sobald ich eine Manipulation erkenne.

2) Jemand dringt von aussen in mein LAN ein und kann darüber mein Haustürschloss ansteuern. Das könnte dann nach meiner geplanten Absicherung nur via 5-10 iOS-Devices passieren, die als Clients für die Gegensprechanlage dienen und Zugriff auf das Steuergerät hätten.

Habt ihr Ideen und Tipps für mich?

Alles hängt an einem Unifi L2/L3 Switch, könnte aber auch an einem managed Netgear betrieben werden (falls nötig).

PS: Anbindung per WiFi wäre auch möglich, aber ich denke nicht, dass das ein Sicherheitszugewinn ist, nur weil kein Kabel dran hängt.
#33
No problem, thank you!

It works in my testing environment so far, so I will probably put it on production.
Thanks for your effort!
#34
QuoteIf you take example 3, you follow /var/log/system/latest.log (you have to disable circular log in System : Settings : Logging) and search for "MAC pair", should be sufficient.
I did this but I still don't have a "latest.log". The checkbox is set for "disable circular log".

I saw the "MAC pair" log written to the file "system_20220112.log" but this will be difficult to monitor.

Do you have a hint what I need to change in order to have this "latest.log"?

Thanks!
#35
Ah, ok, makes sense.

Thanks for clarifying.
#36
Hi,

I have a fresh install on a demo system.

There were two gateways automatically created:
1) WAN_DHCP6
2) WAN_DHCP

I stopped WAN_DHCP6 and it's now in the status "pending".
If now click on the bin to delete it, I am asked if Im sure to delete it. If I confirm, the gateway turns active again.

Is this a known bug or intended behavior?

I know that you can change the interface configuration and set IPv6 to "none" and then delete it. But I would expect a hint "You need to disable..." and not re-activate the gateway.

Thanks!
#37
I did a fresh install on a test system, same problem here.

bash is not installed as a dependency and not part of the standard installation. So the OPN-Arp plugin (which sounds cool), can't run.

I saw that the script itself is rather simple, no? Wouldn't it be possible to re-write it so it can be run inside the default shell (or even PHP if you like)? Just a thought...
#38
I feel you. I run a APU1D4 at the moment and am quite happy with it, even it is reaching its limits now with kids growing up and using more bandwidth as well as adding more services to OPNsense.

I have to re-do my LAN soon so I want to upgrade here and there as there will be a lot more devices on my LAN soon.

But yes, a thin client to replace the APU is definitely the plan, but I need one with PCIe slot...
#39
Ok, cool. So what did YOU want to achieve and what did you end up with?

My plan at the moment is to replace the current OPNsense system by a stronger one and extend it by a SFP+ card so remove it as the bottleneck.

I feel this is the best solution for me maybe. Option b) would be LAGG via several ports, but I guess SFP+ could be faster overall. Not sure.
#40
Thanks for the confirmation.
#41
Quote from: bimbar on January 11, 2022, 03:57:43 PM
It is not the case that the switch does route and the firewall firewalls those packets the switch routes.
Yes, if the switch does the routing, the firewall won't see any of the traffic.

But if I try to separate each VLAN from each other, the switch can't do the routing, as it would pass all traffic between the VLANs, right? There are no rules to block ports in a L3 switch.

So I would have to disable L3 switching and run it as a L2 switch. This would then make the switch pass all traffic through the firewall, right?
#42
Hi,

I currently have an OPNsense instance running as my firewall and router for 3 VLANs.
My plan is to add 2 additional VLANs and replace the current Netgear Switches by a Ubiquity PoE L3 Switch.

So I have a basic question which you can maybe help me to answer:

If all my VLANs are fully separated from each other, I might only benefit from faster inter-VLAN traffic.
Even if I permit access from VLAN 1 to VLAN 2 (e.g. trusted to IoT), all traffic will go through OPNsense for "evaluation" as the L3 switch is not doing "firewalling".

Is that correct?

I want to better understand which device in my LAN needs to have more power. Is it worth investing in the L3 switch or should I rather replace the OPNsense device (which needs to handle a 100 MBit connection and is doing fine)?

Thanks for your thoughts.
#43
Quote from: mimugmail on January 10, 2022, 05:43:20 PM
Did you install the plugin the usual way? It should be a dependency
I clicked on the "+" in the Plugin list after I had added your repository as described on your website. So yes, I would call this "the normal way" :) I reinstalled once, but it didnt help.

I did not use your repo before, so I did it just because of this Plugin.
#44
Quote from: mimugmail on January 10, 2022, 04:09:46 PM
put a "bash" infront of it :)
Is "bash" part of the basic OPNsense installation? At least I don't have it ;)
#45
Thanks, I will try that.

My problem now is that opn-arp does not want to start.

Where can I find the logs?
When I run it (as root) on the shell, I get
/usr/local/bin/opn-arp.sh: Permission denied.