Design for security

Posted Feb 1, 2019 8:39 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Design for security by nim-nim
Parent article: Design for security

> It's hard to design locked down workstations that do not do more productivity damage than the middleboxes.
You don't need to lock down boxes. Just install mandatory firewall rules, software inspectors and anti-intrusion software. This can be almost completely transparent to end-users.

> And even when you lock down workstations, are you going to remove browsers too?
Why would you want to remove browsers?

> Lastly, enforcement through logs does you little good when *network hogging*
Is it seriously even an issue these days?

Design for security

Posted Feb 1, 2019 9:42 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (6 responses)

>> Lastly, enforcement through logs does you little good when *network hogging*
> Is it seriously even an issue these days?

Yes.

Home access nowadays can be 1 FTTH per family, so basically one high-bandwidth link for ~ 4 people.

There's no way any sane corp will provision the same per/user bandwidth ratio on any work site with 50 people or more. The economic model works for home access because its main point is to slurp high-volume entertainment, so home users are ready to pay tens of $ per month and user just to get access to their videos and games. The per user budget for network @work, where users are mostly supposed to exchange mails and access some webified corp apps, is not the same.

Add to that that a byte of corporate bandwidth is more expensive, because corps want some warranted availability (it's expensive to pay people to wait for network to go back up), and you have all the security systems trying to detect intrusions (cost scales with amount of traffic to check), while home bandwidth is dirt cheap (zero security processing, best effort availability levels, no link redundancy).

So basically, network @home and network @work are not the same thing, it's different technical compromises, and all the high-volume low-security low-availability use cases people are used @home do not translate well @work.

Design for security

Posted Feb 1, 2019 9:55 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> So basically, network @home and network @work are not the same thing, it's different technical compromises, and all the high-volume low-security low-availability use cases people are used @home do not translate well @work.
No. I'm speaking about one endpoint device (an intern's laptop?) displacing all other users. As far as I'm aware all sane routers will not allow this.

Design for security

Posted Feb 1, 2019 12:06 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

That depends on the complexity of your network topology. It's easy to manage on border equipments, not so much when you get closer to the backbone. And, unfortunately, humans are social beings, so you can be sure whoever invents a new way to make the network crawl to a stop, will have bragged about it to friends, that will participate in the DOSing.

Design for security

Posted Feb 13, 2019 16:41 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> No. I'm speaking about one endpoint device (an intern's laptop?) displacing all other users. As far as I'm aware all sane routers will not allow this.

And where do I buy said sane router?

My home internet regularly collapses under load. The cause clearly seems to be down to my (reasonably modern) router. And I strongly suspect that actually the cause is the link from there back to the ISP router.

There is a VERY long-standing bug in equipment called "buffer bloat" where a single end-point device *can* displace all other users, and there's probably a hell of a lot of equipment still out there that suffers from this. New versions of the linux kernel work around this, but how many devices are still sold brand-new with old kernels, or haven't been upgraded in years?

Cheers,
Wol

Design for security

Posted Feb 21, 2019 2:50 UTC (Thu) by fest3er (guest, #60379) [Link] (1 responses)

No need to buy anything. Get a late-model PC (dual-core, 1.6GHz CPU or faster, 2GiB RAM, SATA HD, and 2-4 NICs depending on how many zones you want), and install Smoothwall Express on it. I spent a good amount of time getting its QoS (Traffic Control) to work well. Since I released v3.1 in 2014, it has done a very good job preventing any traffic stream from hogging bandwidth. No matter what I do DLing or ULing, all streams share the bandwidth fairly (almost equally). I can have multiple GB downloads and uploads going with none blocking any others. Interactive response is still very good. Identified isochronous traffic is very smooth. DNS and NTP traffic are very timely. Low priority bulk traffic (such as P2P) can use any B/W left after all higher priority packets have been sent. It isn't perfect. Or complete. But it does work well. And is still designed for non-experts; they need to know some technical stuff, but most of the jargon and arcana are hidden from them.

Linux's Traffic Control is poorly documented and leads to impossible expectations. I designed a nice JS-based configuration tool that I eventually abandoned because LTC just cannot do what the documentation says. However, once I really understood what it can do and what it cannot do, I was able to 'fix' traffic control so that, for the most part, traffic flows smoothly. LTC also cannot easily control multiple interfaces; for example, a gigE NIC might be able to 'block out' a 100Mb/s NIC when they both 'send' to a 10Mb/s internet link.

I haven't addressed buffer bloat. 'ls -lstr /' through an SSH connection results in ^C being unresponsive for 5-10 seconds. But dealing with that much output doesn't happen too often.

In short, there *are* Linux-based routers that do a nice job of enforcing bandwidth sharing. And some of them are free.

Design for security

Posted Feb 22, 2019 15:22 UTC (Fri) by nix (subscriber, #2304) [Link]

I haven't addressed buffer bloat.

These days, for wired Ethernet at least, just switching to fq_codel or CAKE on your bottleneck link with the default parameters (or default plus telling it what your ADSL encapsulation etc is) should be enough to fix that, as long as your NIC driver supports BQL, which most now do.

Design for security

Posted Feb 8, 2019 7:33 UTC (Fri) by anton (subscriber, #25547) [Link]

I work at a university with about 2000 staff and about 20000 students, and we don't have any of the restrictions discussed here, and network hogging is not a problem I am aware of (not even in those days when the students did not all have internet at home or in the phone); I think there was one episode a few years ago where a virus or something was rampant in the university network, and apparently overloaded it, but the typical reason for the rare occurrences of network outage is when some piece of hardware fails (e.g. a router dies).

So my university invests in enough bandwidth to allow pretty free internet access, but does not invest in redundant routers etc.; what's different for corporate environments?

Design for security

Posted Feb 1, 2019 9:46 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (6 responses)

>> It's hard to design locked down workstations that do not do more productivity damage than the middleboxes.
>You don't need to lock down boxes. Just install mandatory firewall rules, software inspectors and anti-intrusion software. This can be almost completely transparent to end-users.

And that's almost exactly the processing middleboxes do, except you only need to manage a handful of centralized middleboxes, instead of getting the correct conf on (tens/hundreds) of thousands of workstations.

And if you complain middleboxes are badly configured, how exactly do you expect the same processing to be configured correctly when multiplied by thousands of endpoints or more?

It's not that is is technically impossible, but a corp that skimps on correct middlebox maintenance, is unlikely to be generous on endpoint maintenance.

Design for security

Posted Feb 1, 2019 20:10 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> And that's almost exactly the processing middleboxes do, except you only need to manage a handful of centralized middleboxes, instead of getting the correct conf on (tens/hundreds) of thousands of workstations.
No, middleboxes only see network traffic. They can try to decrypt it, overcoming more and more counter-measures, but they are fundamentally limited.

If your users have laptops then the middleboxes won't see anything that happens outside of the company, when a laptop is used in a Starbucks (for example).

Management software can ensure that the firewalls are configured correctly and it has quite a bit more access to browsers (via group policies) and other software. Also if you have hundreds of endpoints, you probably should manage the client devices anyway.

Design for security

Posted Feb 1, 2019 21:12 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (3 responses)

That's trivial to handle, just deploy a firewall that forbids everything except the corp VPN when outside the corp network

Design for security

Posted Feb 1, 2019 21:15 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> That's trivial to handle, just deploy a firewall that forbids everything except the corp VPN when outside the corp network
Try it. Go on, try it. I dare you.

Hint: this won't work. Even Starbucks requires you to click through the captive portal page to get access to WiFi. Ditto for GoGoInflight and approximately most of other public access points.

Design for security

Posted Feb 2, 2019 12:10 UTC (Sat) by nim-nim (subscriber, #34454) [Link] (1 responses)

That actually works (not my domain, I haven't looked at it, but I think the desktop firewalls let pass the first few requests without filtering to let the portals show up). Or they just let google search been redirected, as that's the internet for a lot of users.

Design for security

Posted Feb 2, 2019 20:51 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Which ones? The firewall on Mac OS X will not disallow outbound connections. It will simply block incoming connections (possibly with exceptions for signed binaries).

You can install additional firewall software but at this point you can just as well install a full-blown management client instead.

Design for security

Posted Feb 1, 2019 21:51 UTC (Fri) by rodgerd (guest, #58896) [Link]

They also break more security measures than they solve problems; cretins with middleboxes masquerading as security experts have done more to undermine security that most black hats could dream of.