Design for security

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

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