strainer

Ok, new paysite here. 16 signups first day, grinning from ear to ear, and now I start seeing tens of fucking thousands of password quesses in the logs, all from different ip addresses.

If it was just one clown I could block him with iptables, but it looks like a coordinated attack to me with dozens or maybe even hundreds of servers, what do I do now???

Anybody have a script that can parse the logfile and generate an iptables block for anybody with 10 wrong guesses or something???

Dragon Curve

My bad I misread your request. There are Apache modules that can reject attacks like this I'm sure - check www.apache.org.

strainer

I don't think so. Apparently the password suckers hit you with hundreds or maybe thousands of servers at once. Its almost like a dos attack, there are so many incoming.

The only thing I can think that would work to block all the ips for a while till they go away!

Dragon Curve

Hm it's going to be pretty difficult to protect if they're using that many servers... it'd be hard to separate the real users from the attackers.

Dragon Curve

http://modules.apache.org/search?id=493
http://modules.apache.org/search?id=494

you could try those.. I'm sure there are other similar modules

clickpimp

gunfire, scalding oil, and Raid can sometimes slow them down ...

strainer

What I need now is a script that will read the error_log and generate an iptables block for every one that has more than say, 10 failures.

No too hard, really, somebody must have already done this???

That would put all 1000 hackers out for the rest of the day...

Dragon Curve

http://www.networkdweebs.com/stuff/security.html

that sounds like it will help you in the short term

use some nice grep and awking to read from that error_log file and generate your iptables blocks

Fatbrain

Ummmmmmm...He's not DOSing you...He's trying to brute force crack your site...Easy to do...Look up www.deny.de

He's not really hitting you from tons of different servers...Well, ok, *kinda*, he's using a large list of proxy servers and it uses a different one for each attempt.

If you go blocking IP tables, your possibly blocking legitimate customers...Baaaaaaaaad ju ju.

Delete the fucking user/pass that's being used...It's that simple...Then, if your a cool webmaster, email the dude with a new user/pass he can use...If it happens again with his new user/pass...Cancel his ass.

Fatbrain

In fact, from what your talking about, he probably got a sucessfull user/pass combo and posted it to a password list.

Fatbrain

Also, is this server setup by yourself or is it a virtual hosted site?

There is nothing you can really do, except modify a .htaccess to reply 200 "ok" or 200 "successfull" reply for each bad login...This makes it nearly impossible for them to determine if they ever got a sucessfull hit on the user/pass or not because all come back successfull...They will then soon give up.

strainer

No, the problem is, he is trying a list of several thousand or maybe hundreds of thousands of passwords, and from thousands of computers or proxy servers.

Not a single one worked, and none ever will, because I force assign all my users randowm passwords.

I'm just worried about the resources he is using, and that he might crash me...

strainer

Is my own dedicated server. Do you have the .htaccess mods? WHat would that mean to a legitimate user, who enters a bad password by mistake?

Fatbrain

As I said, he's trying to brute force into your site...Read above post and check out www.deny.de

It's very simple to do and will even work well on a dialup connection...If your going to run a paysite, get used to this, it will consistantly happen, unless you use html form logins, which actually can still be brute forced.

Fatbrain

Gimme your ICQ/AIM/MSN

strainer

Cool. They just exhausted their list. Generated a 20 meg error file in 20 minutes, sick fucks. I would like to find a way to fend them off next time...

Dragon Curve

Yes he won't be using one user/pass.. he's brute forcing.. most likely dictionary attacking both username and password. The Apache module I posted will block these attacks but for a certain amount of time.. drastically reducing the attack.

Fatbrain

It will block coming from the same IP only I believe...If he's good, he's got a HUGE list of proxies to run through...Using .htaccess to reply 200 for a bad user/pass fends them off REAL quick.

Using Apache to block only repeated tries from the same IP won't do any good.

strainer

Right, since he is using hundreds or maybe thousands of legitimate ip addresses (ok proxy servers we think) I don't want to ban them.

I think the solution might lie in the .htaccess 200 thing, but I'd like to experminet with that one.

Right now, I'm fucking tired though. Gonna go sleep on it and take a look tomorrow!

Dragon Curve

Returning 200 will prevent browsers from requesting the password again on a first password failure. Will make things confusing if a user mistypes their password/username.

SykkBoy

You might also want to check out this, see if your site in on there...:
http://irc.scservers.com/13-11-02-Level10.html

__________________
Support my new movie “The Second Coming”

Oliver Klozov

Strainer look me up on ICQ we have a custom solution to this exact problem.

__________________
Babe-Bucks.com


ICQ 895-80-702
oliversgirls at gmail.com

strainer

Believe it or not I don't have ICQ. Hate the damn thing. But they are at it again, this morning, pumping millions of different passwords in from thousands of different ips, hoping for a match which will never come, because our passwords are secure.

I'd be intrested in knowing what you have but I think I am just going to write a custom solution today. I'm thinking to write a forms based logon with PHP. That would then take you to another PFP script which checks the username and password (by itself testing against a protected part of the member site).

The actual protected directory will be secret and renamed every night to something like members7287389475456727 or whatever. Unless you are already a member it will be impossible to know the protected directory.

It could still be brute force attacked, but not with standard off-the-shelf programs, and imo 99.9% of hackers are loosers way too stupid to write their own...

KRL

Another technique that works is to have a members section that sucks for the hackers to break into. Let them in and see that there is nothing great there to look at execpt a small bunch of pics. Keep your real member area isolated in another domain.

WmCgi

just use Protector-Pro

__________________
SIG TOO BIG! Maximum 120x60 button and no more than 3 text lines of DEFAULT SIZE and COLOR. Unless your sig is for a GFY top banner sponsor, then you may use a 624x80 instead of a 120x60.

Big E

As I posted in another thread, I've got an automated PHP/Mysql/ip_filter solution that's just getting a web frontend put on (stats, etc), but it's been working beautifully.

Best of all, it's automagic addition/automagic removal - the webmaster doesn't have to do any manual work (ok, I'm sooooo lazy).

Contact me: eric AT wildwebmedia.com for more info.

Probono

Because these new scripts appear to be hundreds or thousands of valid login attempts to the server it is very hard to defend. We have seen 1000+ attackers all with unique IP addresses, all hitting only a few times per ip address with a scripted list of login and passwords. The problem is not that they get passwords but that the tools used to block them eat up so many system resources that the servers become very slow at answering valid requests.

We are struggling with the problem and so far we do not see any way to stop the attacks because of their wide ip distibution.

Traditional tools such as those recommended above cannot help and more than they would help against a true DDOS attack.

As these scripts using proxies spread I suspect this problem will cripple most pay sites unless a solution can be found.

I am also open to suggestins

Dragon Curve

There is no script you can use that will defend against these attacks effectively. Grabbing the Apache module IS your best bet. It's free too.

UnseenWorld

Now if THAT's the case, there are defenses against that.

__________________
SIG TOO BIG! Maximum 120x60 button and no more than 3 text lines of DEFAULT SIZE and COLOR. Unless your sig is for a GFY top banner sponsor, then you may use a 624x80 instead of a 120x60.

Big E

Bullshit. Any 'httpd' solution does nothing to solve the REAL problem - exhausting the resources of your Apache installation. You've got to block them at the stack level.

If someone directs a 50-100-200 request per second attack at your webserver, it's going to its knees with an application level security implementation.

Dragon Curve

If you'd read a little about the Apache module you'd quite simply realise that it does merely that. The fact is, you CAN'T protect againt DoS attacks. Take the rootserver DDoS attacks that happened recently. Some of the most well secured if not the most secured servers on the internet were brought down.

The fact here is .. there is NO way to prevent attacks without downtime for your normal users. I mean, how can you differentiate a common user mistyping their username from the attackers, when the attackers are using proxied servers etc.? Simply, you can't.

Unless you're willing to totally take down your webserver when an attack starts up - you can't do this. And if you think you can, I'd sure like to hear your side of it.

No script can fix this problem, and there is nothing you can do to **SOLVE** the problem completely. But don't go paying $50 for a script that will ultimately do nothing. Grab the Apache module, use the 200 header trick to filter out stupid script kiddies and do what you can.

boldy

Not perfect, but its slows them down

http://www.gofuckyourself.com/showth...threadid=79852

__________________
MacDaddy Coder.

Sambuka

OK heres how you solve your problem, some hacker must of found your site and thought "oh cool a NEW site I haven't got 100 logins too, lets crack it."

Options :

1. made a few very easy to crack logins like :
asdf:asdf
asdfg:asdfg
1234:1234 etc etc etc

1. Let him CRACK some of these and once he has 5-10 or even 1 he might give up.

2. Log onto IRC chat and post 10 passwords to your new paysite or even 20 passwords and make sure you send them directly to all the boys running the xxxpasswords channels. They will pass them out to there (close) friends who are behind all these sort of attacks and they might give up on your site once they have a lot of passes and go onto there next target.

3. Go beg on IRC and plead for them to stop.

4. SHUTDOWN your entire site for 2-3 days and hopefully the hacker will be pissed his hacking programs are wasted on a webpage that isn't even there and he'll find another target.

5. rename your members sections so he will have to restart and readjust his password hacking program.

Just a few suggestions...

Sammy

Dragon Curve

Uhm.. right. Let's go into every XXX Password channel on IRC, give the operators access to our site, in the hopes that they will prevent some stupid 12 year old script kiddy from brute forcing the passwords? Makes sense =)

Dragon Curve

Alternatively, you could do what he suggested. Make a super easy account for cracking. Hopefully your script kiddy will test it out. Nice little PHP file grabs his IP. ping -f -s 65507 <ip>

oops =)

Big E

Originally posted by Dragon Curve
So now all of a sudden "brute force = DoS"? They CAN be the same thing but not necessarily.

You're wrong.

I'm currently blocking 1207 servers who've tried to brute force passwords. MAYBE there are some innocents in there, but they've since passed a threshold that indicates a problem and the blockage is only temporary anyway.

Just because you can't come up with the solution doesn't mean it doesn't have a solution.

There is ONE way my current scheme can be "defeated" (if you want to call it that) but it puts such a hardship on the hacker [along with requiring some modest coding skillz that most script kiddies don't possess], that it makes it unlikely, and I'm working on a solution for that as well.

People need to stop thinking in terms of a "script" to solve things. Design "systems" to solve things instead.

It's obvious you have NO concept of what I'm talking about. If the packet gets to Apache, it uses Apache's resources - whether it's in a script, or a compiled module, it's still using Apache's facility which is a limited resource. Do you even have a concept of what an OSI layer is?

Big E

The issue for us has always been: people launch a HUGE brute force attack against our servers and bring it to its knees. We wanted to try and prevent that.

The bonus is, with (A LOT!) less brute force hacking, we won't have nearly as many password cheats.

I still fail to see how your Apache solution would mitigate any Apache DoS by a large brute force attack? If you've got an Apache max of 1024 (or 1592 or 2048) servers, and someone is launching a huge attack, you're still going down.. UNLESS YOU BLOCK THEM AT THE STACK LEVEL.

Dragon Curve

Erm, yes, brute force IS DoS since we are talking about how the attack brings Apache to its knees. In this situation, yes it is.

Maybe there are some innocents in there but they've passed a threshold? Does that mean that the script kiddy must have tried to brute force the password from the same proxy more than once for this to pass the threshold? If so, that's not going to be a very effective method. Moreover, if you block out everyone who makes a failed attempt when there is an attack in progress, you are quite likely to block out innocents. Not a very decent solution.

It is quite obvious YOU have no idea of what you're talking about. The situation here is not how we block it. Yes we can prevent the packets from even getting to our service so we're not using up resources/bandwidth, but the fact is, WHICH ONES do we block? There is NO way to differentiate attackers from innocents.

And the other thing is.. we don't want to block out successful attempts, obviously. Therefore, we must at least receive the HTTP headers from the client to verify whether or not the authentication is successful. Which quite clearly means we MUST use an application-level security implementation.

Unless you intend on blocking out ALL IPs when an attack starts up? =)

Dragon Curve

I like your way of thinking.. THERE'S AN ATTACK IN PROGRESS! It's coming from constantly different IPs - so we'll block ALL IPs! AT THE STACK LEVEL!

Great one, they achieved their DoS already =)

Probono

I will add that we block at the switch level. We run a perl program that analyizes the incoming traffic and if it is a head attack or too many gets from a single ip we block the ip for a period of time.

Even that requires resources to determine who to block and when to remove the block. I have seen our membership servers running at 100% on all processors just dealing with blocking.

We are going to try a new a method out in about 10 days. If it works I will post a thread and share.

(Investment is significant)

Big E

Dragon Curve, yeah, that's it - I block ALL IPs at the stack level. Sheesh.

Why am I even arguing with you? It's obvious you have no concept of what I'm talking to you about.

You go on thinking it's reasonable to block brute force attacks with Apache modules.

Oliver Klozov

The Apache modules recommended above are for DOS (denial of service) attacks which have nothing to do with password hacking.

They will most definiatly NOT help your problem!

By reading the log file and adding IP tables creates a delayed blocking
scheme. An attack might not get caught at all if it does not fall into
the window of time that the program is reading the log file trying to
find requests. This method gets exponentially slower as the size of the
site increases. (the more hits, the more lines in the log file, the
longer it takes to parse the log file, the more lines that are missed
during parsing, and before the next parsing). Signal to noise problem,
where the amount of good traffic overwhelmes the programs ability to
recognize bad traffic.

Having the server reply with a status code of 200 in order to confuse
the program hacking does not work, because it is trivial for the person
hacking the site to compare the results of the request from a known bad
request to the current reply. Modifing the status codes breaks browser
compatability and is against the http protocol standard.

Forms based login to compare username / password data to internal
members area is slow and inefficient. It does not provide ANY
protection, but adds significant overhead (every user/pass is checked as
usual against apache, but also with php). Moving the members area
frusterates anyone who might bookmark your members area.


Our system blocks using a custom written apache module that processes before any other http processing occurs. From my benchmarks there is no negative overhead associated from blocking from apache instead of at the OS level with a packet filter such as IP filter or IP tables. This is because apache
keeps child processes waiting to accept connections, and does not spawn
any additional processes untill the queue has been used up. For people
complaining about apache being brought to its knees during an attack, it
is because they

A: are crashing beacuse of all the authentication
lookups, etc OR

B: they do not have apache setup appropriatly to handle
high volume sites.

Our system called "No Abuse" blocks bad authentication requests before
they hit mod_auth or mod_auth_mysql so no authentication lookups are
done. There is no overhead other than the 3-way TCP handshake and the
initial request. No server side processing is done by apache if "No Abuse"
recognizes an attack. "No Abuse" actually STOPS authentication on bad
passwords so all the overhead on the server is actually removed.

"No Abuse" blocks in real time. High volume sites genereate incredible amounts oflog files. Trying to detect attacks becomes extremly difficult in theseenviornments because of the overhead involved with parsing these log
files. An attacker might kick out 1000 requests in an hour, but they
would be spread out with the other 10000 requests in that hour. because
of the 'signal to noise' ratio, delayed detection methods using log
files is ineffective. It is also slow, and if run from a schedular such
as cron(8), there are windows of time where no detection takes place.

So what does all this mean?

Perl scripts and IP tables are the poormans hacking detection. You can't
catch the serious guys with these toys.

And our system kicks ass and no one has anything like it for UNIX.

Currently not for sale but if anyone is interested you can contact me via ICQ or email [email protected]

__________________
Babe-Bucks.com


ICQ 895-80-702
oliversgirls at gmail.com

PxG

use http://www.proxypass.com

Eliminates the fear of!
Brute Force Hacking Attempts
Proxy-Server Attacks
Password Sharing
Distributed Password Cracking
Significant Server Downtime

ICQ: 153529369

PxG

__________________
Kill Password Hackers Now!
Kill Hit-Botters Now!
_____________________________

PxG

Oliver Klozov,

please dont say 'nobody has it for Unix'.........that's simply not the case.
Our program is a client (apache C module)-server app. that needs apache 1.3.x.x and DSO enabled to run on Unix machines (FreeBSD, OpenBSD, Linux, HPUX, etc).....We brought these features to the board first, and our clients can attest to the quality of our product. Either way your system 'no abuse' was not first....check us out to see for yourself!



PxG!

__________________
Kill Password Hackers Now!
Kill Hit-Botters Now!
_____________________________

Backov

Yep, since we've installed proxypass, we haven't had a single login get successfully bruteforced..

We did get some added through the HUGE hole in the ccbill-local script, but I plugged that.

ProxyPass is the shit.. I don't know what all this clueless babbling above me was. Brute force proxy based attacks are easily defeated with the right tools.

Cheers,
Backov

__________________
<embed src="http://banners.spotbrokers.com/button.swf" FlashVars="clickURL=http://banners.spotbrokers.com" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="120" height="60"></embed>