search

andybalholm / redwood

Web content filter that runs as an HTTP proxy
BSD 2-Clause "Simplified" License
217 stars 37 forks source link

Rasing the ipv6 question: "ipv6 what?" #70

Open elico opened 3 years ago

elico commented 3 years ago

I am starting to work with ipv6 in comming month. I have expirence with it but I am not sure how RedWood looks at it. Currently it's "natting" or "proxying" every single request with it's own ip. Since I have couple iot devices i have seen that their service providers are planing for ipv6 integration. The basic idea is that the device would be reacable directly from the internet instead of via a relay. My current solution is to use RedWood only on pcs and desktops. I have seen some solutions that separate the iot network from the pcs however most clients have a single network and gw. I want to allow only specific iot devices to be able to access specific sites/domains without bumping or maybe interception.

Ideas? Maybe othe angles I have not anticipated yet?

andybalholm commented 3 years ago

If you want the IOT devices to have 2-way direct internet connection, with no filtering, while other devices get transparently intercepted by the filter, it sounds like the firewall configuration is the place to do that.

elico commented 3 years ago

I am wondering if an iot device should have this 2 way access. I want the iot devices to be contained to their domains, protocols and services. my vacuum cleaner needs to have access only to specific domains. the fw cannot do that yet.

בתאריך יום ג׳, 30 במרץ 2021, 23:23, מאת Andy Balholm ‏< @.***>:

If you want the IOT devices to have 2-way direct internet connection, with no filtering, while other devices get transparently intercepted by the filter, it sounds like the firewall configuration is the place to do that.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andybalholm/redwood/issues/70#issuecomment-810552615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANUHMFTWOLQAUR6XSYL4FDTGIXKZANCNFSM42CLONAA .

andybalholm commented 3 years ago

Do the HTTP servers that the IOT devices are accessing need to see their actual IP addresses? Or is it OK if they see the proxy address?

elico commented 3 years ago

They want to see the real ip to avoid any relay as possible. Of course RedWood is a component of a firewall product/service even of it doesn't declared as one. Ipv6 is not wide spread enough for them to shutdown their relays in the next year.. Eventually these iot devices will need to have a way to make their ip known to the filtering service at runtime. I believe that for small networks a static ip would be enough.

בתאריך יום ד׳, 31 במרץ 2021, 19:22, מאת Andy Balholm ‏< @.***>:

Do the HTTP servers that the IOT devices are accessing need to see their actual IP addresses? Or is it OK if they see the proxy address?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andybalholm/redwood/issues/70#issuecomment-811201900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANUHMDAWVCOX5YJJMJ32M3TGND27ANCNFSM42CLONAA .

andybalholm commented 3 years ago

I don't understand what you're talking about at all.

elico commented 3 years ago

@andybalholm Sorry on Back to the desktop. The next text is a bit long but technically very simple, I preferred to write it the long way with hope it will answer all the basic questions about the subject.

I will try to first clear out the doubts. These IoT devices want their own IPv6 address against the world. Whether we will allow them to pass the FW and/or proxy as they please is a whole different story. Currently the most used home IoT devices I know are:

Not all of them really need Internet and eventually not all of them need to be an full blown IoT device. However most of their analytics and general usage data are what the consumers needs or wants. For example, a vacuum cleaner is a "static" function. It need to be able to clean the room and that's it. Vendors like to make sure their device will work in all situations and scenarios.. and there for relay and many other moving parts. The main issue with these devices is security and just to be clear, content filtering is a security feature. What I am trying to say is that IoT devices needs content filtering as a functional feature. Maybe currently they don't need pruning on their xml or json or other apis but their DNS and their SNI needs to be inspected. I have seen to many of these devices doing weird stuff.

The relays I was talking about which vendors wants to remove are actually chats which does NAT piercing and are implementing some messaging services. The vendors want to eliminate NAT gws/devices since they want direct access to the devices to allow full and smooth remote control. Currently most of the IoT vendors provide cloud compute, database and relay services for both functionality and analytical data. Their main business is not the relay but the compute and data, these are the actual firmware resources. These relays are a burden for them. Most of the IoT devices firmware can be delivered over plain HTTP securely enough however there is a standard which demands from medical IoT vendors to apply end to end encryption for communications and upgrades. These are there to implement forward secrecy and allow smooth, simple and fast firmware upgrades. (I had the first video tech talk from the person who leads the team of this standard on how to secure these but lost the link.)

The main concern with these IoT devices is that they can be hacked in so many ways. If we can manage where theses devices can reach by themself and the other way around we can lower their attack vector to vendor infrastructure breaches only. With this in mind the actual network physical access to these devices also needs to be filtered and secured.

andybalholm commented 3 years ago

Several years ago you asked about the possibility of supporting TPROXY. Is that what you need?

elico commented 3 years ago

I believe that tproxy is the right thing for ipv6 (if someone needs to reveal the src ip). However there is no rush with a solution. I still need to do some testing before implemting anything.