I was thinking.. Wouldn't it be cool if we could bock entire countries (China) in the Members area so that it wouldn't even reach our node I'm doing it on my iptables but still.. Would be neat to take all those ip ranges off my firewall load!

How would this be cool?

James

It would be cool in that my mail server would be under less load (less spam to accept and filter out), thereby lowering CPU utilization, thus less power draw and less heat generated. It, the host and the dc, could therefor technically be cool(er).

Yes. Exactly. We also have to mention iptables filtering, web script vulnerability scans, sshd bruting, FTP bruting, DNS exploit attempts, port scans and all the logs that come with it. It's just unnecessary garbage we have to deal with and we all know where most of it comes from.

Yeah, I gave up on even sending abuse complaints to that country, because most of their whois information is out of date, abuse@ e-mail addresses bounce, and when they don't, the messages just get ignored more often than not. Indeed, I wish Linode would let me block all traffic from the United States; it would cut down on problems substantially.

Count me in on blocking countries, personally I'd like to block countries like China, N.Korea, and Nigeria.

Instead the linode routers would have to inspect and pass/fail every packet, even those not destined for your servers. Which puts more load on the routers for _everybody_. Routers don't have infinite bandwidth and the more rules added to them the slower they run.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

I don't remember ever getting spam from North Korea... Hardly anyone has internet access there! But then, perhaps Kim Jong-Il is so desperate for money that he got into the spamming business...

No spam but I've had a few attempts to hack .....

Well, you mean a dedicated box running as a firewall? I'm sure a dedicated could take all that with little effort but then I don't know how much traffic we're talking about. But that's the whole point - to take the load off of the individual nodes (and therefore the entire box) and onto a bouncer at the front door.

An interesting question might be: Which solution would take more "resources?" I know the answer: neither - it's the same load.

However, If there are 500 IPs on a machine, each node will eventually have to deal with the traffic/security; creating 500x the load on that machine as opposed to 1 dedicated taking it all for us. I don't believe these people are targeting specific IP addresses. I *think* they're just working with certain IP blocks.

Of course, I don't think this will ever happen. That's why I said "Wouldn't it be cool" In other words, it's just me bitching aloud.

But it's not reducing the load; it's centralizing the load. There can't be a "block all traffic from 1.2.3.4" rule, because I might want to see that traffic. So the rules would have to list source and destination (block traffic from 1.2.3.4 to A32's IP address). Now, let's say "Jim" also wants to block 1.2.3.4; the central router would now have two rules. So, instead of 2 boxes only blocking traffic they care about we have one box inspecting and checking the packet against two rules. This actually uses up more CPU (more packet inspections) than if each machine only inspects traffic destined to that machine.

In addition to this, traffic to _my_ machine will be inspected, even though I don't want a block. And this does slow traffic down... fractionally. When we get to 500 machines each of which might be blocking 15 different IP ranges, my traffic will be compared against 7500 rules. Now the slowdown will be noticable.

What you're doing is building a bottleneck and increasing processing load.

A central block, such as you suggest, is only efficient if it's mandatory to all machines behind the router; once you allow per-machine rules then it's inefficient.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Yeah. I kinda realized that mid-way through my post. It would have to be on a machine specifically for people that didn't want that traffic.

However, I'm wondering about:



The question is, "inspected against how many rules?" At what point does the amount of iptables rules start to noticeably affect the node's performance?

A quick google finds http://courseware.ee.calpoly.edu/3compr ... curity.pdf

The results also show that the percentage
overhead generated by a firewall when a single packet
of 64 bytes of payload travels the TCP/IP stack, for a
rule-set of zero and 100 rules, ranges from 6% to up to
75%, respectively.

Also, remember, that the linode host itself may already have some rules in place to stop one customer hurting another (iptables and ebtables, probably).

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

A lot of the brute force attempts can be thwarted by using high ports.
I was getting constant ssh brute attempts when first set up.

I did not use iptables to deal with it, the brute force detection solutions that add to your iptables really grow your iptables fast.

I used pam_abl to deal with it - and changed the port number.

pam_abl is a PAM module that creates a bdb database of failed attempts, and when too many - it then refuses to authenticate attempts from that user@host or that host even if they do get the right password. The beauty of it is that it doesn't gum up your iptables.

I also changed to a port > 1024.
Most kitties don't even bother scanning for an sshd running on a non standard port, and even fewer will scan for ports above 1024.

Run sshd on a port > 1024 and you'll find brute force ssh attempts virtually disappear completely.

With respect to ftp - I can't help you there, but the only way I ever would run an ftp server would be anonymous only, so brute force attempts would fail because no one could log in except for anonymous.

As far as DNS goes, I can't help you there either, I don't do my own DNS and have no desire to.

run services that support DNSBL's.