Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[Markus Stenberg <[e-mail]>]

> On 23 Nov 2016, at 3.34, james woodyatt <[e-mail]> wrote:
> On Nov 22, 2016, at 14:39, Markus Stenberg <[e-mail]> wrote:
>> 
>> The recent IoT DDoS publicity is a good example; the devices that are the Mirai botnet are devices that had/have open ports facing the internet.
> Not quite, c.f. <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/>
> 
> The vast majority of those devices were protected from receiving inbound flows over public Internet routes by the stateful filters of IPv4/NAT gateways.

Interesting. I read somewhere elsewhere that upnp igd was part of the problem but not the main one.

> p1. Those ports would not have been open and facing the Internet except they were also configured to use UPnP IGD to punch a hole through their firewall to expose their unsecured services.

So the default opt-out policy of hole punching is broken.

> p2. More importantly, they were also open and facing other compromised hosts on the same network, which were vulnerable not because they had open ports facing the Internet but because they were exposed to malware by legitimate requests to web servers at public Internet destinations.

I did not read that in that article at least. I can believe infested Windows hosts can contaminate anything near them.

> The calls [in both cases p1 and p2] were coming from inside the house.

Default drop inbound policy would have worked in the p1 case; p2 case on the other hand, the moment you have someone inside the network, you are lost, given the modern software quality.

>> It is all about reducing the attack surface.
> What attack surfaces were reduced? None of them were turned on at all. And why? Because, strangely, the industry in which we work engineers so many of the systems, which ordinary people are expected to use, in a way that makes them unusable unless all the security mechanisms that reduce the attack surfaces are disabled or bypassed by default.

At least based on my reading elsewhere, there is quite a bit of IoT hardware that actually has direct IPv4 address as well. And median time to infestation is minutes in the current IPv4 land. I also seem to recall that the ‘unpatched Windows - time to infestation’ benchmark also was minutes already ten years ago. (current Windows has saner default policies though, so I am not sure if that is applicable any more.)

> It’s not about reducing attack surfaces. It’s about making systems that are safe for deployment in close proximity to humans.

Sounds like an impossible dream then, given how prevalent the default username+password has been since 90s. Or buffer overflows. Or SQL injection attacks. All of that has been with us 20+ years and seems to be just more common, not less common, as the time goes by.

> ... and this knowledge is not new. The conficker paper from 2009 found that "144,236 (78.9%) of the infected machines were behind a NAT, VPN, proxy, or firewall". We should know this by now :stateful firewalls do not protect against malware.

There are also two other potential readings to this;

- the nodes could also move and be infected elsewhere, or

- they can make requests to the outside world with bad actor somewhere in the loop. At least earlier, the main _computer_ infection vector were essentially humans, who clicked ‘funny picture.exe’ and ignored security warnings.

IoT land, there is no human in the loop, so there is bit more hope, given software quality is sufficient, as people do not have access to run the ‘funny picture.exe’ as root on the devices.

Cheers,

-Markus