Blocking IP Ranges by Geography

I am dealing with a number of potential spammers/hackers from specific countries flooding my site. I want to try and mitigate this by blocking the IP ranges that track back to each country. I know that IPs can sometimes be inconsistent so this won't necessarily block out all of them. So here is my question:

Are there any best practices for doing this? What are some good sites that outline IP ranges by geographic location for setup?

Blocking SMTP traffic must be done at your mail server. If you do not host your own, then you will need to have your email provider implement this. If you do host your own, let us know what the email server in place is.

Blocking IP traffic can be done at the edge router or if you want to protect your webserver, it will depend on the the web server in place.

If you want to block traffic from some countries at your edge router/firewall, then we will need to know what device you have in place.

Help the community by fixing grammatical or spelling errors, summarizing or clarifying the solution, and adding supporting information or resources. Always respect the original author.

We use Hexamail and it has built in country blocking by IP and also blocking the host country of the URLs contained in spam - that way even if the spammer has a botnet you can block the URLs they are trying to serve that direct users back to Russia etc.

You can even block if the country of the sending IP doesn't match the sender domain country (i.e. the email address is likely to be spoofed)

You should look up the Book "Offensive Countermeasures" by John Strand and
others (http://www.amazon.com/dp/B00DQSQ7QY), which gives very good advice
about how to approach some of this, as well as some insight as to why
blocking various IP addresses is a futile effort.

Blocking SMTP traffic must be done at your mail server. If you do not host your own, then you will need to have your email provider implement this. If you do host your own, let us know what the email server in place is.

Blocking IP traffic can be done at the edge router or if you want to protect your webserver, it will depend on the the web server in place.

If you want to block traffic from some countries at your edge router/firewall, then we will need to know what device you have in place.

Be careful blocking IP ranges so that you don't accidentally block legit traffic.

I dealt with SpamHaus pretty often for a while because our old WAN subnet was apparently a part of a botnet. SpamHaus would block several subnets as a catch-all to reduce spam. This kept us from talking to certain customers.

You can go here to get a start. It provides a list of all major IP address blocks allocated for each country. For countries in Europe and in the Middle East, the name of the company/Internet provider that own these IP blocks is also displayed.

That's better than letting them ALL through, and should reduce the volume
somewhat. And it's not all that easy to spoof an IP address on a protocal
that requires multiple back-and-forth messages, compared to spoofing a
domain name on an e-mail. Of course, it won't protect you from bot
traffic from machines that are in a different country.

Wes,
Are you saying that IP blocking by country IP is a waste of time since there are bad people out there who would not be stopped by the practice?

That sounds like people who say they don't bother to lock their doors since professional thieves can open locked doors. Sure, they can, but it does a good job of keeping bored kids and petty thieves out of your house.

The OP never said this was his only line of defense. The OP is being flooded by spammers and blocking those countries IPs seems a perfectly sane step to me.

I guess I don't understand your point here. What, exactly, are you suggesting? I get that your focus is on security tokens, key exchanges, and encryption as a means of security, but having a nice hammer does not make every problem a nail. The best encryption and authentication methodology does little to mitigate the flood of traffic generated by spammers and the like. By blocking IP ranges, the OP can gain a little breathing room to address issues not related to spammers and script kiddies.

I agree with William, surely its better to use multiple different approaches to blocking spam and intrusions. Sure the most dangerous intruders will easily use a proxy in your local country to send a phishing attack, but the dumb botnets that send thousands of email will be largely stopped (by country IP or IP blacklist) allowing you to see the "wood for the trees" and concentrate on blocking any other malicious attacks. The stats back this up. On our server I see many thousands of email per day blocked (and quarantined) by IP lists and country measures. None of them were desired email

OK, I admit I have an agenda. I'm an advocate of Accountable Anonymity,
where all users of significant resources are identified by an x.509
identity certificate that establishes accountability without disclosing
personal information.

With that you can have DSMRIE = Digital Signatures from Measurably
Reliable Identities Everywhere. No shirt, no shoes, no signature, no
service.

It's not easily done. It's not a downloadable app. It requires
significant changes in the way we do things. So as long as security
problems are going away, we don't need to make the investment :)

Shameless plug: the second edition of my book on the subject, /Quiet
Enjoyment/, will be out shortly.

Sounds interesting actually. Certainly things need to tighten up soon on the Internet in general. Its a shame some of the easier to implement identification mechanisms still aren't widely adopted (e.g. SPF) even by banks.

How will x.509 certificates reduce edge device load? It seems to me, in a situation where you are being flooded by spam and script kiddies, the x.509 scheme would increase the stress load on any edge device since it requires such a lengthy handshake.

Now, if we implement this IP based block prior to the x.509 exchange you suggest, the edge device will have filtered out a large percentage of the incoming traffic leaving more device resources to handle valid x.509 exchanges and speeding up the entire process since unwanted exchanges are reduced in number.

By the way, aren't you concerned that x.509 relies on blacklist rather than whitelist and has no comprehensive single methodology?

So as long as security problems are going away, we don't need to make the investment :)
Many are leery of x.509 due to it's lack of standardization, architectural weaknesses, and known exploits. Are these problems addressed in your new book?

But the increased service load will be offset by dumping all unsigned traffic. If it shows up unsigned, it's ignored.

That does not follow any sort of rational reasoning, IMO.

In your scenario, all of the spammers and script kiddies are allowed to connect and do a key exchange. Those without keys will be dropped. Yet, the complex key exchange for every one of those connections will still take place. There is no offset to edge device stress load, there is instead a measurable increase due to all traffic (even from known bad sources) being allowed the initial handshake followed by a complex and resource intensive key exchange.

With an IP block (by country, black/white list, or other) the connection is dropped upon receipt of the first SYN. Then you can filter out the remaining connections using the x.509 protocol (or whatever suites you). This demonstrably lighter stress load on your edge device will help improve performance and therefore security since a stressed device is a soon to fail device.

That cert has to be used by a supporting protocol. On the web, that means TLS. The TLS handshake (which I posted above) will still take place. Are you implying that a TLS handshake using x.509 PKI does not take up devices resources like reading single packet SYN and dropping the connection based on source IP?

Wes, this is not a nail. Blocking extraneous traffic from known bad sources is better handled first by the simplest method using the least resources. I have to assume you are aware of that simple fact and are going somewhere with this line of reasoning. Otherwise we are forced to assume you will push your x.509 agenda even to the point not only ignoring but actively working against simple and effective methods the OP can take to achieve his goal.

The odd part for me is that these two approaches (source IP block and x.509) are in no way mutually exclusive yet your tone would suggest otherwise.

It may just be a terminology thing, but to verify a digital signature, you
do need to exchange keys.
In order to verify the signature, you need to have their public key. At
some point, that has to be exchanged.
In order to verify the public key belongs to who you think it does, you
also need trusted 3rd party public key (usually a CA).
Encryption is still involved as well. In order to get a digital signature,
you need something to actually sign. If you don't want to be open to
replays, that something should be random. So you need to:
- generate some random bytes and send them to the person who you are trying
to verify
- The person has to then generate a hash of the random bytes
- Then they have to encrypt the hash and send it back to you
- Then you have to decrypt the hash with the public key (which verifies
that the remote person has the private key matching the public key you
trust is theirs).

So, there are definitely keys being exchanged and there is encryption going
on, amongst other costly mathematical operations.

Digital signatures do not require key exchange. It's a much lighter weight procedure than encryption.

A digital signature is a key exchange. x.509 is a PKI scheme.

A digital signature scheme typically consists of three algorithms:

A key generation algorithm that selects a private key uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.

A signing algorithm that, given a message and a private key, produces a signature.

A signature verifying algorithm that, given a message, public key and a signature, either accepts or rejects the message's claim to authenticity.

Two main properties are required. First, a signature generated from a fixed message and fixed private key should verify the authenticity of that message by using the corresponding public key. Secondly, it should be computationally infeasible to generate a valid signature for a party without knowing that party's private key.

Yes, you need to get the sender's public key. In most cases the
recipient already has it.

The term "key exchange" refers to the resource intensive process of
generating and sharing an agreed-upon symmetric key for encryption and
decryption of whole files, not hashes. The encryption involved in
signing is asymmetric encryption of a hash using a private key, to be
decrypted by anyone who has the public key. No symmetric key necessary.
This is not a resource intensive process.

Also, the procedure you describe implies two steps between sender and
recipients, but in most cases it's a single step. I hash your received
message (it's in plaintext, no decryption necessary) and I
asymmetrically decrypt the signature (signed hash). I can also use OCSP
or CRL to verify that your keys have not been reported compromised.

If the two hashes are the same, I know that the message was really from
the person from whom it purports to be and that it has not been altered
in transit. No key exchange necessary.

You mean you believe that every time you want to sign something you
generate a new key pair?

No, when you are enrolled a key pair is generated (multiple key pairs if
done right). One is designated the private key, the other the public
key, the publick key is sent as part of a certificate signing request to
a certification authority, after which you use the corresponding private
key to sign as many hundreds of messages and files as you want.

The whole point of signing is the establishment of authenticity. "The
identity claim of the person with this key pair has been checked out. We
are measurably certain that he is who he says he is."

If you generated a key pair every time you went to sign something, what
would be the point?

Vastly more resource intensive than dropping initial SYN based on a blacklist and could still be implemented post blacklist check thereby reducing the overall impact on system peformance.

No key exchange necessary

No symmetrical key exchange perhaps, but your client still provides a key to the host which has to be decrypted.

key exchange is a red herring in any case.

Your method does not solve the OP issue.
Your method only allows for previously approved connections (cannot be used on a public web server).
Your method will reject all SMTP traffic unless the senders email server is specifically designed to connect to your mail server and has been previously approved.
Your method is in not germaine to the discussion at hand "Blocking IP Ranges by Geography"
Your method is resource intensive.
Your method is expensive to implement
Your method is easy to get wrong giving the potential to harm the end user through poor implementation due to a lack of standardization and inherant flaws with x.509

Well, it's good to see that's working well, security issues are declining, and the cost of implementing a system of reliable x.509 based identities is unnecessary

Your facetiousness aside, I very much agree with that last bit. Do you really think x.509 is the magic bullet to fix all of our security problems? If so, then why isn't it working?

x.509 is not reliable, not secure, deeply flawed, and needs to be put out to pasture. Any scheme based on trust is deeply flawed.

Beyond that, your version of an x.509 implementation is based on knowing everyone who will ever visit your site as well as the assumption that you can trust those you have provided a key to. It is ridiculously useless to anyone doing business on the web.

You are advocating something you have never seen done? If universal x.509 identity credentials established through reliable enrollment processes has not been implemented (that you know of) how can you suggest it as a solution to anything other than a pipe dream?

All of this has been what? a dance through Wes Kussmauls imagination land of things he would like other people to pay for?

I'm aware of your past. I am also aware of The Authenticity Institutes QEI agenda. However, when someone comes to ittoolbox.com asking specific questions, suggesting they implement something that has never been implemented before (even by your company who advocates it) is beyond hubris. Unless you are here to actually participate, what you are doing is what most of us call trolling.

When your QEI team implements, documents, and demonstrates your technology, you might have standing. Until then, suggesting completely imaginary x.509 implementations in response to a real request for help is a waste of everyone's time.

no one had seen a consumer oriented social network before I built Delphi, which we sold to Rupert Murdoch's News Corp.

Well, no one but CompuServe customers since 1969 and The Source members since 1979 (and the rest of the computing world chatting on the thousands of public BBS systems).

Attempting to parlay your sale of the digital encyclopedia company that became Delphi to Newscorp (who dumped it in under 3 years) in to some sort of qualification seems like misty eyed reliving of past glory and amounts to little more than name dropping.

I understand that some people believe that tomorrow will be no different from today. I'm sure that's comforting.

I live in the world of change Wes. I was born to it. I didn't come in to it later in life as you did. That's why I see your x.509 scheme as outmoded, outdated, archaic and needing to go the way of the dinosaur and of Delphi.

It started when I noted the weakness of IP address mapping as a means to
thwart attacks.

An MIT Technology Review cover story a few years back entitled "The
Internet Is Broken." I realize that no single person here can do much by
themselves to fix it, but neither should we throw up our hands and say,
well, we all just have to get used to living in a cardboard box in Times
Square.

I agree that internet security is a major concern and needs addressing. I don't think it's appropriate to use a thread where people are asking for help as a means to push your companies agenda.

If you would like to discuss x.509 or internet security in general, go ahead and start your own thread. You can discuss it to your hearts content. Just don't step on someone elses thread pushing imaginary schemes and confusing the issue.

I really had high hopes that you where going somewhere with your line of thought so I asked direct questions about your idea hoping you would be leading to some helpful advice.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.