Hello All - I am trying to find an AP that will work in 2 modes concurrently (i.e. bridge and AP mode). Is anyone aware of one that will do this?
Thanks in advance.
Thanks in advance.
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 MenuQuote from: deanwebb on May 26, 2022, 01:45:57 PM
If you're going to have a lot of distance to cover, I'd recommend a private 5G network instead of standard wireless.
Quote from: deanwebb on May 23, 2022, 01:59:41 PMQuote from: Docster on May 23, 2022, 12:45:59 PM
That's not a concern for this device.
I'd be interested for more details on your device. I have had some discussions with the Building Security Consortium about the need to secure devices being used for physical security, environmental controls, and the like, as they're typically devices we only see as connecting, doing their job, and being monitored for functionality and not considering them as the endpoints that they are, with potential vulnerabilities and opportunities to act as pivot points in an attack or for the data to/from the devices to be intercepted and used either to further an attack or to be the objective of the attack.
Quote from: deanwebb on May 22, 2022, 08:03:58 AM
It is relevant in terms of how the device handles an error condition or, in this case, an enforcement condition - what it does if it expects a network to access, but is denied.
Quote from: icecream-guy on May 20, 2022, 06:27:28 PM
I was thinking that a Raspberry Pi would be a good platform for this, if you had some programming experience with Linux variants. The world is yours. setting up multiple interfaces, and loading Wireshark on the platform, and with logging you could script a VPN connection to upload logs whenever there is a network connection to someplace in the cloud,
I see the biggest problem is connecting to networks where you are not wanted, e,g. NAC where you get put into a quarantine VLAN. you may get a DHCP address, and monitor other devices on the same network, but that's about all.
Quote from: deanwebb on May 20, 2022, 12:00:07 PM
Hello there, I'm ready to help with security concerns.
First and foremost, let there be no hard-coded usernames or passwords among your devices, lest they be smitten with ten thousand plagues! Seriously, that's a major no-no. Just want to get that off my chest.
Second, is the device running a full OS, a compact OS, or a minimal OS? This has implications for things like error-handling, random number generators necessary for encryption, and general resiliency. In your use cases, more functionality means more flexibility in each use case and error-handling success instead of buffer overflow when unexpected conditions arise.
Getting closer to your use cases, I consider it to be a best practice to have security devices in their own VLAN. You will potentially have customers that still have flat, unsegmented networks, so they will find a requirement for a separate VLAN to be not practical. Same for customers that are looking to use your device in a smaller office, with a limited IP range and typically zero local tech support.
For the first use case, that manual checking is labor-intensive. It also leaves itself open to an attacker using a default password set to connect and do improper things. With it being unconnected, there is no alerting on a breach event or even a successful logon event, and as such would not be acceptable in a military or government or regulated industrial environment. Home users would probably be OK with it. You also have issues if there is an exposed factory reset button. Does hitting the reset button wipe all data? If yes, it's an exploit for an attacker wishing to cover evidence recorded on the monitor. If no, then an attacker potentially has access to the data after resetting the password on the device. If resetting the device is limited to persons with a legit console connection and that the device does not collect data or allow access to data unless the password is changed from a default credential or a reset credential, then you may have something there. If built-in MFA controls the reset procedure, you're even better off. Overall, I'm not a fan of this use case, but it may be all that's possible for some remote or home environments.
Second use case: DHCP is typically fine for this. You will want native encryption in communications with the server. I'm assuming the connection to the Internet is a connection to a cloud-based server. If so, you will want a private encryption function built into the application that uses strong, non-PKI methods. Why not PKI? Because PKI is vulnerable to quantum-based attacks. They are on their way, so if you use non-PKI-based encryption, you are in a better place. Be sure to NOT roll your own, but to use legitimate, established encryption protocols. It's expected that quantum attacks will tear into PKI encryption in a matter of seconds, while they only halve the time for cracking established symmetric encryption methods. So symmetric encryption methods that would take longer than the heat death of the universe to unravel now will be unraveled with quantum attacks some time after the electron shells of all atoms in the universe have collapsed, so that's "good enough" in my book.
If data is available locally in the second use case, you have the security concerns from the standalone case to consider.
For the 3rd case, the wireless one, you're looking at your onboard wifi needing to be compatible with current standards as well as older ones, for customers still using legacy gear.
In both the networked cases, a simple ethernet card/wifi card is needed, no requirement for onboard switching, routing or wireless AP. Those are needed if and only if the device is also supposed to act as a point of connectivity for other devices.
You will want the devices to be configurable either with DHCP or a statically-assigned IP address. If the devices also have an IPv6 stack, then they can support the default addressing standards with that protocol pretty easily.
These are all endpoint devices, so they are a terminus in the network communication - they should just connect and all the networking devices they connect to will do the rest.