Brute force attack
 

some one is brute forcing my member area with multipe country ips and very fast, cannot block it on account of the amount of ips he is using, about 10 diferent ones per second,
cant script anything either on account of ip quantity

any ideas would be appreciate it

Thanks

Get used to it...take all known precautions & just ride out the storm.

People will tell you pennywise this...proxy gaurd that...but nothing works if someone knows what they are doing.

Sorry mate, you're just plain wrong.

To the poster - go get proxypass http://www.proxypass.com/ - it will fix your problem, like it did ours.

When the script denies any attempts to brute force from an open proxy, then they've got no tools. The others like Pennywise and IProtect and such are useless against an open proxy based brute force attack.

Cheers,
Backov

Write a script to deactivate the username/password trying to be cracked and have it re-enabled once the attack is done... shouldnt be too hard to implement.

Joe

Yea im just plain wrong :1orglaugh

We got kevin mitnick from BikiniVoyeur over here.....

I clearly stated "nothing works if someone knows what they are doing". I.E. using non standard port proxies etc. much like the new 3rd generation hitbots.

What does your script scan 3128, 80, 8080, 8000, 8001, 1080, 21, 22, 25 etc.

Any surfers firewall would be lighting up like an x-mas tree.

But its cool, if what you got is working for you then great, just don't tell me im plain wrong.

Well, your users are real people that probably click on the members link to enter your site right? And this script is stupid and will keep hitting the same login page over and over? So why not just do a simple renaming of the login section?

So if your members site is http://www.site.com/members/, just rename your directory something like /member/ and the old directory deleted. This won't prevent the brute force aspect but it won't bog down your server as much from failed login attempts, it will just 401 error the script.

Not a great solution I admit but its a quick solution until you can reduce brute force attacks.

WG

send him the password to get in. Obviously he wants to see the members area. don't be soo cheap - show him the good porn.

You're just plain wrong bud. There it is. Again. I've been a programmer for about 16 years - have you been alive that long?

Anyway, it's not my script. We just use it. It not only scans for tags that the attacker is using an open proxy, there's a HUGE centralized db of open proxies that's constantly updated. It's about as serious as you can get.


Cheers,
Backov

Dear CGI Geek,
If you got Qs, please hit me up on ICQ and we can chat!
#153529369

BTW. Backov is not the owner of the pxp , but he is a client
of ours, here's another testimonial from another one of our clients
"The load times where averaging 5.0 and got as high as 16.0 the same day you installed this I stopped our daily backups as well so I think between the two this server should be smooth. It's doing .3 - .5 all day wow I'm happy this server was crashing daily. On top of the servers already high loads customers where yakking about pennywize which causes even higher loads. So your solution is a miracle in the working. I think everything is fine, I probably going to roll this out on two more boxes next week.

Thank you,

Charles Yarbrough
www.dwhs.net
www.adult-website-hosting.com
1-866-660-HOST"

Also check out TopCash's testimonial at http://www.proxypass.com/modules.php...rder=0&thold=0

Sorry not trying to spam, but people should be aware that there's an alternative to Pennywize and Iprotect.


Best regards,

:thumbsup

PxG

change your member area files or something like that so the robot hammers a file that does not exist

:2 cents:

if you're a true CGI geek, you should be able to figure something out on your own. ya know.

tips from a guy who knows how to do this:

1) avoid any programs/scripts that attempt to "throttle" the crackers in real time. that is a sure path to doom. your server's connections will be so tied up with this throttling that nobody else will be able to get in.

2) don't use ipf - your CPU will be so busy checking each and every incoming packet that it will slow down the site for everyone else.

3) if you don't know how to do it, don't worry about it. just catch the guys who make it in. or assign good passwords.

Just wanted to mention that I just talked to a guy from proxypass.com cause I had a few questions and he got right back to me and answered all the questions I had quickly and he seemed to know what he was talking about. He seemed very proffessional and knowledgeable, I will be using proxypass when I get launched, if it does what it says should be nice addition.

Rory
:helpme

I just wanted to respond to both Salsbury and pr0. Both have interesting points that I'd like to address.

Salsbury: your point about network connections is valid. However, we use UDP protocol which extremely low level and doesn't rely on a three-part handshake. Basically, we average response times of 0.01 - 0.05 seconds to our clients. And, since its UDP there is never any network backup or bottleneck. Also, we do deposit a local db of proxies we've caught on the client system, for fast reference.

pr0: your concern about non-standard port proxies has one problem with it: there are very few non-standard port proxies around. I found a list of proxies on your web site, it was a list of 2065. Our DB currently has between 50,000 - 100,000 open, abusable proxies that we refresh and remove old ones from on a daily basis. Now, I am not sure if all of your proxies are non-standard port or not, but let's assume they are.

You have a list of 2000, more or less. Let's do some math:

1) Our software will also block attempts from the same IP after X attempts (usually 5 or so). As a result, even if we don't detect your 2000 proxies then you will get about 10,000 attempts to crack a password. In the cracking world, this is not a lot.

2) Let's say you optimize your cracking effort and therefore use only 1 username (you've lowered the number of variables you need to guess at to 1 now). Our software also does username blocks after X attempts on a particular username (regardless of IP). So this optimization is now null.

So the bottom line is that since there are very few non-standard port proxies available to a cracker, attempting to crack a site protected with ProxyPass has very little chance for success. 10,000 attempts is VERY LOW, as most cracking requires 100,000s or millions of attempts before a username/pass is obtained. And that's if you concentrate on a single username!
And the most important thing is that your server doesn't handle and return a ton of authentication attempts, lowering the user load average greatly.

The cracker would be much better off to assemble a list of say, 10,000 proxies and attack another site that is not protected with proxypass.

I hope this helps,

attack does not repeat ip per user,
so no conventional method will work,
I have stop proactivly 100 IPs attacks before,
this is very diferent.
Now proxi based software is based on 2 assumtions:
1. Attack signature
Does not have one
2. It knows all open proxies
Numeric imposibility
Also it has to authenticarte ip on query, but next query to log it
would be a killer counting on God giving you a way to tell which IP is bad and which one is not.

I think is more on replacing apache authentication
with something booby trapped with timeouts,
and non standard http headers so damn bot goes crazy,
of course at a great resources cost.

cgiGeek,

We do not simply rely on our DB of open proxies. We actively search for open proxies during an attack, so that you receive denial of proxies in REAL-TIME, even though they are not in our DB yet. Of course, we analyze millions of hits per day between the proxypass and proxyguard products, so we have a very sizable database of open proxies.

We built this program because there is no commercial program out there right now to stop brute force attacks through proxies and because we felt there is room in the market for something that does. Our clients have all seen dramatically improved results, as you can tell by their testimonials and unprompted comments on this and other boards.

Of course, nothing is perfect and the Apache auth scheme sucks.
That's the core of the problem, you are right. But until Ibill, CCbill, and Epoch change their requirements (right now they require apache auth) there is very little alternative. Our program has built in "booby traps" too. I won't get into specifics, but under "heavy attacks" a mode is triggered in which responses are not given to proxy-ip requests. This frustrates bots and spins them into timeout/wait states... it's a little way of saying BACK OFF. This could potentially crash a botters server, etc.

And even if you used php/mysql, the potential is still there for brute forcing via proxies... it just won't take such a dangerous toll on your server (PHP is faster and has less overhead than apache auth schemes). But the physical attacks will still persist and passwords will be stolen.

Best Regards,