Sophos IPS Kill My internet speed

Not currently (except you find a CPU with ~8 - 10GHz per core)...

Lowering # of CPU's or snort instances doesn't help / change anything in that matter.

With 4 cores you should be able to start 3 downloads / perftests / different connections from different sites ~300MBit per each of them summing up to a total of ~900 MBit. But you will not be able to get that throughput in a single connection due that "snort instances bound to a CPU core" limitation. That's how UTM and snort works.

That's maybe one of the biggest differentiator / limitation between a x86 base compared to ASIC / purpose specialized hardware appliances. In normal company usage as border gateway this usually isn't a issue, but that limitation may occur in such special cases as yours where a single connection may use the full bandwidth. This is also true for IPSEC tunnels or other stuff in the UTM too.

There are multithreaded alternatives out there to the singlethreaded snort as Suricata for example. But they usually still aren't as mature as snort today, even if they may offer some benefits in higher throughput for single connections or specific tests, but due multithreading overhead finally reaches lower cumulated top bandwidths with lots of connections compared to multiple snort instances.

Lowering # of CPU's or snort instances doesn't help / change anything in that matter.

With 4 cores you should be able to start 3 downloads / perftests / different connections from different sites ~300MBit per each of them summing up to a total of ~900 MBit. But you will not be able to get that throughput in a single connection due that "snort instances bound to a CPU core" limitation. That's how UTM and snort works.

That's maybe one of the biggest differentiator / limitation between a x86 base compared to ASIC / purpose specialized hardware appliances. In normal company usage as border gateway this usually isn't a issue, but that limitation may occur in such special cases as yours where a single connection may use the full bandwidth. This is also true for IPSEC tunnels or other stuff in the UTM too.

There are multithreaded alternatives out there to the singlethreaded snort as Suricata for example. But they usually still aren't as mature as snort today, even if they may offer some benefits in higher throughput for single connections or specific tests, but due multithreading overhead finally reaches lower cumulated top bandwidths with lots of connections compared to multiple snort instances.

it can depending on what he's trying to do.  an asic is going to have the same issue due to snort's limitations.  anything that runs on an asic might hit the throughput but won't have nearly the detection capabilities of snort..period.  There's a reason snort is number 1.  The underlying hardware isn't the problem.  it is snort's design.  There are ways around it which i have detailed quite extensively.  However Cisco is now pouring tons of resources into snort development and a new MT snort is on the way.  However MT has it's own issues with thread concurrency, cpu memory and cache coherency..etc etc etc that are common to any multi-core system ASIC or not.  Simply rewriting Snort as a MT programs isn't going to 100% solve this issue..but it will drastically enhance it's throughput.  Let's hope that it's detection doesn't suffer at the same time.

Lowering # of CPU's or snort instances doesn't help / change anything in that matter.

With 4 cores you should be able to start 3 downloads / perftests / different connections from different sites ~300MBit per each of them summing up to a total of ~900 MBit. But you will not be able to get that throughput in a single connection due that "snort instances bound to a CPU core" limitation. That's how UTM and snort works.

That's maybe one of the biggest differentiator / limitation between a x86 base compared to ASIC / purpose specialized hardware appliances. In normal company usage as border gateway this usually isn't a issue, but that limitation may occur in such special cases as yours where a single connection may use the full bandwidth. This is also true for IPSEC tunnels or other stuff in the UTM too.

There are multithreaded alternatives out there to the singlethreaded snort as Suricata for example. But they usually still aren't as mature as snort today, even if they may offer some benefits in higher throughput for single connections or specific tests, but due multithreading overhead finally reaches lower cumulated top bandwidths with lots of connections compared to multiple snort instances.

it can depending on what he's trying to do.  an asic is going to have the same issue due to snort's limitations.  anything that runs on an asic might hit the throughput but won't have nearly the detection capabilities of snort..period.  There's a reason snort is number 1.  The underlying hardware isn't the problem.  it is snort's design.  There are ways around it which i have detailed quite extensively.  However Cisco is now pouring tons of resources into snort development and a new MT snort is on the way.  However MT has it's own issues with thread concurrency, cpu memory and cache coherency..etc etc etc that are common to any multi-core system ASIC or not.  Simply rewriting Snort as a MT programs isn't going to 100% solve this issue..but it will drastically enhance it's throughput.  Let's hope that it's detection doesn't suffer at the same time.