February 11th, 2004 08:06 PM
Not all of nmap's scan methods are easily detectable. If you don't do OS detection, don't use an exotic scan type (XMas, NULL, FIN), and don't send pings, there should be nothing that identifies the source positively as nmap.
Using -sS is the best for most purposes, if you want the tool to remain undetected use that.
However, an IDS which detects port scans generally will still detect it.
There is a new option that is -sI, which is the "Idle" scan. This works by spoofing packets and bouncing the replies off a "zombie" host (An host with an OS with a known sequential TCP ID generation algorithm) to detect the replies.
Using idle scan, no non-spoofed packets are sent to the target, thus it is very difficult for them to detect the true IP address of the scanner.
I have tested the idle scan (on my LAN only!) and it seems to work. It's not clear what performance or other implications there are though.
To remain entirely undetected is impossible. To effectively cloak your IP address is fairly straightforward.
By combining idle scan and decoy scans (coming from spoofed hosts which aren't really scanning), it would be very difficult for the IDS to determine your true IP address. They would have to contact the ISP of all the IPs which appear to be scanning them, until they find the true one (that would probably fail), but if that succeeded, they would then need to have IDS logs on the zombie to determine the attacker's true IP (again, unlikely).
The attacker would choose a zombie which was known not to have IDS logs of its own (typically a quiet machine left turned on with no services open or processes running). The attacker could also use known public multi-user machines as decoys (example: widely used shell services)
February 11th, 2004 08:18 PM
Ah, did not know about -sI. -sS is even worse though, as most IDS' also check for breaks in TCP/IP standards, which is a dead line of sight for half open port checking. At least, mine goes off and so does my works.
I agree, there is a lot you can do to have nmap be as undetectable as possible, and I am well aware of it, but when it comes down to it nmap is detectable through it's normal means of what makes it *nmap*. Stealth scanning, OS detection, fingerprinting, Exoitic scanning, all of those are horrid ways of checking security as the IDS goes simply nuts.
I will give -sI a shot though, as even if nmap is detectable moreso than by hand port scanning, it is best to leave the trail pointing to someone else. Awesome responce, and thanks
February 11th, 2004 08:38 PM
If you turn pinging off, -sS should be no more detectable than using any other TCP client.
Especially if you get your host OS NOT to send a RST back to the half-open port.
In that case, the syn scans look exactly like someone trying to open a connection but quitting half-way through (or network misconfiguration causes the SYN ACK to get lost or something). These events are probably fairly common (especially on a server which routinely receives a large amount of SYNs, like a web or mail server)
February 11th, 2004 08:48 PM
In all honesty what Slarty is referring to is not avoiding being detected but rather making such a bloody racket that the poor receiving admin has little or no chance of determining where the real source is. Yes, you may not have been identified as an NMap scan but the sheer volume of traffic tells me that you are serious as opposed to a basic scan that we all see 1000 times a day.
With all the kiddie scanning, (which is usually obvious by the fact it runs the whole subnet against a single port - they have their latest, greatest script and they need port 21 open....<LOL>, it's easy to see a "normal" scan that picks on a single machine and runs a number of ports implying that it is the machine the attacker is interested in rather than the specific service. You rarely see the whole subnet being scanned across numbers of ports, (except open proxy scans which are a bit obvious), and it would imply either impatience or incompetence on the part of the attacker - both of which are going to get him/her caught.
After that, with all the preproceesors etc. in IDS's, we in the security community have managed to slow down the "enemy". If they _really_ want us then that scan must take days not hours or minutes because they have no clue at that point if they are being watched for, where they are being watched for, (inside, outside, at the firewall or all three), and what the parameters set on the "watcher" are. If they don't want to get caught and blocked or worse they have to be more careful every year as new rules and products hit the market.
Then they have to wonder if they are hitting a honetpot/net.... That could be pretty fatal....
Pooh's question does bring up an interesting question though..... Have we reached the point where some of the "standard" tools are beginning to not be a good choice for attackers and thus they have to write their own or use innocuous tools like their web browser and WinDump and analyze the packets for themselves to determine OS etc.
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
February 12th, 2004 12:32 AM
Good point... repeatedly hitting firewalled ports can show up even a fairly polite port scan easily... my point was, that with tools such as the idle scan, it becomes virtually impossible for a sysadmin to take any action against the originator's IP.
Of course if you have a honeypot and they own it, they will probably start using their own IP after a little while...
Anyone who has run IDS in the last three years will know that there are now so many windows worms around, there's practically no point in setting up IDS rules for port numbers that these worms are known to attack, there is just far too much traffic.
Of course finer-grained rules that don't detect the worms are always preferable.
February 12th, 2004 01:32 AM
Another option that may be of interest on Nmap is the --data_length switch, that will enable you to add to the packet size, possibly defeating some signatures.
A handy tool for Windows users who want to craft packets is engage at http://www.engagesecurity.com/produc...packetbuilder/
February 12th, 2004 04:19 AM
Many of nmaps packets are easily recognizable yes, but its such a popular tool thats no surprise. And normally I would say that since penetration testers have all the proper authorization to 'go get the goodies', being silent may not be a major issue since they KNOW you are there and you arent going to be prosecuted if they find you However, I'm willing to concede sometimes a part of the bargain may involve going undetected, hopefully this means you're good enough to do one of the following:
A.Use nmap effectivley the way it is
B.Kindly edit the source that Fyodor gave you.
C.Program your own damn tools
\"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier
February 12th, 2004 05:11 AM
Well what about if you use nmap -v -v -sS -PO -O -p 1-65535 192.168.x.x
[list=1][*]-v verbose[*]-sS SYN stealth (best TCP scan)[*]-PO Dont ping hosts[*]-O OS detection[*]-p ports to scan 1-65535[*]192.168.x.x = host[/list=1]
You can also setup decoy's using the -D option in nmap. Decoy allows you to hide your scan. I say 'the more the merrier'
February 12th, 2004 05:39 AM
I think the point here is how to avoid the IDS. If your computer tries to connect to every single port in the TCP/IP specs, then I'm sure there is a good chance that someone would notice it. How many services do you know that legitimately use anything above port 2000 or so for public access?
So obviously, scanning stuff that has no real application or use in a common network will be noticed. An example of this would be searching for home-made freshly baked chocolate-chip cookies. If your mom puts them in a cookie jar, and your friends put them in cookie jars, would you go trample in your neighbors flower garden searching for cookies if you cought a wiff of them floating down the street? No, you'd find their cookie jar.
This cookie jar is a legitimate service, it is pretty standardized that you put cookies in them. But since everyone puts cookies in a cookie jar, then if you know where their cookie jars are you could hypothetically steal their cookie jars. So, they watch their cookie jars, right? Of course! But there are of course some weird neighbors who would put their cookies in the refrigrator.
So how does this apply to computers? I hope I'm not veering off-topic here...
The cookie jar could be the FTP, HTTP, SSH, TELNET, etc services. It is a service that provides content/data/privilages (cookies). If you have a cookie jar, you are assumed to provide the cookie service, so you will see traffic (kids coming to get cookies when they smell you cooking). Let's face it, there is a lot of kids who want cookies, and in computers a lot of traffic. How do you find out if a kid is taking more cookies than he should? The IDS has to do this.
What if you have that weird neighbor who puts cookies in the refrigrator instead of the cookie jar? Obviously, if you didn't know he did that and you try to steal the cookie jar at night, you get no cookies. And the missing cookie jar shows that someone tried to steal his cookies. Like a honey pot. Do you honestly want to check everyone's refrigrator if you decide to go on a night time cookie raid? It is risky, and the cookie could of course be soggy since refrigrators do that, and all of that can be part of a Honeypot / IDS.
Back on topic, I hope...
The point is what is the best way to fingerprint a host without arrousing suspecion? Obviously, it is best if you can get insider information, ie watching that neighbor hide the cookies. But the purpose here is that you don't, and how do you avoid doing what everyone else does so you can get the cookie? Do you really want to risk searching the fridge for the cookies? Or do you just run in blind for that jar... And how can you do it the different way (not use nmap), just barely get by the IDS, and get your cookie and get the heck out of town?
I don't know how to do this, but I think that pooh sun tzu may be one of the people who may think up other ways of solving the situation to get by. Perhaps my analogy helps throw a new light on the situation, perhaps it doesn't, but with how much time I spend writing it (instead of other homework) I'm posting. IMHO, the best way to get by would be with a rare 0-day exploit, even though it is possible to protect against some of these even before they are discovered if the right filtering is done on all of the data; a sort of pranoid "Don't trust input!" security system that will get anyone who tries...and then there is finding the 0-day in the first place...
February 12th, 2004 07:45 AM
This is becoming very redundant, over, and over, and over again.
Well what about if you use nmap -v -v -sS -PO -O -p 1-65535 192.168.x.x
1. -v verbose
2. -sS SYN stealth (best TCP scan)
3. -PO Dont ping hosts
4. -O OS detection
5. -p ports to scan 1-65535
6. 192.168.x.x = host
1. - verbose doesn't do a single thing for or against nmap anoniminity
2. -sS half open scans are great, but we covered that
3. -P0 is great too, but already covered
4. -O this was in my origonal post, and one of the main things that GIVE AWAY NMAP to IDS, is their window timestamp checks for OS detection.
5. -p 1-65535 - Every single port? That's just asking to get caught because of noisy scanning, that IDS picks up by the 3rd port check.
People, my question was answered on the first page, but this has continued on still trying to give me nmap advice. Thank you for the tips and tricks, but I know how nmap works inside and out, thus why I wanted to bring to everyone's attention it's downsides (see my first post). So please, no more tips, no more tricks. I know how nmap works and how incredibly easy it is to dtect any nmap scan. Besides, the origonal question of "Is there anyway to hand craft packets?" that this thread is about was answered. I'm not trying to sound rude, but it does seem as if very few people are taking the time to read the entire thread.
My thanks, to Tim, however, for his great insight and thoughts upon current IDS methods, and to the open mind he had towards considering "what else could there be that isn't known yet, to us?"