Avoiding Detection

How
not to set of the Intrusion Detection System

In
case you haven't noticed, over the past couple of years its getting consistently
more difficult to find a server to go mess around with. Although a lot
of companies (many of which haven't a clue about security) are being set
up every hour, it's relatively difficult to go out there and find a potential
target without spending many hours perhaps more likely days finding these
sites. Anyhow, the main reason for this "lack of playgrounds"
as I like to call it, could possibly be attributed to the fact that any
site with an admin worth his salt, would have installed an Intrusion Detection
System.

I'm
talking about systems look for odd activity, or "anomalies", as they are
often called. IDS's have probably been around longer than a lot of people
realise, the only difference is that it was not categorised as such till
recently.

ID
Systems go back to the days of portscan loggers, and PERL scripts that
administrators would set up to look at system logs for remote and local
anomalies. This could be anything from excessive amounts of incorrect
password guesses using "su", to having pre-compiled software directories,
or set-uid binaries lying around. Basically, any tool that looks for bizarre
patterns in system usage or network traffic can be called an IDS.

Some
system admins rely only on IDS methods, whereas the smarter portion of
them still use some method of a firewall. If a firewall is in place, the
IDS also may communicate with the firewall, telling the firewall the attacker's
IP Address and letting the firewall take care of business. When I refer
to firewall, I'm talking about software like ipchains not a piece
of hardware that is put in place in a network.

There
are a few free Intrusion Detection System programs available for UNIX,
and plenty of commercial ones for NT as well as UNIX. Exploration of a
network which does not belong to you (or exploration of one where you
don't have permission to do so) is tricky business. Homework is essential.
Blindly port scanning a machine 2000 miles away might actually get you
busted (you don't want to be locked up for a friggin portscan now do you?)

The
problem stems from the fact that the majority of IDS's will set off alarms
if it sees typical portscanning, tracerouting, and OS fingerprinting.
Add to this the likelihood that the system administrator is probably some
paranoid dickhead, and you can pretty much bet your bottom dollar that
their IDS has been set to operate on the "extreme paranoia"
setting.

Finding out what IDS they're running.

The
first step in finding out what IDS the remote system is running would
be to check what OS is installed. Why? Well for the simple reason that
it narrows down the choices of IDS that could be installed. Once you know
what IDS software they are likely running, you will have a better idea
of what you can and cannot do.

TCP
Fingerprinting using nmap's fingerprinter for example might work without
raising any flags, but it does require that you know an open port. Yeah
sure, you can do a full portscan, but that would probably set of most
if not all IDS's - game over... By using a TCP fingerprint test, you're
sending 6 STRANGE packets to an open port. Certain loggers can detect
these bizarre patterns of packets, and some IDS's will pick up a quick
burst of packets as a Denial Of Service Attack, and you're nailed. That's
Bad.

One
of the best methods to employ would be to set up a test system on your
LAN, install as many IDS's as possible and see if nmap or other network
scanners will set it off. This way, you can experiment with different
settings till you find something that works. Another good idea would be
to surf on over to your targets website and look around for stuff. Under
normal circumstances no IDS will register surfing as an intrusion unless
you happen to stumble onto one of their restricted pages. Your mileage
will vary on this one.

An
easy method to start you off on the "what OS are they running"
question would be to try and get a response from their web server. There
are a bunch of scripts out there that will either send a malformed URL to port 80 of the server and read back the error message. Alternatively
if you're a lazy ass and couldn't be bothered with downloading shit, just
telnet to port 80 and type in GET //.. this usually does work,
and the server will return some garbled crap about not being able to comprehend
a word of what you just typed along with the line Server : Apache x.x.x
or IIS etc. Once again your mileage will vary depending on the target.
It's worth a try though.

There are other ways of trying to figure out what OS they are using on
the server you wish to play with. These can range from Social Engineering
techniques or any other method you can think of.

Once
you find out what OS they are most likely using, go to your favorite search
engine (I personally use Metacrawler
and altavista.com) Just look for
a list of IDS software that runs on that OS. Once you've got a list, check
to see if the IDS is a commercial version or a free one. Grab any of the
free ones you can get, and set them up on your test machine. Of course
the exact configuration that your target is using would be extremely difficult
to guess, so try as many different settings you have the patience for.
Your goal here is to see how far you can push the IDS without setting
off any alarms.

Try
different stealth portscanning techniques, and anything else you can think
of. See how long of a delay you can use between ports on a portscan, and
randomize what ports you use. Many people will scan just one port every
3 hours or so, in random order. By the end of a day, you could have a
definitive answer about 4 or more different services. With a really paranoid
sysadmin and the right IDS, even this kind of scan can lead to being scrutinized. All things considered, once you know what OS they are running, a check
on just a few services will tell you an awful lot if you know what you're
doing. If you know it's Solaris, then you look only for "buggy" Solaris
services to try to exploit. You don't go searching a Solaris server for
a linux-specific exploit, do you? This kind of slow scanning is becoming
more and more popular, and the IDS industry probably is not far behind.
I know some IDS systems can be set to look for slow scans, but they only
detect a slow scan if it can find a pattern (for instance every 2 hours
and 42 minutes (roughly) it picks up a connection to a different port
from the same IP Address, and this happens for almost a whole day... some
IDS can be told to red-flag this type of activity)

Another
variation that sometimes throws off an IDS is using the proof-of-concept
scan and sniff approach, where you portscan someone with a spoofed IP
Address of a machine on your local segment. If you are sniffing, you will
see the results of the portscan, even though they were not destined back
to you. This shows up in system logs and to IDS systems as if it were
not your machine portscanning, but someone else's... sometimes.

Another option, similar to the aforementioned one, is to use different
Internet access methods. If you have Internet at work, scan one port from
work. Once, that's all. Go home, use your dialup account to do it again,
just one port. Go to a cybercafe or a friend's house and do it there,
too. If you take your time and execute this part very carefully, there
will be very little cause for alarm as far as your target is concerned.
This can also be executed if you have friends on the phone or in IRC/ICQ,
you can say "hey...check to see if port 25 is open on yourmomma.com!"

Justremember, when you know what your target's defenses are, you have a better
chance at being able to set up similar defenses for yourself and play
with it. On the flip side, any system administrator that leaves something
as important as an IDS with the default values shouldn't be a sysadmin.
Unfortunately, there are way too many of these around. If you stray away
from the defaults when setting up an IDS system, you are likely to catch
more of the activity. Your modified rule sets will more than likely be
stricter than default, and the people who think that they've managed to
fool your system will suffer the same fate as that guy who portscanned
you 33 times last week.

Peace
out. -
L33tdawg

1.)
OsReview :
Red Hat 6.1 -
L33tdawg

2.)
Lockdown
: Securing your Linux box (part 1) -
L33tdawg

3.)
Remote OS
detection via TCP/IP Stack FingerPrinting -
Fyodor

4.)
Installing
Linux on a Laptop -
OB-1

5.)
Hacking
payphones - Telstra style -
OB-1

6.)
Testing modems
with a DoS attack -
L33tdawg

7.)
Avoiding detection
-
L33tdawg