Ok, I'm having problems with hackers from across the globe trying to get into our servers. Why? i have no clue. nothing of value in my servers worth getting.

Right now my service only does business with USA. So I'm trying to find a way to block all Non USA traffic. I called my hosting provider and they are unable to help. Said it was up to me to do this.

Well I've already taken care of the TCP Wrappers. by spawning a small C program i made that uses MaxMind's GeoIP system. to automatically deny access. Now i need to do something about all the other network connections that come in to services that do not use the TCP wrappers.

So i was wondering if IPTABLES have a way to spawn a sub proccess like TCP wrappers or if there was any other firewall software out there for linux that would let me achieve my goal.

Please use "crackers" term instead: read "Hacker" term abuse.

What exactly are you trying to do? Are you talking about HTTP-only filtering for US-only hosts or do you mean ENTIRE incoming traffic(do you care about it?). I assume this should be done on application-level.
There is also a recent maxmind-geoip list of all US addresses(or by-country) available here, if that can be of use: http://www.ipaddresslocation.org/ip_...get_ranges.php. Very useful tool in some cases, as mentioned, based on maxmind geoip database, released monthly.
Please, clarify your situation and the troubles crackers are giving you.

I want to block ALL non us traffic. Doesn't matter which port or service. I simply what to stop it before it's passed onto service it's intended for.

I.E. dns requests. If the request is coming from some place out side the US. I don't even want bind to see it. HTTP requests same thing. I don't even want the traffic to reach apache.

Which is why i figured i would use IPtables or something.

Maybe you could use the method I described in this thread?

Of course, you'd be making a good_ips.txt file instead (and using ACCEPT for the IPs, not DROP).

1 members found this post helpful.

That will work. I'll just put in a bash script and set it on a cron job.

Thank you.

Look, that will happen; they don't know what you've got until they have broken in, and anyway a server on the internet is a valuable prize for some (ie, what you've got is large-scale internet access), so you just have to accept it as a fact of life an be prepared for it. Why some get hit more than others is almost irrelevant; everyone has to be prepared for it.

In addition to what you are doing with iptables, ensure that your ssh security is good: look here, for example.

Black list the bad guys, white list the good guys...the choice is yours. Try not to do anything too complex and involved, otherwise you'll replace one potential threat with another.

If you build your firewall ruleset from a bash script, can't you just do whatever else you need to from that bash script (more generally, even if your ruleset is not generated dynamically, it will be run from a script)? Does it have to be a sub-process of the firewall?

What I've set up, I'm liking. This bash script to rebuild the firewall rules is working pretty well.

The way i set the IP tables
Allow My IP always
Look at the BLOCKEDHOST chain (generated via a spawn in the tcp wrappers)
Allow USA only chain
Block ALL others.

Then once a week (cause i'm not sure the exact release day) the bash script downloads the GeoIP database and pull out the USA ranges from it. then flushes the USA only chain and rebuilds it. the proccess takes about 5 minutes.

As for our SSH security. There is only 1 login, root with a 65 character password which is changed monthly. There were 0 failed login attempts for 3 days prior to the breach. Only thing I could assume is a keylogger on a computer or something that picked it up, though no av scans turned anything up.

Regardless of what you want to do, it is a particular bad idea. If you take a look on the currently assigned IPv4 prefixes you will probably notice that there are hundreds of thousands IPv4 prefixes, each of them potentially not being aggregated to a larger subnet and thus eventually allocated to a different country.

For you, this would mean, that you would require that your firewall holds ~ 300k rules. Each packet would therefore need to pass a chain of that many entries. Must I really advise, that this generates both, a huge workload, and enormous delays for your packet flows? Iptables (or any other software firewall without support of ASICs) is not capable to do such a thing. Forget about it. Oh and by the way, unless you want to allow traffic from Myanmar only, also whitelists won't work as the U.S. range alone consists of more than 50% of all entries, creating a comparable amount of rules. If you did not encouter any problems yet so far, you must have no traffic beside of some noise. Your set up will blow up, as soon your server carries really traffic that needs to be processed (e.g. SYN Flood).


Oh, and by the way, this is security by obscurity. IP geo-location is inexact and doesn't prevent anything. Think about tunnels or proxies that may route traffic through the U.S.



Harden your server will bring you more.

1 members found this post helpful.

I believe iptables (recent ones at least) have a geoip module now so you don't need to spawn anything

excerpt from iptables -m geoip -h

geoip match options:
[!] --src-cc, --source-country country[,country...]
Match packet coming from (one of) the specified country(ies)
[!] --dst-cc, --destination-country country[,country...]
Match packet going to (one of) the specified country(ies)

NOTE: The country is inputed by its ISO3166 code.

Not really, you may introduce direct GeoIP support through path-o-matic though. See http://netfilter.org/projects/patch-...-external.html

This on the other hand will perform (somehow). Nevertheless it's still useless to filter location based just out of an IP.