How to restrict website access by country 1

[J1mbo]

I had a hacker deface my website a few weeks ago. I've since blocked his IP address range from accessing my site.

I'm was wondering if anyone has a mapping of IP addresses to countries so i can block everyone outside the US?

I've looked around google w/o any luck. Thanks,

 

[cLFlaVA]

right. i forgot - hackers only exist outside of the USA.

http://www.google.com/search?hl=en&lr=&c2coff=1&q=ip+address+country&btnG=Search

*cLFlaVA
----------------------------
[tt]I already made like infinity of those at scout camp...[/tt]
beware of active imagination: [URL unfurl="true"]http://www.coryarthus.com/[/url]

BillyRayPreachersSonIsTheLeetestHax0rDude

 

[manarth]

can anyone say 'proxy server'?

<marc>
New to Tek-Tips? Get better answers - faq581-3339

 

[J1mbo]

Thanks for the link.

I understand proxies and that hackers exist in the US. I'm trying to eliminate the larger threat and make it not worth their time to bother with me.

I can prosecute someone in the US much easier than say Russia or Turkey too. Cheers,

 

[BillyRayPreachersSon]

Hmm... the word xenophobic springs readily to mind here!

Dan


[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[Wullie]

I'm trying to eliminate the larger threat and make it not worth their time to bother with me

What makes you think that something as simple as an IP block will stop them wanting to deface your site? Adding an extra challenge for them is likely only to make them more determined to show you that they can still do it.

If you want to stop the site being defaced, find out where the security hole is and fix it. Blocking IPs after they have already defaced your site is a pretty pointless thing to do.

Hope this helps

Wullie

Fresh Look - Quality Coldfusion/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[GUJUm0deL]

Call your hosting company and let them put your site behind a firewall.

[sub]
____________________________________
Just Imagine.

http://www.imajinarts.com

[sub]

 

[Wullie]

Call your hosting company and let them put your site behind a firewall.

A firewall is a good suggestion for a personal computer to stop people gaining access, but isn't the same for a server.

You cannot stealth the server unless you want to block everyone from accessing your website and a firewall will not stop someone gaining entry through a vulnerable script on your site.

A firewall can block unused ports, it cannot block ports that you deliberately have open otherwise why have the server in the first place if nobody can access it? It would be the equivelant of opening a shop and having a gate stopping anyone getting in to buy something.

Because only a site was defaced I would be willing to bet that they did not gain root access of the machine through an unused port.

Hope this helps

Wullie

Fresh Look - Quality Coldfusion/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[GUJUm0deL]

What I meant was the hosting company can block all unused ports (some hosting providers don't do that, my previous employer used RackSpace, and they had over 1000 ports opened and were listening, it wasn't until I noticed that and notified them to close all ports except a select few), typical ones that are open would be port 80, dB port, FTP port. But i'm guessing other portsd (unless his site uses other ports) should not be open, am I correct??

But you're suggestion in finding the security hole and fixing it is a better assessment in his situation. I guess he can ask his hosting company to make sure they have all the current security patches.

[sub]
____________________________________
Just Imagine.

http://www.imajinarts.com

[sub]

 

[Wullie]

A huge amount of the servers out there don't have firewalls on them, however there is nothing to suggest that this host doesn't.

Look at the points we know:

1) Site was defaced.
2) Customer wants to block IPs to prevent happening again.

Taking point 2 on it's own and assuming this is a shared server, then what is the point of blocking IPs if it wasn't your site the security hole was in? If the server was rooted then blocking IPs from a site unrelated to the attack is pointless, because they can still access the server.

From this I can only really assume that the security hole was on the OP's account/site, which in this case a firewall will do nothing on it's own, the only available option is to secure the site so that it doesn't happen again.

Hope this helps

Wullie

Fresh Look - Quality Coldfusion/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[GUJUm0deL]

Is it just me or was a portion of this thread deleted?

[sub]
____________________________________
Just Imagine.

http://www.imajinarts.com

[sub]

 

[manarth]

Is it just me or was a portion of this thread deleted?

It happens.

<marc>
New to Tek-Tips? Get better answers - faq581-3339

 

[mkrausnick]

J1mbo, can you determine how this happened? Have you come up with a list of possibe vulnerabilities that could have allowed your site to be hacked?

Is it possible for the hack to have been allowed by something in the code of the site itself, and if so, what sorts of coding can allow a site to be hacked?

I maintain several web sites on a volunteer basis and know next to nothing about security, so I'm asking for my own education.

One obvious question (with apologies if this is a dumb question): Is it possible the hacker obtained or guessed your FTP id and password and simply logged in and uploaded the defacements?

Mike Krausnick
Dublin, California

 

[damber]

mkrausnick,

There are plenty of techniques for comprimising a website. Though excluding all the normal OS attacks here are a few simple examples;

1. SQL Injection - an unchecked SQL statement dynamically generated from variables passed by the user which contain certain hacks (e.g. "' OR 1=1" as the password )

2. File Uploads - allowing users to upload files without checking the type of file can lead to them uploading scripts that they can execute and use to perform actions on your site.

3. Cross Site Scripting (XSS) - this can lead to DoS attacks from unsuspecting visitors to your site - if a user uploads a script (e.g. javascript) this (when a user views it as part of your page - e.g. blog comments etc) could be used to continually request your site, or propogate to more pages/posts etc - a recent example of this was MySpace. This can be used for other things besides DoS.

4. WebServer Vulnerabilities, e.g. Global.asa access (for unpatched ASP Servers) - although quite an old vulnerability, if your host hasn't patched their server correctly a specially formed HTTP request can trigger the response of the contents (code) in the global.asa - which can have security information in it.

5. Password/security Files - it is easy to place unsecured information into a readable (though not necessarily directly navigable) file, which can be searched for or blind tested by attackers - always secure every page - for example .inc renamed to .asp / .php / .jsp etc.

6. Using Debug Information that has been left in the source code - not an attack vector, but an info gathering exercise that could be used to formulate an attack

7. Exploitation of Server side processing methods that do not cleanse input data (similar to SQL Injection) - functions that execute literal code generated by inputs from the user - or use that to access the operating system (e.g. filesystem). Though you would expect developers that work at this level to be somewhat aware of the potential risks and necessary steps to safeguard themselves.

8. Bypassing client side validation - NEVER rely on client side validation to secure the inputs - users can use tools like telnet or netcat to send the HTTP request, and therefore bypass any security you put into your client side script.

9. Hidden form elements holding sensitive data is surprisingly still done - with everything you do - DO NOT TRUST THE CLIENT SIDE !!

10. Server Side Includes... again from user input may trigger the server to execute them at some point.

OK, that should be enough examples, but there are plenty more. The main point to take from this is that treat every bit of informtation from the client machine as potentially dangerous, and filter out what shouldn't be there. Also don't send anything to the client if it should be secret - e.g. passwords in cookies, or in the URL or hidden form elements.

A smile is worth a thousand kind words. So smile, it's easy!

 

[BabyJeffy]

Good points... and excellent post there damber.

Though you would expect developers that work at this level to be somewhat aware of the potential risks and necessary steps to safeguard themselves.

Indeed you would. And you would probably not be that surprised to know that there remain those out there who have responsibility on this level -- and still fall into the same traps.

Cheers,
Jeff

[tt]Jeff's Page [/tt][tt]@[/tt][tt] Code Couch

http://www.codecouch.com/jeff/

[/tt]

What is Javascript? faq216-6094

 

[mkrausnick]

Damber,

Wow, that's worth a star!. Thanks for taking the time. You should consider turning it into a FAQ and expanding it to include some of the "plenty more" you referred to.

I think I'm OK on most of the items on your list but I'm definitely going to review all my site code.




Mike Krausnick
Dublin, California

 

[damber]

Thanks Jeff & Mike,

Indeed you would. And you would probably not be that surprised to know that there remain those out there who have responsibility on this level -- and still fall into the same traps.

Very true - some developers by accident (we all overlook things now and then), but sadly some through complete ignorance...

A smile is worth a thousand kind words. So smile, it's easy!

 

[Wullie]

The most common problem when a script is exploited is that the script has been downloaded from the Internet and not kept up to date.

For example, you download a forum (PHPBB has been hit very hard with this recently) and then leave it without checking to see if any new versions have been released.

The reason that these scripts are very commonly exploited is that the person has access to the source code for that script and when a security issue is found, they create worms that search the Internet looking for any vulnerable scripts. Because they have the source code, they know exactly how to exploit the script.

I see this on a daily basis where people assume that because the script is the latest release at present, it will continue to be stable/secure, however this is not the case.

You need to make sure that you signup for any announcement lists for the scripts that you use and upgrade the script as soon as a new security fix is released.

Hope this helps

Wullie

Fresh Look - Quality Coldfusion 7/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell