[clug] shimmer

[Paul Wayper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Couter wrote:
| David Schoen <neerolyte at gmail.com> wrote:
|> This may be a silly question, but how are DoS attacks easier with
|> something like that?
|
| It's painfully simple to forge the source address of IP packets. With
| such a system, I can lock out any IP address I choose with a single
| packet.
|
|> Assuming shimmerd blocks the offender in any sensible fashion (tell
|> iptables to drop packets from connecting ip, or even an snmp event
|> back to a router, to do the same thing) an attacker isn't even going
|> to get through to the application layer so the load on the server
|> should be greatly minimised, greatly reducing the effectiveness of a
|> DoS attack, not the other way around?
|
| How well does the system work when I've pretended to be a few tens of
| thousands of distinct attackers on the 'net? Your iptables ruleset is
| getting pretty big and taking a lot of CPU time to traverse.
|

It might look like an easy way to cause a denial-of-resources attack, but
let's look at a couple of factors:

1) There's a 15-in-10000 (for the example configuration) chance of hitting one
on a server you know is running shimmer, or around than 0.15% chance of
hitting one per connection.  We can talk probabilities, but for statistical
certainty you'd need to generate 9986 packets per minute, or around 166 every
second.  Yes, this isn't difficult, but neither is it unnoticeable.  And
that's just to make sure that one chosen victim's address is denied access to
the service on the shimmer mirage.

2) If we're talking a TCP service that is being protected, then forged packets
aren't going to help you - iptables and other firewalls already deal with such
annoyances.  So the best you can do is either to try and attack UDP services
behind shimmer, be on the same network as your victim so that you can see
returned SYN/ACK packets, or be very good with guessing TCP sequence numbers
(or, if they're running Linux, very very very very good).

3) The black list is handled by shimmer itself rather than iptables, so it's
no load on iptables.  It's only handled for that specific set of ports, so
it's not going to interfere with other traffic.  And it rolls every 15 minutes
so the best you've done is to deny one victim access to that specific service
for 15 minutes, in a way that doesn't interfere with their use of the other
services on the server.

4) If you're forging packets, and you want to take down a chosen server and/or
victim whose IP addresses you know or are on the same subnet as your victim,
attacking the shimmer server is going to be a fairly low-yield attack compared
with the variety of other attacks you could perform.

5) Given that the whole idea of this is stealth, if you don't know the victim
or server's IP addresses but are scanning for vulnerabilities or weak
passwords, this is statistically very unlikely to give you anything and far
more likely for you to not see a thing or lock yourself off their server,
which is the whole point.

So I think you need to read up a bit more on shimmer and think more about the
real attack possibilities.  Your proposed attack doesn't sound like a possible
scenario to me.

Shimmer is, however, not a really credible security solution - see the
comments on
http://www.jgc.org/blog/2008/01/first-release-of-my-shimmer-project.html for
an analysis that shows that an attacker can brute-force find the correct open
port after about 2.5 hours, or eleven scans of the machine given a 15-minute
penalty for wrong guesses.  An attacker with 100 machines can get one machine
to connect to the service about 99.8% of the time in the first minute.  So
once again this is not a realistic block to a determined attacker, but it does
keep the script kiddies and scanning bots away from your SSH server (which may
be useful if have to run SSH and don't trust your users, as many hosting
companies have to).  And I've had just as much success setting my incoming SSH
port to something still easily guessable but not 22.

Have fun,

Paul

P.S. This may come across as a bit rude, but given the somewhat paranoid
security "threats" I've been challenged with recently I may be a bit short on
the issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFIdgsPu7W0U8VsXYIRAm4uAJ91rc4Ml9fxQwOoW3BjaUgqxsFWSwCZAbCX
ZYDfmPRlGz4jQXWfuBNNPaU=
=D902
-----END PGP SIGNATURE-----