Re: sniffer/promisc detector
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
+++ 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. -- Ruben van der Leij
On Wed, 21 Jan 2004 15:58:14 +0100, Ruben van der Leij <ruben-nanog@nutz.nl> said:
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. 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.
+++ 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. -- Ruben van der Leij
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
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 -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
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). ----- Original Message ----- From: "Crist Clark" <crist.clark@globalstar.com> To: "Alexei Roudnev" <alex@relcom.net> Cc: "Ruben van der Leij" <ruben-nanog@nutz.nl>; <nanog@merit.edu> Sent: Wednesday, January 21, 2004 11:26 AM Subject: Re: sniffer/promisc detector
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
-- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On Wed, Jan 21, 2004 at 09:04:40AM -0800, 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 ). And you will have approx. 40% of packets lost.
Practically, nmap is useless for this purpose.
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 # So the full 65K port scan, plus OS and version detection took a little over 8 minutes over a relatively slow connection. I ran it several times to ensure ports weren't being missed. A quick test from my colocated machine took 3 minutes. And it isn't like I had to watch the whole time -- I was surfing a porn site in another window while it ran. The services would have still been detected on different ports as the same probes are done. I don't think using nonstandard ports will help against any but the most marginal attackers and worms. But if those are a serious problem, perhaps more time should be spent patching rather than moving vulnerable services to unusual ports. I am not saying you won't get _any_ benefit at all from this obfuscation, but I seriously doubt it will be worth the headaches. If ports don't have to be reachable from the outside, filter them at your firewall/router. If outsiders do need to reach the ports, moving them around will just be a pain in the @#$ for those legitimate users. You'll find that your own users are the ones port scanning you in order to locate the services you've hidden. Cheers, Fyodor http://www.insecure.org PS: Yes, the scan would have been much slower if that host had a "default deny" policy, but would not have been outrageous. You are permitted to scan "scanme.insecure.org" to test that scenario. The time taken is not unreasonable, when I run 65K scans against large heavily filtered networks, I usually just let it run overnight.
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. ----- Original Message ----- From: "Fyodor" <fyodor@insecure.org> To: "Alexei Roudnev" <alex@relcom.net> Cc: "Ruben van der Leij" <ruben-nanog@nutz.nl>; <nanog@merit.edu> Sent: Thursday, January 22, 2004 1:12 AM Subject: Re: sniffer/promisc detector
On Wed, Jan 21, 2004 at 09:04:40AM -0800, 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 ). And you will have approx. 40% of packets lost.
Practically, nmap is useless for this purpose.
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 #
So the full 65K port scan, plus OS and version detection took a little over 8 minutes over a relatively slow connection. I ran it several times to ensure ports weren't being missed. A quick test from my colocated machine took 3 minutes. And it isn't like I had to watch the whole time -- I was surfing a porn site in another window while it ran. The services would have still been detected on different ports as the same probes are done. I don't think using nonstandard ports will help against any but the most marginal attackers and worms. But if those are a serious problem, perhaps more time should be spent patching rather than moving vulnerable services to unusual ports.
I am not saying you won't get _any_ benefit at all from this obfuscation, but I seriously doubt it will be worth the headaches. If ports don't have to be reachable from the outside, filter them at your firewall/router. If outsiders do need to reach the ports, moving them around will just be a pain in the @#$ for those legitimate users. You'll find that your own users are the ones port scanning you in order to locate the services you've hidden.
Cheers, Fyodor http://www.insecure.org
PS: Yes, the scan would have been much slower if that host had a "default deny" policy, but would not have been outrageous. You are permitted to scan "scanme.insecure.org" to test that scenario. The time taken is not unreasonable, when I run 65K scans against large heavily filtered networks, I usually just let it run overnight.
+++ 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. -- Ruben van der Leij
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 -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
+++ 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.. :P -- Ruben van der Leij
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.
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... 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.
participants (8)
-
Alexei Roudnev -
Andrew Simmons -
Crist Clark -
Fyodor -
Jason Slagle -
Michael.Dillon＠radianz.com -
Ruben van der Leij -
Valdis.Kletnieks＠vt.edu