Tar pitting automated attacks

Mike Hauber m.hauber at mchsi.com
Wed Sep 8 09:34:59 PDT 2004


On Wednesday 08 September 2004 10:54 am, Mike Galvez 
proclaimed:
> On Wed, Sep 08, 2004 at 01:19:15AM -0700, Ted Mittelstaedt 
wrote:
> > > -----Original Message-----
> > > From: owner-freebsd-questions at freebsd.org
> > > [mailto:owner-freebsd-questions at freebsd.org]On Behalf
> > > Of Mike Galvez Sent: Tuesday, September 07, 2004 6:42
> > > AM
> > > To: freebsd-questions at freebsd.org
> > > Subject: Tar pitting automated attacks
> > >
> > >
> > > Is there a method to make this more expensive to the
> > > attacker, such as tar-pitting?
> >
> > No.  These days attackers use distributed networks of
> > cracked PCs to launch attacks.  The vast bulk of these
> > attacks is automated. The cracker merely feeds in a job
> > and pushes it to his network to work away at.  Most of
> > the time the cracker spends is in adding new machines
> > that have vulnerabilities into his distributed network
> > of cracked PCs
> >
> > If you successfully erect a network block, the
> > cracker's software will just go to the next IP in the
> > sequence to attack.  Your actually doing more damage to
> > the cracker's distributed network by your SSH server
> > patiently saying no, no, no, no, no, no, etc. for 20-50
> > thousand times, because that ties the cracked PC up for
> > a lot longer just working away at your system.
>
> This is why I was curious about tar-pitting. The attacker
> is banging away at common user accounts every 3 to 5
> seconds sometimes more than a thousand times. A tar pit
> or something like it could slow the attack to maybe four
> attempts in an hour as opposed to a thousand.
>
> I am still looking for my passive-aggressive solution.
>
>   I presume of course that you aren't using guessible
>
> > passwords and you have everything patched to current
> > levels.
> >
> > if you want to do damage to the attacker, you need to
> > make a good effort at reporting the source IP numbers
> > to the netblock managers the IP is part of.  Granted,
> > 3/4 of the time the netblock managers won't do anything
> > about it.
>
> Reporting these to ISPs is like shouting at the ocean.
> They are most likely overwhelmed, indifferent or both.
>
>   But whenever they do, it usually
>
> > takes that cracked PC out of the distributed network. 
> > That is what costs the cracker because then the cracker
> > has to expend work replacing it with another cracked
> > PC.
> >
> > But, it is a lot like trying to pick up spilled
> > spaghetti with tweezers. There's so many cracked PC's
> > out there that as soon as you get one taken down,
> > there's plenty more where that came from.
> >
> > Now, if you REALLY want to damage the attacker, you
> > throw the works at the IP numbers that are scanning
> > you, and find the back door that the cracker is using
> > on those hosts, then go in and hard-code the homepage
> > on their web broswer to something like
> > http://www.fuckyou.com, making sure to use one of those
> > cracker programs that makes it impossible for them to
> > change it back.  That is usually sufficient to get the
> > owner of the cracked PC off their lazy ass to get their
> > machine cleaned up.
> >
> > Ted
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-quest
> >ions To unsubscribe, send any mail to
> > "freebsd-questions-unsubscribe at freebsd.org"

I realize this is probably a dumb question (I quietly drop 
everything incoming unless it's keep-state, and I only 
allow ssh internally)...

If you're needing to ssh to your machine from a limited 
range of IPs, then why not tell your PF to drop incoming 
unless it's within that range?  I know it puts a limit on 
your options for connecting, but on the other hand it also 
makes an attack not worth the time and resources.  (That is 
is the way I'm understanding it, but I'm still learning)

On the other hand.  I would imagine that it wouldn't be too 
difficult to write some code that would detect repeated, 
failed attempts and then quietly drop incoming for a 
predetermined amount of time (could be reset by dialing in, 
too).  I wouldn't have a clue as to how to do it, but it 
_seems_ logical.  :)
 
Just curious,

Mike


More information about the freebsd-questions mailing list