OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Automatic Retaliation contra DoS
From: Michael H. Warfield (mhwWITTSEND.COM)
Date: Wed May 17 2000 - 21:05:41 CDT

On Wed, May 17, 2000 at 08:52:13PM -0000, Weston Pawlowski wrote:
> Automatic retaliation is usually a bit dangerous, but it can
> still be a good thing, you just have to be careful...

        No... It can not be a good thing because you can not be
careful enough not to have it turned against you.

> It can be used as a DoS against you... Let's say that you
> have portsentry setup to detect stealth TCP and UDP
> scans/floods, and it filters out all packets from the
> "attacker" via ipchains. Well, guess what... Someone could
> just type something like "nmap -sS -S 64.28.67.48 -e eth0
> yourserver.net" and cause portsentry to think "64.28.67.48"
> (slashdot.org) is scanning you, so it'll filter it out, and
> now you can't read slashdot.org until you remove the entry
> in ipchains! It's incredibly easy to spoof an IP on a SYN
> scan, so don't retailiate when you detect one.

        How about this... How about if I set up a web page with
lots of pretty girls with no clothes on and lots of hidden image src
URL's that poke at your retaliating box. Make it look like a full
fledged, fully connected, port scan or maybe an intrusion attempt
(go for some trojan ports). Then I add some really enticing meta-tags
and leave a link around that the search engines are sure to hit.
Then just wait for the chumps to come hit it. You take them out
in wind-rows and their admins want to know why you are commiting a
federal crime by executing attacks against their systems. Want that
legal liability? Want to explain that to your lawyers?

> So, you should only retaliate when you are pretty sure that
> the IP is real (ie a full connection). I have my server
> setup to only notify me of stealth mode scans (such as a SYN
> scan), and I have simple little programs, which I call port
> mines, listening on various unusual port numbers for full
> connections. When a connection is made to one of my port
> mines, it notifies me and filters out the attacker via
> ipchains. My setup will retaliate against non-stealth port
> scans (used by most script kiddies and Windows users), and
> notify me about anything else.

        If I know what your IP address is, you could be in a lot of
trouble...

        SecureITeam posted a message on their web site that I had
written about this on the Abacus mailing list. You can find it here.

http://www.securiteam.com/securitynews/The_risks_of_counter-attack_tactics.html

        To summarize, even to do queries back to the "probing" system
is likely to bring you unwanted attention and likely to be used
against you. You've really got nothing to gain and you are risking
an awful lot (especially in terms of legal liability if this thing
backfires on you - and it will).

> Completely filtering a suspected attacker out might be a bit
> harsh for a more public server, so I'd aggree that lowering
> the priority would be a great alternative. Does anyone know
> how feasible and how effective that would be?

> As long as we're on the subject, does anyone know why
> someone might want to poke at UDP ports 22 and 5632. I was
> just notified by portsentry that someone's messing with
> those ports, again. I saw exactly the same thing, three
> times before. The last two times it was from the same IP as
> the current attack, but the very first time it was from a
> different IP, but on the same ISP. And all four times, I was
> using a different IP. Any theories???

> -Weston Pawlowski
> BugWeston.cx
> The Mace Project: http://www.MaceHQ.cx

> ---

> Hi there,

> I read the thread here about automatic retaliation in case
> of an attack
> (automatically closing the firewall for this packets or the
> like) and that this
> would make a nice DoS of its own. Well and then i had an
> idea:

> Newer routers and new (future?) Linux kernels allow for some
> kind of priority
> adjustment. So instead of simply closing the door for
> possibly malicious
> packets, how about automatically throwing them into a lowest
> priority class?
> This would in case of attack ensure 100% bandwith for legal
> packets while
> allowing traffic for this "malicious" packets in case of
> false alarm (may be
> slower). Also the detection routine could keep on checking
> (the malicios packets
> are still arriving), and open the door again some time after
> the last packet of
> that type. Would be somehow like "tarpitting" in mailers (in
> case of spam).

> What do you professionals think about this?

> Greetings
> Siegfried Gipp 

--
 Michael H. Warfield    |  (770) 985-6132   |  mhwWittsEnd.com
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!