Re: Security changes - restricting uhttpd addresses
On 2022-10-26 18:55, Etienne Champetier wrote: Le mar. 25 oct. 2022 à 17:47, Michael Richardson a écrit : Peter Naulls wrote: > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. It's totally impractical. Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's really only responding on the right interface ? With complicated routing setup it changes a bit the behavior, but this might be the simplest option if we don't want to rely only on the firewall I have an experimental branch with SO_BINDTODEVICE support, but I haven't tested it with the latest stable or snapshot releases yet. https://cgit.m7n.se/pub/openwrt/uhttpd/log/?h=bind-to-device-master /Mikael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On Wed, Oct 26, 2022 at 11:58 AM Etienne Champetier wrote: > > Le mar. 25 oct. 2022 à 17:47, Michael Richardson > a écrit : > > > > > > Peter Naulls wrote: > > > Nevertheless, the security people are looking at this config > > > statically, and not seeing that it's bound to the LAN interface IP > > > only. > > > > I don't think they are really security people, but... > > > > > For my use, I've changed the default binding to the LAN IP, and also > > > added another init.d script to check the current LAN address, and > > > update the uhttpd config if need be and then restart it (and add > > > a config hook to the network config). Obviously this isn't > > > very satisfactory, open to better suggestions here. > > > > So, it needs to bound to *all* the IPv6 "LAN" IPs. > > That means: > > a) the ULA that is created. > > b) the LL-IPv6 that are always present > > c) the GUA IPv6 that is delegated > > > > And when we make guest LANs, we may also need to bind it to that, because > > there are things that guests might need to know, such as seeing the status > > page to see if the network is up. > > > > > It might also be better if uhttpd could be configured to bind > > > to a specific interface rather than knowing its IP upfront, but > > > that might be impractical. > > > > It's totally impractical. I also have to reiterate these "security audits", and this is in now way related to OpenWRT, but the people who like to think they know security. o just because a package is installed does not mean it is listening o go read some docs o learn how to port scan yourself o go read some docs o learn how to write your own exploits o go read some docs o quit reading CVEs that are not related to your product(s) o go read some docs o join LKML and read what is being done o go read some docs Leave us alone - my company uses Linux exclusively - the threats are handled way faster than any other platform (OpenWRT aside), so tell your *security* people to hire someone that is not a straight out of college noob running some 3rd part package collector and actually learn how to examine a system for exploits. Just because something is installed absolutely does not mean it is vulnerable to attack. This is becoming a headache trying to teach the recently graduated kids with security degrees or certifications (that are easily handed out nowadays) how to handle security. Everyone wants to package inspect versus network inspect. Let me tell you something - if I have physical access, there is not a damn thing you can do to stop me - so just worry about network access like everyone is telling you. If your company is not amenable to that - I would find another job. I have a rule of thumb - I do not work for people dumber than me - you should try that rather than trying to force dumber people to make you change. Rules of the world progressing (college class 101). > Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's > really only responding on the right interface ? > With complicated routing setup it changes a bit the behavior, but this > might be the simplest option if we don't want to rely only on the > firewall ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Le mar. 25 oct. 2022 à 17:47, Michael Richardson a écrit : > > > Peter Naulls wrote: > > Nevertheless, the security people are looking at this config > > statically, and not seeing that it's bound to the LAN interface IP > > only. > > I don't think they are really security people, but... > > > For my use, I've changed the default binding to the LAN IP, and also > > added another init.d script to check the current LAN address, and > > update the uhttpd config if need be and then restart it (and add > > a config hook to the network config). Obviously this isn't > > very satisfactory, open to better suggestions here. > > So, it needs to bound to *all* the IPv6 "LAN" IPs. > That means: > a) the ULA that is created. > b) the LL-IPv6 that are always present > c) the GUA IPv6 that is delegated > > And when we make guest LANs, we may also need to bind it to that, because > there are things that guests might need to know, such as seeing the status > page to see if the network is up. > > > It might also be better if uhttpd could be configured to bind > > to a specific interface rather than knowing its IP upfront, but > > that might be impractical. > > It's totally impractical. Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's really only responding on the right interface ? With complicated routing setup it changes a bit the behavior, but this might be the simplest option if we don't want to rely only on the firewall > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote: From: Nathan Lutchansky My hands are tied, we gotta do the dance. I mean this as gently as possible, but I think what a lot of us are missing is the benefit to the OpenWrt project to carry an increased maintenance burden in response to your internal requirements, which you openly state add no value. Maybe your time is better spent fixing your organization's processes, rather than trying to make volunteers responsive to what we all agree are pointless requirements?? -Nathan Apologies, due to volume, I had put this list on digest and am missing some of the responses not CCed to me and am going to be breaking the threading here. Thanks to everyone for taking the time. My company is small, there's little disagreement on what I've mentioned to date about these issues internally. These audits are done by much (much) larger partner companies - e.g, MS/Intel that I mentioned recently, so there's no chance there to change process. The best response in many cases is well reasoned arguments, but sometimes not. I'm not asking anyone here to do anything; but if my comments serve as useful reference in future to someone who is going through the same process, then I'll consider it time well spent. And if the commentary turns into practical measures, then I'll contribute back what I can. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:45, Michael Richardson wrote: So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated Sorry, I badly paraphrased. The requested change was for IPv4 only. I don't anticipate any IPv6 changes here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 5:34 PM, Peter Naulls wrote: On 10/25/22 17:25, Reuben Dowle wrote: The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. Well, I agree. For clarity, years ago I had been through reviews with both Microsoft and Intel, with some combination of Ubuntu/OpenWrt, so had some expectation here. Those reviews turned up their share of nonsense, but things have changed I guess. My hands are tied, we gotta do the dance. I mean this as gently as possible, but I think what a lot of us are missing is the benefit to the OpenWrt project to carry an increased maintenance burden in response to your internal requirements, which you openly state add no value. Maybe your time is better spent fixing your organization's processes, rather than trying to make volunteers responsive to what we all agree are pointless requirements? -Nathan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Peter Naulls wrote: > Nevertheless, the security people are looking at this config > statically, and not seeing that it's bound to the LAN interface IP > only. I don't think they are really security people, but... > For my use, I've changed the default binding to the LAN IP, and also > added another init.d script to check the current LAN address, and > update the uhttpd config if need be and then restart it (and add > a config hook to the network config). Obviously this isn't > very satisfactory, open to better suggestions here. So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated And when we make guest LANs, we may also need to bind it to that, because there are things that guests might need to know, such as seeing the status page to see if the network is up. > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. It's totally impractical. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:25, Reuben Dowle wrote: I have myself gone through the process of getting an openwrt based product through a security audit. The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. Well, I agree. For clarity, years ago I had been through reviews with both Microsoft and Intel, with some combination of Ubuntu/OpenWrt, so had some expectation here. Those reviews turned up their share of nonsense, but things have changed I guess. My hands are tied, we gotta do the dance. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. I think adding complexity here is a pretty good argument against this. Certainly. But failing an official fix, I'm left to a workaround of my own devising, which is unlikely to be robust in the short term, but will have to do - unless someone has other suggestions. To be clear to everyone here - I appreciate the feedback, and likely agree with everything that's been said - I've been doing this as long as you guys, so I know the ins and outs, but I think the conversation is still worth having. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Security changes - restricting uhttpd addresses
I have myself gone through the process of getting an openwrt based product through a security audit. > I think everyone bothering to read this understands the theatre aspects of all > this that I called out in my original post. Whether things should actually be > fixed (or "fixed") is certainly an open question, but if I can save someone > some future grief, or at least have the discussion, then I might save myself > or > someone else some time. The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. > That said, I think that limiting the listening ports of uhttpd is a good > idea. I > hardly see any downside to it, apart from maybe adding some complexity. I think adding complexity here is a pretty good argument against this. Regard, Reuben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 16:40, Karl Palsson wrote: Peter Naulls wrote: If they see what they want to see, then why should anyone else get involved in their wish fulfilment? Security review is fine, security should not be entertained, and certainly foisted on other people? Karl, not sure where you're going with this. You haven't named anything practical here, apart from suggesting ignoring it. OpenWrt is widely used nowadays, probably more than most people expect, security reviews like this are likely to become more common. I think everyone bothering to read this understands the theatre aspects of all this that I called out in my original post. Whether things should actually be fixed (or "fixed") is certainly an open question, but if I can save someone some future grief, or at least have the discussion, then I might save myself or someone else some time. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Peter Naulls wrote: > On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote: > is much easier to let the firewall zones deal with that. > > > >> As aside, they don't see the iptables tool in the system, and don't > >> understand that that's been deprecated (although I since did add it > >> for some unrelated legacy usage), and think there's no firewall at all. > > > > 22.03? Did you read the release notes? nftables. > > Luiz, I think you might have missed the context of my post - > perhaps you missed my earlier ones. I'm well aware that > nftables is in use, but this is in a security review, and they > see what they want to see. If they see what they want to see, then why should anyone else get involved in their wish fulfilment? Security review is fine, security should not be entertained, and certainly foisted on other people? Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote: is much easier to let the firewall zones deal with that. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. 22.03? Did you read the release notes? nftables. Luiz, I think you might have missed the context of my post - perhaps you missed my earlier ones. I'm well aware that nftables is in use, but this is in a security review, and they see what they want to see. It would be better to improve the uhttpd startup script, allowing it to bind to a list of openwrt interfaces. It is always better to reference an existing config than to duplicate it. Or leave the original bind address. I agree that's a better solution. I don't think I've advocated duplicating config though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
> The default uhttpd configuration has this: > > # HTTP listen addresses, multiple allowed > list listen_http0.0.0.0:80 > list listen_http[::]:80 > > Now, I know there's lots of practical reasons for this to be the case, > and I know also that the firewall setup in OpenWrt is robust and > isn't going to allow WAN-side access. > > Nevertheless, the security people are looking at this config > statically, and not seeing that it's bound to the LAN interface IP > only. It might be easy to bind to the LAN interface in a simple product but OpenWrt might have multiple interfaces. It is much easier to let the firewall zones deal with that. > As aside, they don't see the iptables tool in the system, and don't > understand that that's been deprecated (although I since did add it > for some unrelated legacy usage), and think there's no firewall at all. 22.03? Did you read the release notes? nftables. > For my use, I've changed the default binding to the LAN IP, and also > added another init.d script to check the current LAN address, and > update the uhttpd config if need be and then restart it (and add > a config hook to the network config). Obviously this isn't > very satisfactory, open to better suggestions here. It would be better to improve the uhttpd startup script, allowing it to bind to a list of openwrt interfaces. It is always better to reference an existing config than to duplicate it. Or leave the original bind address. > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. No, there are dozens of services that do just that. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Security changes - restricting uhttpd addresses
The default uhttpd configuration has this: # HTTP listen addresses, multiple allowed list listen_http0.0.0.0:80 list listen_http[::]:80 Now, I know there's lots of practical reasons for this to be the case, and I know also that the firewall setup in OpenWrt is robust and isn't going to allow WAN-side access. Nevertheless, the security people are looking at this config statically, and not seeing that it's bound to the LAN interface IP only. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. For my use, I've changed the default binding to the LAN IP, and also added another init.d script to check the current LAN address, and update the uhttpd config if need be and then restart it (and add a config hook to the network config). Obviously this isn't very satisfactory, open to better suggestions here. It might also be better if uhttpd could be configured to bind to a specific interface rather than knowing its IP upfront, but that might be impractical. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
