Design for security

Posted Feb 1, 2019 9:42 UTC (Fri) by nim-nim (subscriber, #34454)
In reply to: Design for security by Cyberax
Parent article: Design for security

>> 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?