BRUTE FORCE ATTACKS
SPECIAL EDITION

Joe sent in an email this week asking about Brute Force attacks. This has been a popular topic over the years. I have compiled every BRUTE FORCE story from the last 240 issues of the newsletter.

Joe writes
I've been hit by some brute force attacks to get passwords. I have password sentry which catches the multiple uses of passwords and suspends the user/pass but that doesnt stop the assholes from actually getting the passwords and posting them! I looked through past trix issues for help but nobody seems to have posted an actual "fix". Do you know if there is such a thing?

|||||||||||||||||||||||||||||||||||||||||||||||

BRUTE FORCE HACKERS AND HOW TO STOP THEM by Craig
Anyone who runs their own server and pay site(s) all has had dealings with brute force hackers...these are usually the punks that download a program that does nothing but try different username/password combinations in the hopes of finding a valid one to your site. Normally the ones that use small throughput modems such as 33.6 or 56k are not a threat...although they still are a security risk they're not as much of a concern as the people with Cable modems or faster connections. Why? Because to increase "efficiency" of these programs they allow multiple connections..and that number is totally dependant on what the hacker himself wants to use...so a person on a cable modem could effectively attempt 100 or so combinations per second or even higher depending on their OS and its socket capabilities. Here's where the problems come into play:

1) Apache only allows a maximum number of connections at any time...by default it's 150, and without some minor modifications the maximum limit is 256. This means if you have a default apache installation 75% of your connections are being used by this brute force hacker forcing all legit traffic to only use the 50 connections, meaning people getting locked out (server not responding errors)

2) The server load skyrockets...an easy way to know if someone is potentially hacking your system is to check the server load...for example:

bash-> w
11:34am up 19:46, 4 users, load average: 0.10, 0.23, 0.47

The load average is what you should check...this is the average rate on one of my servers...almost always below 1...if that number suddenly becomes 4 or higher I immediately go to check for a hacker.

How to check for a brute force hacker:

If you have all your access & error logs in one directory (which I recommend you do) it's really simple. All my logs are named as follows...

sitename_access.log -> for connections to site
sitename_error.log -> for error messages from site

Failed access attempts are located in the error log. So go into the directory where these logs are located and type the following command

tail -f *error* | grep "user"

Note: The | is called a pipe, and normally located above the forward slash on your keyboard...it is NOT an L or an uppercase i (I).

IMMEDIATELY you'll know if you're being brutally hacked...you'll see unauthorized messages flying across the screen...here's an example direct from my logs

[Mon Feb 28 16:23:44 2000] [error] [client 111.222.333.444] user jonathan not found: /members2/login.html
[Mon Feb 28 16:23:45 2000] [error] [client 111.222.333.444] user justin not found: /members2/login.html
[Mon Feb 28 16:23:46 2000] [error] [client 111.222.333.444] user william not found: /members2/login.html
[Mon Feb 28 16:23:46 2000] [error] [client 111.222.333.444] user robert not found: /members2/login.html
[Mon Feb 28 16:23:47 2000] [error] [client 111.222.333.444] user alexander not found: /members2/login.html
[Mon Feb 28 16:23:47 2000] [error] [client 111.222.333.444] user bigesu not found: /members2/login.html
[Mon Feb 28 16:23:47 2000] [error] [client 111.222.333.444] user jordan not found: /members2/login.html
[Mon Feb 28 16:23:48 2000] [error] [client 111.222.333.444] user kevin not found: /members2/login.html
[Mon Feb 28 16:23:49 2000] [error] [client 111.222.333.444] user samuel not found: /members2/login.html
[Mon Feb 28 16:23:49 2000] [error] [client 111.222.333.444] user christian not found: /members2/login.html
[Mon Feb 28 16:23:50 2000] [error] [client 111.222.333.444] user benjamin not found: /members2/login.html
[Mon Feb 28 16:23:50 2000] [error] [client 111.222.333.444] user nathan not found: /members2/login.html

Note: I've changed the IP to prevent any possible legal implications :) But sure enough this guy was definately trying to bruteforce his way in. It's the same IP being declined OVER AND OVER...

4) How to release your wrath on the hacker

It's very simple actually. Using a simple command you can reconfigure the network card itself to no longer process incoming requests from an IP...there's a couple of issues with doing this but it is 99% effective. Here are the commands for different unix based systems

Generic (should work on any unix OS)
/sbin/route add $TARGET$ 333.444.555.666

Generic Linux
/sbin/route add -host $TARGET$ gw 333.444.555.666

Newer versions of Linux support the reject flag now. (I believe kernel 2.2+)
For linux users, try this one first...if it tells you reject is not a valid flag, use the generic one.
/sbin/route add -host $TARGET$ reject

Generic BSD (BSDI, OpenBSD, NetBSD, FreeBSD)
/sbin/route add $TARGET$ 333.444.555.666

Generic Sun
/usr/sbin/route add $TARGET$ 333.444.555.666 1

NEXTSTEP
/usr/etc/route add $TARGET$ 127.0.0.1 1

FreeBSD
route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole

Digital UNIX 4.0D (OSF/1 / Compaq Tru64 UNIX)
/sbin/route add -host -blackhole $TARGET$ 127.0.0.1

Replace $TARGET$ with the IP of the individual you wish to block. You MUST have superuser access at the time for this command to work.

Issues:

1) This may not be 100% effective against proxy users (although most brute force hacking programs don't support proxies...I've used the above system for a few months now and have never had a problem)

2) If you block a proxy based IP such as an AOL proxy (usually starts with 152) you can hinder other AOL traffic from reaching you for the length the IP is blocked. So you might be wise to do a traceroute on the IP first...if it is AOL based, contact AOL and complain and ban the IP maybe only for a few minutes.

3) The blocking is effective until either you release the block (use the same command only replace add with del) or reboot the system

It also should be mentioned this doesn't prevent the user from actually sending a request to your machine...it just means the the request is immediately disposed of when received...it's not really important to care about this fact...but it should be mentioned nonetheless :) If ever you catch a bruteforce hacker it's always wise to check to see if they got access to any usernames (yes, it can be checked :D). It is also recommended to periodically do a test brute force on your own server to look for easy username/password combinations which should be changed. I will provide examples of how to do this next week.

||||||||||||||||||||||||||||||||||||||||||||||||

MORE ON BRUTE ATTACKS AND SERVER SET UP by Stel
Stel wanted to add to the ongoing brute force trix we have seen in the last few weeks and he writes:
If you're going to set up your box properly you need to:
1)Recompile/install the primary Kernel to "maxusers512"
and using Apache 1.3.11 as an example
2)Inside of the /usr/ports/www/apache_1.3.11/src/includes
directory edit the file called httpd.h change the entry
for "#define HARD_SERVER_LIMIT 256" from 256 to 512.
3)Re-make the apache port.
4)Re-install apache which will preserve your existing httpd.conf
file
5)Edit you httpd.conf file and change the the entries to
the kind of numbers I find useful below. Assuming you
have at least 256 megs of RAM installed on the Server.
MinSpareServers 192
MaxSpareServers 288
StartServers 192
MaxClients 511

The above changes would prevent ANY server lockout from occurring. Running
an adult webserver with lower numbers simply does you major damage! When
as password gets broken AND a brute force password thrower is at play you
need the ability to go up to 450+ sessions. Unfortunately the ONLY way to
exceed the 512 user limit is to go to a pay for play UNIX O/S such as BSDI,
Solaris, etc. FreeBSD, NETBSD, OpenBSD, Liunx, etc all have a 512 maxuser
limit hard coded. Use something like "top" which will show you total PIDS
running. Simply do a "top" at after boot time is over to get an idea of
what the average load is for the machine. If its 120 processes and you
look one time and its suddendly 200+ you know either 1) a password hurler
is going at it or 2) a password breach as occurred.

Since AOL Servers use a round robin Class C Proxy for any SINGLE user they
can use a password hurler through the proxy. I've see it done. I've had to
write special defense code to allow through ordinary AOLers because most
defense routines detect the constanting changing IP Address of an AOL as a
breech.

||||||||||||||||||||||||||||||||||||||||||||||||

PENNYWISE 2.0 - PRO LEVEL CROOK CATCHING
I just got an email from Steve at PennyWise and I wanted to pass along what their new features offer. PennyWise is used by hundreds of porn sites to STOP PASSWORD THIEVES. The new features include the ability to completely block brute force attacks as well as blocking password traders. No other script or solution offers this so seemlessly. Normally you have to add IP addresses to your .htaccess file and then manually remove them and such - Pennywize does everything automatically.
www.pennywize.com

||||||||||||||||||||||||||||||||||||||||||||||||

BRUTE FORCE PASSWORD HACK BLOCKER by Antone
Antone writes:
Thought I might contribute to the trix a bit, after trying to find a solution for stopping brute force password crackers I decided to do my own - all current solutions to protect the members area of a paysite are too expensive IMHO, why pay $50/month for such a simpl thing???

Now, first of all let me say this:
This is not a newbie script, it's for paysite owners. It also requires that
the following is installed:
-PHP4
-apaches rewrite module
-MySQL (and you have to know how to create a database in it!)
-crontab.
-telnet.
-cgi...of course!

I have used PHP/MySQL to insure that the script can take a high load.

Basically what it does is this:
1. Sets a php file as the error 401 handler (failed password login error) in
the member sections .htaccess
2. The php file logs failed accesses to MySQL.
3. If the php file notices that the same IP has failed more than 20 logins
it outputs a new root .htaccess file containing all the "bad" IP addresses,
redirecting access attempts to fbi.gov (lol!)
4. Crontab entrys clear the IP log once daily, as well as outputting a
template .htaccess file=restoring access.

The script can be downloaded from:
offshoreclicks.com/nocracker.zip

update:
Hi, fixed the problem, the script should be 100% kickass now! (although it's
only tested on my server redhat6.1/apache1.3.12/mysql latest
beta/php4.03pl1)
Since apache "spools" the 401 error page I made the php script only log the
access as suspect if the request contained a username, which it doesn't do
at the time apache spools - only when someone entered a "false" user/pass
combo.

update #2
I did a test run with a passwod hurler: Always expecting the
worst, I set up a hurler to hide by cycling through multiple proxys (i.e.
multiple IPs...) and hurl away.
Result: 100% - i.e the offending proxys (used 20) where blocked after 20*20
attempts=400, server load was totally negligable, never even saw that
php/mysql was working in the "top" command. I'm sure there are even better
solutions, but most want obscene amounts of cash!

Cheers,
Antone
offshoreclicks.com
Webmasters get paid 3 cents/raw, 0.3 cents/impression - no conversions!

|||||||||||||||||||||||||||||||||||||||||||||||

PRO-LEVEL BRUTE FORCE PROTECTION from Darren
Darren writes
Hi Andy, I noticed D.Trees write about brute force
attacks on her members area. We have been hosting
adult sites for years, and have been watching this
type of activity since day one. We have tried
everything from the cheap .cgi programs, a well known
remotely hosted one, and an Apache module that costs a
few thousand dollars, but is the best by far. They can
ALL be beat due to the fact there are 1000's of open
proxy servers publicly available, and brute force
software that allows you to go through a list of them.

Here is how our software works. We have the absolute
best software written to stop this type of activity,
and yes, as I said it can be beat.

What happens is someone loads a list of proxies. Then
they rotate through the proxy list using a different
IP for each hack attempt. Our software logs this, and
if one IP (for example) tries 10 login attempts and
fails it gets blocked. Of course if someone has 1000
proxy IP's they will get 10 000 attempts to break in
before our software blocks their entire list.

Here is the downer to this. When someone tries to
login with a false username/password they get an
Apache 401 error, meaning Authentication required.
Now, after one IP gets (for example) 10 of these
errors, it gets blocked by our software. Now, they are
getting a 403 apache error message meaning Access
forbidden. So basically our software is saying " You
tried to log in 10 times from the same IP, none of
them were right, you are blocked from our server now"

What sucks is most of the brute force member area
hacking software written will continue to hack the
members area even though the ip is blocked. This is
where we find the problems...the IP is blocked but the
software continues to run generating 403 errors
instead of 401's. Of course there is less overhead on
the server with a 403 error, but it does create large
log files.

We have had .cgi scripts written that hide the members
area URL to avoid brute force programs being run, but
then some of them will brute force a .cgi script
trying to log in which really fux things up as we all
know how much overhead perl uses. :))

As a webhost, I don't consider this a DOS attack. Even
with several 100 login attempts a minute, our servers
do not slow down. It is annoying to watch in real
time, though, especially when their IP is blocked and
the software they use still hurls away.

The best way to handle them? Get a webhost with
industrial strength software to stop this type of
attack. Don't use crappy perl scripts, or remote
member area protection companies. There is no
substitute for a well written Apache Module written in
C++! :) Ours uses no overhead on our server...at all!
We could have several 100 people attacking a site, and
not even notice it at all. Of course, they are not
getting in, just getting 403 error messages.

The only other way I can think is having a login
script written in perl or php that a brute force
program will not run against. This hides your members
area, and script kiddies are lazy and will move on to
the next site if they can't figure out how to brute
force yours easily.

If you have any questions, e-mail me back. If anyone
is having problems and needs a good host, tell him to
write me. We do have real e-mail and domains, I just
like to be discreet.

Regards,
Darren
darren_bsd@yahoo.com

|||||||||||||||||||||||||||||||||||||||||||||||

PRO-LEVEL BRUTE FORCE PROTECTION from Interstel
Interstel writes
Its not really a denial of service attack since those are designed to take
you off the air. These are designed to breach a password. The only method
that works is an interactive Firewall system that can be supplied by an
Apache mod that continuously checks for multiple failed 401's from the same
IP in a short span of time. And the firewalling should be a dump to dev
null not a denial. That way you lock their machines up trying to access a
black hole.

Its a fairly complex solution. Depending on how its implemented it can be
processor intensive and usually works best if you have an independent
firewall box routing all traffic anyway although individual Firewalling
running on the box itself is workable too.

We charge several thousand dollars for the solution. Its one of our best money makers.

Interstel
interstel@tampabayadult.net

|||||||||||||||||||||||||||||||||||||||||||||||

PRO-LEVEL BRUTE FORCE PROTECTION from Rebel Hawk
Rebel Hawk writes
In reply of DOS/brute force attacks i've been fighting them for a long
time and developed an script run by cron each minute, which checks the
log file for attacks and smoke out the offending IP (by blocking it at
router level) for 15 minutes, then release it.

The main thing here is to slow down the DOS enough to neutralize its
clogging effect, the script is not designed to completely stop the
password discovering, although it will do in the 98% of the times, but
eventually they will figure out some keys, so to be completely shielded
you must use a separate routine to block the compromised U/P for
sometime to avoid the bandwidth theft.

I've found out that they use public proxies, so you can't ban the IP
forever, or you risk loosing many customers, as those IPs are proxies
and used by *Many* people, the best way after much experimenting is to
ban the IP for 15 minutes and the release it again, that will prevent
the attacker to find out any passes, also, the down curve is arithmetic,
this is, as more IPs you block, you increase the number of tries for
each IP, making it easy for you to smoke the other IPs out.

Also it is needed that your host checks out for spoofed IPs, otherwise
the script will do nothing but block innocent IPs

I've been having this attacks since months ago, sometimes the assholes
tries 1 U/P per IP making it very, very difficult to smoke them out, but
with this script i can catch them in about 10 mins.

I can't disclose the code here for security reasons, but explaining the
inner workings will help you deal with this assholes

Another idea will be to collect enough IPs from the attacks and as soon
as an attack is detected, block them all for some mins, that will
completely frustrate the assholes, but that should need a large
'frequent delinquent' IP database, i actually have such data, and i plan
to build such database in the near future, even i've though that i could
share that database with other webmasters so we can build some sort of
black list. I don't know, i'm open to ideas, you can drop me a line to
Peter AKA Rebel Hawk
service@scylla.charybdis.net

|||||||||||||||||||||||||||||||||||||||||||||||

|||||||||||||||||||||||||||||||||||||||||||||||

HELP! BRUTE FORCE PASSWORD OR DOS ATTACK ADVICE NEEDED from D. Trees
D. writes
I've been seeing a lot of what I term DoS-style attacks. I wonder 1) am I
using the right terminology; 2) are other Web folks seeing the same rise
in attacks; 3) is there a protection against it?

Here's what's happening. An attack is coordinated among 100-500 IP
addresses, with each address having a portion of brute force user/pass
file. These hundred or so IPs begin pounding on the members directory,
each with a different user/pass combination. For example:
199.73.33.11 - - [05/Dec/2001:17:35:31 -0500] "HEAD /members/
HTTP/1.0" 403 0
pandora.adam.es - - [05/Dec/2001:17:35:31 -0500] "HEAD /members/
HTTP/1.0" 403 0
193.120.133.81 - - [05/Dec/2001:17:35:32 -0500] "HEAD /members/
HTTP/1.0" 403 0
ntmail.tsi.com.mx - - [05/Dec/2001:17:35:34 -0500] "HEAD /members/
HTTP/1.0" 403 0

These adresses (as well as 1000+ more) are getting 403s instead of 401s
because I added them to my .htaccess file. That way they don't even get to
attempt to use the user/pass combination in the hack attempt.

But that's only four of 200 who were attacking today. I added all of the
IPs to my .htaccess (check your error-log for the IP as opposed to the
domain name), but that's time-consuming. There's got to be a better way.

But, each address only tries out maybe 10 user/pass combinations. If 100
IPs each have 10 user/pass combinations to try, that's 1000 attempts. If
it's 500, it's 5000.

So why do I call it a Dos (Denial of Service) style of attack? Just
imaging 500 servers/PCs pounding on your members directory with a
user/pass list. Even if you add them to the .htaccess, they're still
sending a request. Advise, or other instances?

Guru-O-Gif writes:
if anyone can better explain these attacks or what best way to handle them, please email me for next weeks letter andy@lips.com
thanks!

|||||||||||||||||||||||||||||||||||||||||||||||

COMPLETEWEB.NET REPSONDS TO D. TREES from Gary
Gary writes
Yes, we see that all the time. People trying 1000's of passwords on a site will
do the head requests, because they don't return as much info, just if it was successful
or not. The reason coming from so many IP addresses, is they are using proxy servers,
so you can't track down their original location to block. There are thousands of these
proxy servers, and almost impossible to deny them all. They can send 10-20 requests
through each, x 50-100 servers, and they will all do their requests, which can load
the server down trying to auth them. Almost impossible to stop.
We do have software added into our apache to slow them down, and deny them eventually.
If we get more than 5 wrong userid:password tries from an ip address in so many seconds,
that IP is denied for a predetermined time (usually a few hours). That will stop it from
hurting it too bad, and also stops them from getting any passwords, unless they are
really determined, and just keep trying for weeks. But they usually give up and will
go on to an easier site.
www.completeweb.net

|||||||||||||||||||||||||||||||||||||||||||||||

IPROTECT FOR PASSWORD HACKS from Guru-O-Gif
Many ISPs use an apache module iProtect to help deal with these style of attacks
www.digital-concepts.net/cgi-iprotect.html

|||||||||||||||||||||||||||||||||||||||||||||||

MORE BRUTE FORCE IDEAS from Rebel Hawk
Rebel Hawk
In spite of the brute force attacks i can tell you: I DID IT!, I FINALLY DEFEATED THEM, how?, easy: lowered my IP/tries limit to 2 and raised my IP hold time to 60 mins and they are gone for ever. spread the word out, if your members are interested i can write an alogritmic scheme of the code, so anyone can write it in perl, php, sh or whatever, mine is in sh. Also, i'm still working on the 'frequent delinquent' IP database, some sort of RBL for the IPs, i would like to offer it for free to all the adult community.
service@comnet.com.ec

UPDATE -this just in from Rebel Hawk
Rebel Hawk writes
Andy i've tested the FDIP database setting up a shield and it works like
heaven!, the attacks stopped immediately!, now i have the assholes rigth
from the balls! Spread the word, let's kill those bastards now!
service@comnet.com.ec

|||||||||||||||||||||||||||||||||||||||||||||||

BRUTE FORCE AND DRAWBACK OF ERROR 403 from Interstel
Interstel writes
We stopped using this method awhile back because the
reply packets eat up more bandwidth than the hack attempts do! Unless you
dump the hackers into oblivion without reply to their packets after the 5
failure in 2 minute window you're wasting bandwidth. And the amount of
bandwidth even a 403 generates is about 5-10 times what the request header
alone sucked up.

Course, <grin> I can convince all my hosted customers to buy this kind of
protections which is why lots of them have high bandwidth bills. They just
never get the point.

By the way. We do forcibly redirect those first attempt our of 5 into a
theftjoin page. I figure once in a great while you'll actually sell them
something.

|||||||||||||||||||||||||||||||||||||||||||||||

ALTERNATIVE SOLUTION TO BRUTE FORCE ATTACK from Stephen
Stephen writes:
In all of the brute force protection methods I have read none seem to really
address the problem the right way.
What does the person trying to crack an account want? He wants a valid
password. Blocking the crackers isn't giving them what they want.
So instead of trying to block the cracker, let them in, or make them think
they got in.

If the cracker is trying to crack a username that is not valid on your
server you can just make that account valid but instead of pointing it to
your real members area you point it to a "fake" area, maybe with a bunch of
pop-ups. Not only does this stop the cracker, because for all his program
knows he has a valid login, but also the login might get posted to a
password trading website where you could make a few extra $.
Now the problem with the above is that if the cracker is trying to crack a
valid account on your server you couldn't turn it into a "fake" area login.
But you could, after detecting the cracker, just send them to your "fake"
area. This would make the cracker think he got a valid password but really
its not.

(I don't know if the above idea would help a really large website or if I
even know what I'm talking about. But I have seen variations of the idea
done and working. So its worth a shot.)

Guru-Of-Gif writes:
I like Stephen's idea...can any of you programmers out there tell us if this would work in real life and why or why not? Here is another approach with that idea...why not seed your customer login database with 1000 easy names and passwords. Then, the script will get a hit almost instantly. This might also catch a lot of simple hackers and send them to cash pages etc rather than true pages. I guess the question is "when the brute force machine gets a HIT and matches, does it shut off, or does it only shutoff when the hacker tells it to"? please email me your comments on these ideas andy@lips.com

Here is one more thought...can a method be created where the login page is constanly moving...maybe using php. Therefore surfers don't see it moving...they just get to it...but the script can never find it since it is not in the same place twice? Or it is on the same html page, but how it talks to the DB is altered once a second or something and this makes it impossible for the brute force to use? Is this theory possible? Or would the scipt still cause grief by pounding away?

UPDATE - PASSWORD SEEDING + IPROTECT
I was just on the horn shooting the shit with the Baron-Of-Bandwidth and he told me two things related to BRUTE FORCE
1. PASSWORD SEEDING
he said "sorry dude, we have been doing this for over two years now" ...hee hee haa. So yes, password seeding as I theorized above does seem to be a very good idea. Dayne says they use common stuff like admin, root, bob, tom and maybe the same word for password or a blank password and then hand that off to a error 403 and the scripts turn off once they get in generally.
2. iPROTECT
the baron says iProtect still works very well for certain password hacks. He did say that over the years they have loosened the minimum tries up do to proxies. He says they might go up to 20 or even 30 for some AOL proxies.
www.digital-concepts.net/cgi-iprotect.html

|||||||||||||||||||||||||||||||||||||||||||||||

BRUTE FORCE ATTACKS IDEAS AND THOUGHTS from Darren
Darren writes:
this Brute forcing topic is interesting! :)
Brute forcing has been going on for several years
now...why so long for webmasters to pick up on the
fact people are constantly trying to break into their
site?

Stephan's idea of submitting to password sites is a
good one. I don't doubt there are people making money
out there doing it. But they are not gonna tell you
how they are doing it. :)) But we have directed tons
of password traffic to front pages, signup pages etc.
on amateur sites that were doing 1:200 conversions,
and password traffic converts SHIT! People looking for
free passwords are not going to pay for it!

As for having a hidden area so it cannot be brute
forced, we have used perl scripts to hide our members
areas and it works pretty good. Until the perl script
gets attacked, then you see 50.00 + server loads. It
is nasty. I have not seen a solution to this, although
I am sure php would be better then perl. We just leave
our members areas URL public, let the crackers go at
it. They will learn what a 403 error is sooner or
later.

As for brute force programs shutting off, some will
keep going after a valid login, some will stop. It
depends how you configure them, or if they were coded
with an option to stop or keep going. Most password
'crackers' (script kiddies) will keep the program
running. If you can catch a crack in progress and all
of the sudden it stops on the username 'alice' then
you know that they found a valid login and the program
stopped. But, like I said, most crackers will let it
run on so you can't tell.

Iprotect kicks ass, and there is not one program out
there that can touch it. It is compiled into Apache
and uses little to no overhead. It is well worth the
money, you can earn it back if you are clever.
Unfortunately your host has to install it. It costs a
lot. And a lot of hosting companies will not use it as
they make a ton off of overages. If anyone is hosted
by a company that does not use this software, let me
know and I will set you up with us!
(darren_bsd@yahoo.com) A lot of big adult hosting
companies are not using this software (on purpose) and
it is a total disservice to their customers. We know
of a biggie that used it at one time and stopped using
it. Gee, wonder why? ;)

As for seeding passwords, read above, password traffic
is SHIT. But it can easily be done with iProt. Like
your guy said, they have been doing it for years now.
So have a lot of people. :)) But, believe it or not,
password sites have databases of rogue domains and
ip's that submit fake sites, or redirect traffic. I
have seen them, they are quite large. ha ha

I think if you did redirect the traffic intelligently
you could make money from it. I rank the traffic as
crappier the TGP traffic, though so you would have to
get a lot to profit from it. But, there are ways...you
just have to think outside the box. :) Traffic is
traffic...some just sucks worse then others. If you
can sell ice to Eskimos, you can convert password
traffic.

||||||||||||||||||||||||||||||||||||||||||||||||

PRO-LEVEL BRUTE FORCE PREVENTION from Kaz
Kaz writes
http://www.paysitepowertools.com/os-memlogin.html
Anyway you could add the link to Memlogin to your bruteforcer edition. We feel this is the end-all-be-all way to stop bruteforcers. Theres really no way to get around it if you implement it right.. no way short of faking the referring url anyway.

|||||||||||||||||||||||||||||||||||||||||||||||

WHAT HAPPENS TO APACHE DURING A BRUTE FORCE ATTACK from Craig
Craig the Programmer wrrites:
In response to this suggestion. I can't vouch for whether or not it is a
good money making idea....might be decent for making a few extra coins by
using popups for exit console programs....but personally I could see very
little profit coming out of the work in setting a cash in page up. If
someone has gone to the trouble to find a password site, they will more than
likely pass you by when they realize it's a fake. Might come in handy
though if instead of a payment page to instead use it as a way of fueling
traffic for a tgp....actually put some content on the hacked page and treat
that page like you normally would if it was a TGP...might be a potential way
of filtering horrible traffic for just awful traffic =)

However the biggest problem with the hacked passwords isn't the
bandwidth....it's the demand on the server. By default an apache server is
limited to 150 simultaneous connections. Without needing to make a source
adjustment and rebuilding the software you can increase this limit to 256 (I
think 1024 on Windows machines). The problem is that most brute force
programs use multiple connections sometimes to the extreme. Say the person
doing the hacking is doing 100 simultaneous attempts. Assuming there have
been no configuration changes from the default we have a number of problems

(Remember this is using default configs)

Apache only ever has 5 processes listening for activity to start. So now we
have the 100 connection attempts being logged
5 processes are now running, 95 are backed up
When maxed out apache starts increasing reserve processes (up to that 150
limit), starting at 1 and doubling in number each second....so when there's
a backlog the first second only 1 processes is added, then 2, then 4, etc up
to 32 processes per second

Getting back to the connections

95 connections are pending
6 connections, 94 pending
8 connections, 92 pending
12 connections, 88 pending
20 connections, 80 pending
36 connections, 64 pending
58 connections, 32 pending
90 connections, 0 pending

so now just to handle those initial 100 connections it takes about 8 seconds
(pending on if your server can keep up with the increases swiftly
enough)....Sounds easy enough...8 seconds isn't all that much. But it does
then create a backlog with other requests such as other people trying to
connect to the site....they need to wait at minimum those 8 seconds before
the page even starts getting downloaded.

Now the painful news.

1 -
The first major downfall....Keepalives ....an excellent configuration to use
to help conserve processing power and memory usage but is devastating when
getting hacked...keepalives basically reserve that process to the IP
currently connected to it for X amount of time...usually 15 seconds.

So now even if the hacker stops after those 100 attempts, no one can use the
100 processes now idle for 15 seconds...so new connections need to be
created for all new requests.

2 -
You would initially think...well 100 used connections isn't all that
bad...if I set the server to 256 that still allows another 156 people to
connect to the server...right?
Dead wrong. The reason for that is most browsers do simultaneous
downloadings....they download they HTML plus have separate connections to
download each image to be displayed in that HTML at the same time to help
decrease the delay on displaying the page...I'm not sure what the limit is
but I have seen Netscape 4.X browsers downloading as many as 25 items
simultaneously. Here's a simple way to see for yourself on a windows based
machine.

Reboot your system, open up an msdos prompt (start menu -> run -> command)
type: netstat -A
This will list all your current network connections, there will be a few
already in the list used for keeping the network usable on your system so
just ignore those.

now open up your browser and go to a website....a good example is
www.cnn.com as they display several graphics on their HTML pages
after the page is loaded go back to the msdos prompt
type: netstat -A

you will now see a considerable number of open connections...each of those
represent a connection that was made to cnn.com's webserver. Keep this in
mind as you read below.

Let's say very conservatively each HTML page has the user's browser create
only 5 connections...one for the HTML and a few graphical images...however
anything with thumbnail tables or even poorman sitemaps (having a jumble of
images meshed together to form one complete image instead of just that
singular image) can increase that number

Okay so 5 connections per user - 156/5 = 31 users with one free process
So now you're down to 31 people who can access the site simultaneously.
Then you have the keep alive issue again. If 5 users load one page each,
then 25 connections are tied up for 15 seconds (after the downloading is
complete). So if you have a large number of unique individuals you can run
out of connections very quickly. And that's just HTML pages....large
downloads (ex. movie clips) or slow connection users can tie the connections
up for a lot longer. This means now that the 100 connections consumed by
the hacker are wreaking havoc on your paying subscribers (or those going
through your free areas as potential customers) even if you're blocking
those connections either via 403s, redirects, etc.

And then what happens if you have multiple brute force programs on you?
Kiss your server connectivity goodbye to anyone legitimately trying to
connect to your website(s).

Then there is the suggestion about the sales pages, or pages to trick the
hackers into thinking they got access to the members area. If ever you
check out any of the password sites online you'll see a LOT of pay sites
actually use this trick...usually in cahoots with the administrator of that
password site. The pay sites will offer phony username/passwords, the
administrator then posts it on the password site pretending like it's a
legitimate hack (my oxymoron for the day) and then gets a kickback on any
signups. Personally I don't know if such a method works however it has been
around for years and it's possible it's been bled dry.

However if you do want to try that be sure you can take on the extra
traffic....I remember helping a company set up a few of these trick pages
and they had about 200,000 page hits within a few days. I don't know if
they got any sales or were able to put that traffic to any use however the
servers took a beating....they stayed online due to the preperatory measures
that were taken (btw if anyone is attempting to try this I strongly urge
them to use a BSD os as it is much more efficient on handling pure web
traffic than any other unix based os I have worked with). I think even with
a conservative page consiting of about 60k worth of HTML and graphics they
forked out about 12 GBits of data just on the crap traffic.

I'm not saying something like this is unprofitable....I honestly don't
know...but you need to be prepared for the additional strain on your
server(s) and I strongly discourage anyone who shares a server with others
to try this.

If anyone is seeking any further advice on the subject or require assistance
in developing something like this, they can contact me at
2bunnyhop@rogers.com

|||||||||||||||||||||||||||||||||||||||||||||||