sniffer/promisc detector

Mailman List Mirror (Read Only)
1

> Uhm, that would be wrong. This is simply "security through

obscurity".

Yes, it is wrong for the _smart books_. But it works in real life.

Actually, an automated script or manual scan can find it trivially.

If security through obscurity was useless then the USAF
would never have developed the stealth bomber. The British
forces in North Africa would never have employed Jasper
Maskelyne and his magic gang and Rommel would have defeated
the British at El Alamein. And the Serbs would not have been
able to retrieve the vast majority of their tanks from Kosovo
after NATO's bombing campaign.

The fact is that camouflage is a legitimate defense technique
and can be used in networks as well as in the real world.
Nobody would suggest that camouflage is sufficient to
protect something but war is a numbers game. If you can
use obscurity and camouflage to divert a percentage of the
attacks against you then you can pay more attention to the
much tougher security issues which sometimes can only be
resolved through constant vigilance.

--Michael Dillon

2

+++ Michael.Dillon@radianz.com [21/01/04 10:52 +0000]:

>> > Uhm, that would be wrong. This is simply "security through
>> > obscurity".
>> Yes, it is wrong for the _smart books_. But it works in real life.

>Actually, an automated script or manual scan can find it trivially.

If security through obscurity was useless then the USAF
would never have developed the stealth bomber.

TINS (There is no Stealth)

Stealth only works because of the limited number of frequencies used by
military radar. Somebody using a (very) different frequency or a broadband
radar would see your F117A just fine.

The same applies for digging yourself into the sand. That works fine in a
sandy desert, but is no practical methode for hiding yourself on a rocky
desert or in the snow.

The message is: stealth might work in a limited number of situations.
Trusting on stealth will make you look silly in the end. You hiding in
a clearly visible pile of snow with footsteps leading to it. Or running an
outdated (and exploitable) sshd on port 2222.

Like said before: a scripted attack would trivially find your superstealth
ssh-port. Connect to $port, wait for 'SSH-1.99*' or a timeout, and repeat
for $port++.

If you can use obscurity and camouflage to divert a percentage of the
attacks against you

Somebody who isn't smart enough to do 'nmap -p 0-65535 $target' isn't worth
diverting. The 'security' gained with that is negliable. 'Camouflage' on the
big bad internet is mainly a game of fooling yourself into feeling secure.
The newest feature in H4x0rSh13ld Pr0 2003 SE, for the masses. I wouldn't waste
time on matters to trivial to have any measurable effect.

But. Just opinions. Mine, that is.

3

I'm sure everybody who got whacked by Lion or CodeRed or Blaster or.... are
glad to hear those attacks weren't worth diverting.

The point is that if somebody is doing 'nmap -p 0-65535' at you, you are a *specific*
target, and not one of the "get a probe every 4 minutes" targets that every machine
on the wire is.

4

Please, do it:

time nmap -p 0-65535 $target

You will be surprised (and nmap will not report applications; to test a
response, multiply time at 5 ). And you will have approx. 40% of packets
lost.

Practically, nmap is useless for this purpose.

Somebody who isn't smart enough to do 'nmap -p 0-65535 $target' isn't

worth

5

Alexei Roudnev wrote:

Please, do it:

time nmap -p 0-65535 $target

You will be surprised (and nmap will not report applications; to test a
response, multiply time at 5 ).

Yes. It will,

  http://www.insecure.org/nmap/versionscan.html

6

Clipped for brevity...

>> > Uhm, that would be wrong. This is simply "security through
obscurity".
>> Yes, it is wrong for the _smart books_. But it works in real life.

>Actually, an automated script or manual scan can find it trivially.

If security through obscurity was useless then the USAF
would never have developed the stealth bomber. [...]

Yes. But making a bomber "stealth" means designing it to be difficult
to detect by an opponent. It doesn't mean painting "I am Not a
Bomber, I Am The Ice Cream Man" on the side and hoping nobody takes a
second glance at it.

Somebody else pointed out that nmap in its basic mode isn't terribly
fast. That's true. But redesigning for speed wouldn't be that hard.
Scan lots of ports in parallel, checking just for an ACK back from a
SYN, then go through those that responded in order of likelihood (22,
then unassigned ports, then assigned ones), and having it stop when it
finds ssh, and you reduce the time required by several orders of
magnitude. And that's assuming you don't have the help of tons of
zombies. If everybody tries to get obscure with their ports, then
this will become common, and it will be the people who are
legitimately trying to connect who get annoyed by the obscurity. And
if you're only trying to provide services for members of your
organization, a VPNish solution makes a lot more sense than
complicated custom port juggling.

So, okay, sure, like many other things, if a small number of clueful
people are doing this, then they will reap benefits for it. If it
becomes widely spread practice, there will be more harm than good from
it, and people will start ignoring it, working around it, and/or
taking direct action against it that will render it pointless or
harmful to the user. Lots of things have hit this death and been
forgotten or relegated back to the fringe. I'll risk the wrath of
many and mention multicast. Somewhere out there, Randy Bush is
probably thinking of his vision of the future of deaggregated /24s.

-Dave

7

+++ Valdis.Kletnieks@vt.edu [21/01/04 11:40 -0500]:

> Somebody who isn't smart enough to do 'nmap -p 0-65535 $target' isn't worth
> diverting.

I'm sure everybody who got whacked by Lion or CodeRed or Blaster or.... are
glad to hear those attacks weren't worth diverting.

I'm sure moving www.microsoft.com to port 81 would have helped a lot against
CodeRed. But explaining that to the visitors would have been sheer hell,
don't you think?

Why would one have port 135 reachable from the big bad internet? Do you
really expect to use netbios-over-ip over that same big bad net?

Moving bind to port 54 would have stopped Lion. Along with the rest of the
internet.

Nice scenario's, but I still fail to see the advantage of having 'stealthy'
hidden http and bind servers. Dns is a large part of my bread and butter,
and http that of my customers.

And, returning to the realm of realism, moving sshd to a different port
*could* help, but other services cannot be moved. Those can't be 'obscured',
and those can still present grave security-risks.

Like I said: digging yourself in the sand might be useful, but digging in
snow is a waste of time and effort which would have been better spend on
securing that IIS-monster lurking in your POP.

The point is that if somebody is doing 'nmap -p 0-65535' at you, you are a *specific*
target, and not one of the "get a probe every 4 minutes" targets that every machine
on the wire is.

Given sufficient patience an attacker could pose like a random probe. Some
can be very hardheaded. One German D00d has been trying to get me for the
last six years. Every couple of weeks I see a pattern of probes which is
quite distinct, comes from the east, and takes days to complete. If one has
a gazillion hits a day one wouldn't notice such slow but persistant probing.

8

I saw such scanners 6 years ago (amazingly, they could not determine very
old OS and very oold services...).
But, just again, no one use it in automated scans over the Internet. As I
was saying, port camuphlaging works as a very first line of defense - it
cuts 99% of all attacks and akllow you to deal with the rest 1%.

I'll measure time tomorrow... Such tools are usually very slow (and lost
20 - 50% of all packets, so to have a reliable result, you must scan host
2 - 4 times).

9

Yes. But making a bomber "stealth" means designing it to be difficult
to detect by an opponent. It doesn't mean painting "I am Not a
Bomber, I Am The Ice Cream Man" on the side and hoping nobody takes a
second glance at it.

This works as well. 6 years ago we set up faked telnet services, which
writed out login/password and reported 'no more processes', run a few faked
telnet sessions (so that sniffers could record them) and then tracked an
attempts to login. 'I am ice cream man' is a pretty good idea.

Of course, if anyone will do it., Internet became some kind of 'Made man
house' (it is already, isn't it?)

10

Oh, really? I'll do a quick test of your theory that Nmap will be
slow with a 65K port scan, miss 40% of the open ports due to packet
loss, and not be able to report the application/services running on
the port. I may be biased, but anyone who wants to can reproduce this
test (at the risk of pissing off SCO, who admittedly are rather
litigous). To be even more fair, I'll run the scan from a
128kbps-upstream aDSL line:

# nmap -sSV -T4 -O -p0-65535 apollo.sco.com
WARNING: Scanning "port 0" is supported, but unusual.

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-01-22 00:49 PST
Interesting ports on apollo.sco.com (216.250.128.35):
(The 65524 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
0/tcp filtered unknown
21/tcp open ftp WU-FTPD 2.1WU(1)+SCO-2.6.1+-sec
22/tcp open ssh SSH 1.2.22 (protocol 1.5)
199/tcp open smux?
457/tcp open http NCSA httpd 1.3
615/tcp open http NCSA httpd 1.5
1035/tcp filtered unknown
1521/tcp open oracle-tns Oracle DB Listener 2.3.4.0.0 (for SCO System V/386)
13722/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpjava-msvc: No such file or directory)
13782/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpcd: No such file or directory)
13783/tcp open inetd inetd (failed to exec /usr/openv/bin/vopied: No such file or directory)
64206/tcp open unknown
Device type: general purpose
Running: SCO UnixWare
OS details: SCO UnixWare 7.0.0 or OpenServer 5.0.4-5.0.6

Nmap run completed -- 1 IP address (1 host up) scanned in 501.897 seconds

11

I started such scan 10 - 20 minutes ago; it did not completed yet, so I do
not have exact time (it is DSL -> 100 Mbit link + firewall).

But you results shows just what I am saying - 99% of all attacks was caused
by automated tools, and non-standard ports effectively blocks all such
attacks. I agree to spend some time and set up non-standard ports (and even
explain them to customers), if I decrease rate of attacks 100 - 1000 times
(what really happen if ports are non-standard). If you are not a bank, do
not host IRC server, and are not SCO, attack rate decreases to absolute 0.
If you run nmap -p1-65000 in automated tool (with 10 minutes / host, and
usually much more), you will scan Internet forever.

So, it pay off.

12

My results vary from 15 minuts to 1 hour.

13

+++ Alexei Roudnev [22/01/04 09:05 -0800]:

My results vary from 15 minuts to 1 hour.

Mine too. So nmap sucks if you want to quickly identify daemons running on
strange ports. No big deal. This discussion wasn't about nmap to start with.
The point of the discussion was wether it made sense to run services on
non-standard ports to deter cr4x0rs. And I feel it doesn't.

However: nmap can be tweaked, if you want to operate with an axe.

The default timeout per port is 5 seconds. You could shorten that. You could
pre-scan networks, to find only interesting ports, and version-scan those.
You could scan large subnets in parallel. You could re-write parts of it, or
start from scratch.

As long as a sshd yells "SSH-1.99" at you the moment you connect to it's
port there's no hiding sshd.

A well-tuned iptables or equivalent, on the other hand, might hide the
presence of daemons completely for anyone except the designated users. How
is that for obscurity? Unless you're coming from one of a very few
permissible hosts, and connect to a specific IP on the machine you will get
a normal RST, and think the port is unused. Even H4x0rsc4n Pr0 won't tell
you that port is actually a way in, unless you happen to scan it from the
right machine.

14

Mine too. So nmap sucks if you want to quickly identify daemons running on
strange ports. No big deal. This discussion wasn't about nmap to start with.
The point of the discussion was wether it made sense to run services on
non-standard ports to deter cr4x0rs. And I feel it doesn't.

I've sat here and watched this discussion and kept my thoughts to myself
because I'm thinking "Maybe I'm missing something", but I don't think I
am.

I don't think the OP ever hinted at the fact that he runs VUNERABLE
services on another port. He just states that running SERVICES on
alternative ports makes the automated worms/etc miss you. This may give
you the time you need to get patched. It's part of a whole group of
defenses, not the only one.

sshd exploit is known to the kiddies for 3 weeks before getting public.

By the time it's public, a worm is out to own systems with it.

The worm targets 22.

If you are running there and don't upgrade before the worm hits you,
you're infected. If you were on another port, you'd likely have a bit
more time to upgrade.

This isn't about hiding the safe and leaving it unlocked, it's about not
putting it out in the middle of a busy intersection frequented by crooks.
If they target your safe, you're in trouble anyways - having it out of the
way makes it less likely the casual crook will go "Oh that safe can be
opened like this" and walk away with your money.

Jason

15

+++ Jason Slagle [22/01/04 19:13 -0500]:

> The point of the discussion was wether it made sense to run services on
> non-standard ports to deter cr4x0rs. And I feel it doesn't.

I've sat here and watched this discussion and kept my thoughts to myself
because I'm thinking "Maybe I'm missing something", but I don't think I
am.

sshd exploit is known to the kiddies for 3 weeks before getting public.

The k1dd13 isn't able to feed a single packet to my exploitable sshd.

If I were to run that sshd on a non-standard port, and he wants my ass *and*
knows his way around with nmap or such I would gain between minutes and an
hour, as shown by others.

Thanks to paranoid iptables I would gain days, weeks, months or more,
depending on the luck he has with finding out which and 0wn1ng those boxes I
use to gain access to the box he wants to cr4x0r.

By the way: those boxes run other OSses on different architectures, just as
a precaution. Hosted by others. Different networks, different accountnames
and passwords. .bash_history linked to /dev/null, you know the works.

That hours delay won't save my ass, as it takes three weeks for others to
piece together the vulnerability. Those iptables *will* save my ass. More
often than a non-standard port, at least.

And now for running named on port 54 as a defense against buffer-overflows
in bind.. :stuck_out_tongue:

16

> My results vary from 15 minuts to 1 hour.

Mine too. So nmap sucks if you want to quickly identify daemons running on
strange ports. No big deal. This discussion wasn't about nmap to start

with.

The point of the discussion was wether it made sense to run services on
non-standard ports to deter cr4x0rs.

Right anser is _it depends_ - do not rule out such option and do not use it
as a panacea.

17

Ruben van der Leij wrote:

+++ Alexei Roudnev [22/01/04 09:05 -0800]:

My results vary from 15 minuts to 1 hour.

Mine too. So nmap sucks if you want to quickly identify daemons running on
strange ports. No big deal. This discussion wasn't about nmap to start with.

Point of interest: Dan Kaminsky's scanrand (part of Paketto Keiretsu - www.doxpara.com, which seems to be down right now, but the Google cache works) is a very fast bulk scanner:

"During an authorized test inside a multinational corporation's class B,
  scanrand detected 8300 web servers across 65,536 addresses. Time elapsed:
  approximately 4 seconds."
http://www.pantek.com/library/general/lists/newsfeed.osdn.com/osdn-developer-txt-mm/msg00001.html

http://www.doxpara.com/ - down at present but Paketto is widely mirrored.

There was also a "scan the entire Internet" project a few years back which used BASS, a bulk scanner. (grep the report for 'they're heeeere' for a tale of uber hacking that makes the hair stand up on the back of my neck even today...)

BASS:
http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

Report:
http://www.viacorp.com/auditing.html

\a

The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the intended recipient. If you are not the intended recipient any disclosure, reproduction, distribution or other dissemination or use of this
communications is strictly prohibited. The views expressed in this e-mail
are those of the individual and not necessarily of MIS Corporate Defence Solutions Ltd. Any prices quoted are only valid if followed up by a formal written quote. If you have received this transmission in error, please contact our Security Manager on +44 (01622) 723410.

This email is intended for the recipient only and contains confidential information, some or all of which may be legally privileged. If you are not the intended recipient, you must not use, save, disclose, distribute, copy, print or rely on this email or any information contained within it. Please notify the sender by return and delete it from your computer. Thank you.