[kwlug-disc] Deny Internet access for some LAN devices
B. S.
bs27975 at gmail.com
Thu Apr 13 16:57:41 EDT 2017
Right, but that assumes his home router has that ability. (He did note
it at least has the basic ability to deny an ip, and has done so.)
The comment about turning off UPnP is prudent, mirroring my same on the
device itself. Which could in turn be mirrored by anything else
aggregating UPnP within the place. Seems that many devices come by
default exposing, and aggregating, UPnP by default. Including Linux. Not
all of which by default turn on a firewall or iptables.
In one case I had to find a UPnP discoverer app for my Android to find a
camera - upon running it I was startled to discover how many other
things were advertising. Unexpectedly, and inadvertently.
> Right, but that assumes the home router has that ability.
Thus my comment about making his Pi (the camera) gateway. It will have
such ability. Aside from specifically controlling forwarding (e.g. via
vpn, and internal devices then look for the cameras via internal routes
to the PI), simple iptables drops to 0.0.0.0 become possible.
OpenWRT et al would bring similar functionality to the table.
It is arguable everyone should be running with pfSense et al in front of
everything, explicitly controlling their traffic. IoT firmware bugs
(e.g. cameras) have demonstrated one's internal network probably isn't
as opaque as one thinks.
Doesn't protect against running a browser as root, though! Nor anything
else inviting stuff in that phone's home / attacks from inside.
Which likely examine the local machine's routes, probably leading to
camera discovery and access.
On 04/13/2017 04:11 PM, John Van Ostrand wrote:
> How about traffic shaping. Matching packets with tc and then filter. I've
> not done it but it seems it might work.
>
> http://www.docum.org/faq/cache/62.html
>
> On Wed, Apr 12, 2017 at 6:01 PM, B. S. <bs27975 at gmail.com> wrote:
>
>> Doesn't need to be a VLAN, which would require the router to understand
>> VLAN. Just static addresses (nets) on the camera, and a secondary eth on
>> points you care about / would access with. e.g. On the PI, where the VPN
>> address and internal net can forward to that interface and vice versa, and
>> forwards from that net to 0.0.0.0 denied. Gateway on the cameras would be
>> the PI.
>>
>> For VLAN, the cameras, or the switch(es) they're connected to, would have
>> to be VLAN capable and probably aren't. The PI could be made to be, but by
>> itself that doesn't buy you anything that isn't already present above.
>>
>> Have to be static on the cameras, else a physically separate network or
>> DHCP is going to cause network confusion. Or specially crafted DHCP
>> settings - which would only bring complication for little gain.
>>
>> You'll want to turn off PnP, et al, on the cameras, and UPnP et al inside
>> the house, so nothing can inadvertently discover the presence of the
>> cameras.
>>
>>
>> On 04/12/2017 08:57 AM, Raymond Chen wrote:
>>
>>> I love the subnet idea. I'll check if it has the VLAN support. Thank you.
>>>
>>> @Paul, no it doesn't have parent control. :)
>>>
>>> On Tue, Apr 11, 2017 at 11:52 PM, Paul Nijjar via kwlug-disc <
>>> kwlug-disc at kwlug.org> wrote:
>>>
>>>
>>>> Are there parental control features on the router? You could say that
>>>> the cameras have an early bedtime and are not allowed to access the
>>>> Internet after those hours.
>>>>
>>>> On Tue, Apr 11, 2017 at 06:08:40PM -0400, Raymond Chen wrote:
>>>>
>>>>> I have some cameras in my house. I'm trying to disable their access to
>>>>> Internet. Since I have a VPN service on my Raspberry Pi, if I want to
>>>>> connect to those cameras, I can connect to the VPN first.
>>>>>
>>>>> One way I can think of is setting their gateway IP address to empty. But
>>>> if there is a malware on the camera, that doesn't help so much, right?
>>>>>
>>>>> I'm sure those DD-WRT routers can do that, just create a policy based on
>>>>> the MAC... But unfortunately my route is D-Link N600. It has some basic
>>>>> firewall, filter features, but most of them are protecting agains
>>>>> outside
>>>>> access. Any idea?
More information about the kwlug-disc
mailing list