Hypervivid Tiger Team - Port-Scanning: A Practical Approach ----------------------------------------------------------- Version 1.0 Author(s): Doug Hoyte - Senior Programmer * Introduction * Your arsenal * Fundamentals * Port scanning * Practical Scanning Introduction ------------ Often times it is useful, even necessary, to gather as much information as possible about a remote target. This includes learning all of their network "points of entry", the operating systems used, firewalling methods employed, services running, etc. Note that while it certainly is possible to portscan with a windows machine, I will be focusing on using a unix machine with certain utilities installed. This is due to Windows' lack of raw socket access (pre Win2K) and the lack of decent, free, portscanners availble for the platform. In the next section I will share some useful pointers on portscanning. Note that root level access is required on your unix machine for many scans. Your arsenal ------------ Which unix you use is entirely up to you. I suggest you verify that nmap will run on your flavour of unix before deciding on one in particular. Linux, BSD, and SunOS are good choices. HP-UX, AIX, IRIX, SCO, XENIX, and the rest of the plethora of unix clones MAY work, but you'll be sailing untested waters. Here's the list of other programs you might want to install: * nmap (The defacto security scanner) * nc (NetCat - The "IP Swiss Army Knife") * tcpdump (The original sniffer. Personally, I prefer snort, but tcpdump will run on just about any unix out there...) * lynx (Excellent console based webbrowser. Always handy to have) For the Tiger Team member involved in physical audits, nothing is more valuable than a laptop with a network card in it, running unix. It can be carried around throughout the company building, and plugged into ethernet jacks and start sniffing/scanning immediatley. I personally would suggest NetBSD or OpenBSD for this purpose, because they are small, fast, mobile, and VERY capable unix systems. Fundamentals ------------ In order to understand how to make your scans efficient and effective, you have to grasp a few concepts about TCP/IP networking, and how the operating system accomplishes this. All of the internet (which relies very heavily on TCP/IP) uses packets to send data back and forth. There is no direct stream of data like, say, a telephone connection. Instead, the computer sends packets, which are processed, filtered, fragmented, and routed throughout other computers, until this packet of data reaches its ultimate destination. If this concept is completely foreign to you, you will probably have much difficulty understanding basic portscanning. In any case, you must understand how computers can cary on simultaneous connections to different computers at once. The explanation can actually get quite detailed, but is the basis of portscanning. Here are the basics: Every internet connected computer has an IP address (either permanently designated to that very machine, or dynamically assigned upon connecting to the network) which uniquely identifies that machine to all other machines on the network. Think of the IP address as a name for the computer. All packets you want to send to a particular computer, you would slap that address onto the packets you want to send, and throw that packet out onto the internet, and let the internet take care of getting that packet to the machine with the destination's IP address. But what if I want to have 2 connections to one IP address simultaneously? How will my computer know which packets are for which connection? Ports, my friend. Each internet connected computer has 65535 potential ports available to them. Keep in mind that usually only ports greater than 1024 are designated for general use, with the rest of the ports reserved for services on machines, like webservers (port 80), FTP servers (port 21), SSH servers (port 22). At least that's how it's supposed to work. There are to many exceptions to list. For instance, IRC servers (port 6667), MySQL (port 3306). Note: One of the reasons why I insisted you have root access on your unix machine is that if you want to listen on a port belown 1024 in unix, you simply must have root privileges. Unix won't let you "bind" to that port otherwise. Note that this is not necessary for most portscanning techniques, but can be very valuable in certain situations. Okay. So what happens when I, as a client, want to open a connection to a computer on the internet on a specific port? This also is quite involved, so I'll summarize. You slap together a small packet which has a special "flag" set on it: SYN (Synchronizing). Then you slap on your own IP address (the "source IP"). Then you pick a random, unused port between 1024 and 65535, and slap that on the packet (the "source port"). Next you slap on the destination's IP address (the "destination IP"), and the port you want to connect to ("the destination port"). Then you send the packet onto the internet and (hopefully) a few milliseconds later it will arrive at its destination. From here on in, all TCP/IP packets for this connection will use the same ports and IP addresses, except, of course, when the server sends a packet, then the source becomes the destination, and vice versa. So, upon recieving the packet, the server must make a decision. First off, does the server want to talk to this IP address that's knocking on its door, so to speak. If it does, it will check if the source port is indeed open for communication (SYNchronization, as it were). If so, it replies with another packet, except this one has not only the SYN flag set, but also the ACK. If, on the other hand, this port is NOT open, it sends an ICMP message (which is NOT, in fact TCP/IP, but operates over the internet nonetheless): an RST (reset). The user at the client's computer would probably get an error message like "the service you requested is not online at ". Assuming that all went well and a SYN/ACK was transmitted, the client will then reply with a packet with only the ACK flag set. Then, the 2 can begin sending data packets between them (which all, as a matter of fact, have the ACK flag set). Now this may seem like an awful amount of trouble to go through to establish a connection... Why not just start sending packets? Well, if you think about it, this is the minimal amount of communication required for verifying to both parties that data can, in fact, be sent in 2 directions. Interestingly, there is a second method of sending data over the internet as well, called UDP/IP, which basically DOES just start sending packets. Unfortunatley, UDP/IP is renowned for its unreliability. Not only are packets NOT guaranteed to arrive in order and without data corruption, but their arrival isn't guaranteed at all! UDP does have its place, though, especially when you don't need full data integrity (Streaming audio is the classic exmple). nmap offers UDP/IP scanning techniques too, by the way.) A couple notes before we proceed to actual port scanning: * Here's what an IP address might look like: 192.168.24.53. * All information in this manual deals with IPv4. * Often, IPs and DNS names can be used interchangably. Think about DNS names, like hypervivid.com, as being turned into an IP by the operating system before being used by the networking code. * TCP/IP connections are also closed via ICMP (ideally), or by timeout (as is often the case) * If a client that DIDN'T request a connection ever recieves a SYN/ACK packet, it is supposed to reply with an ICMP message responding appropriately. Port-Scanning ------------- Basically, for this section, you can simply throw out all other port scanners, and learn how to use nmap. nmap is an extremely powerful, free security scanner that, in my opinion, beats the pants off even the most pricey commercial scanners on the market. A skilled nmap wielder can scan through firewalls, determine remote operating systems, preform literally dozens of different types of scans, and even bounce scans off of FTP servers, so the victim will think the FTP server is scanning them. Congratulations go to Fyodor, the author of nmap, and all the other hackers who helped make nmap the incredible beast that it is today. This is by no means a complete nmap manual. The most complete documentation is, of course, the freely available source code. Next to that, you have to rely on the man page, even though the man page neglects to mention several interesting features of nmap that you could only ever find buried deep inside the source. I'll touch upon several of the different scan types, OS detection, tips, and a few of these "undocumented features". Okay, here's a very simple nmap scan: nmap 192.168.9.3 This uses many defaults. It defaults to a standard TCP scan. You could also have done it like so: nmap -sT 192.168.9.3 Description of -sT: Basically, this scan attempts a full TCP/IP connection as described above with every port listed in nmap's custom /etc/services file. It then reports all ports it finds open. Note: If you're not, in fact, scanning over the network (for example, nmap localhost), this is the scan you want to use. It's VERY fast, and most IP loggers don't log TCP/IP connection attempts from 'localhost'. Note: If you don't have root on the box you're scanning from, this is the only "standard" scan you can do as this scan doesn't use raw sockets, and instead relies on the ubiquitous connect() system call. Advantages: * Fairly fast scan * DOESN'T require root privileges. Disadvantages: * VERY easily detectable. Description of -sS: So let's consider a "SYN scan", or "half-open scanning" as it is commonly called. Basically it works like this: Your machine injects a SYN packet of the appropriate port and IP address onto the network stream so that your OS doesn't even know it's sending out this packet, that way it won't be expecting a SYN/ACK packet back from the server. Then, nmap starts listening directly into the network stream until it sees either SYN/ACKs or the ICMP messages saying the port is closed. That's all nmap has to do. The OS, upon recieving this SYN/ACK packet from the scan victim, thinks "I didn't request this connection, I'd better send an ICMP error message...". It's important that your OS does this, otherwise the server will sit there expecting an ACK packet for quite some time, which eats up memory and such. This is referred to as SYN flooding, which is something you DON'T want to do if stealthiness is your game. (I'll touch briefly on how nmap can be used as a very powerful SYN flooding tool a bit later). It's called half-open scanning because a full connection is never made. nmap takes just enough information it needs, and never has to open a full connection. Advantages: * Fairly stealthy... * Most firewalling software doesn't log these particular scans, although many do. * Reasonably fast scan. Sometimes faster than -sT, sometimes not. Disadvatages: * You need to be root to preform this scan. * I've found this scan can be signifigantly slower than -sT on older hardware with ISA ethernet cards for whatever reason. * Still sends packets to the victim that have your IP on them. Description of -sF, -sX, -sN: There are 3 other types of "standard" TCP/IP scans: -sF, -sX, and -sN. Basically they have to do with setting various TCP/IP flags on the packets that you scan with, relying on the standard methods of handling these unusual packets set out in the networking standards: the RFCs. To be honest, I get very little use out of any of these scans. They aren't much more difficult to detect and log than -sS, and you can't be certain that all scanned OSs respond according to the RFCs, so chances are you'll have to use a different scan just to confirm the results of these ones! Of course, there are people that really like these scans. See the nmap man page for details. Advantages: * Debatably more stealthy than SYN scans. * These scans will impress your friends if you do them right. :) Disadvantages: * Sometimes you get cryptic, misleading results. * Still sends packets to the victim that have your IP on them. Description of -sI: This is an exciting new scan that has just recently been incorporated into nmap. Few people seem to know how it works, but Fyodor has promised us some documentation on this scan soon. If it works as advertised, this scan has an incredible amount of potential. I've played with it a bit, but haven't got it working. Advantages: * No packets sent to the victim from your IP! * Your friends will idol you if you do them right. :) Disadvantages: * Probably has some serious limitations. This document will be updated when I understand more of this scan. Description of -sA: This little doozy of a scan is highly underrated, in my opinion. It has a very large amount of legitimate network debugging uses. Basically it works like this: You want to find out if a firewall is filtering certain ports (filtering means not letting you see which ports are open behind the firewall by not returning ICMP messages saying you can't be reached). Good for mapping out firewall rulesets. Plus if you know a port is open behind a firewall, you can deduce wether or not you're dealing with a stateful packet filter. You can't find out which ports are open on internal hosts, but you can determine which hosts to scan when you get that short, 2 minute opportunity on the internal network after slipping through a window right before closing time. ;) Seriously, though, in the hands of somebody who understands firewalling principles, this scan can be incredibly valuable. Note: When you're reading the nmap manpage, you'll see that it mentions the ACK packets have random sequence numbers and such. It seems everybodies favorite IDS (intrustion detection system), snort, was using a clever monitoring trick to see if somebody was mapping out the firewall ruleset. See, earlier versions of nmap had a fixed value, so it was trivial to pick them up, and find any GUARANTEED suspicious activity. That's some nice detective work by the people who make snort. Congrats go to Fyodor too, who fixed it, enabling us scanners to ACK scan free from worry. :) Advantages: * This stuff is probably never logged. * Very useful for the skilled scanner. Disadvantages: * It isn't really a port scan. Description of -sW: This is an even cooler scan than -sA. Not only does it use ACK packets instead of SYN packets to find your targets filtering rules, but it will also report open ports on the target! It does this via some sort of TCP/IP window size anomalies. Unfortunatley, it only works for some OSs... (It works for many popular ones, though, including VMS, SunOS 4.X, and BSD) Advantages: * Everything holds from -sA Disadvantages: * Doesn't work on all Operating Systems Description of -sU: This is a UDP scan. UDP, or Uniform Datagram Protocol, is a straightforward protocol. You send a packet, if it gets there, good. Any applications bound to that UDP port on the destination gets the data. If it's closed, they send back an ICMP message. That's basically it. -sU just sends UDP packets to all ports in the services file. UDP isn't that commonly used, but often times it's a good idea to do a quick UDP scan on a host just to see whats up. For instance they might be running NFS or something. %90 of the time, I'm simply not interested in UDP ports, so this feature doesn't get a lot of use. Advantages: * Quite fast, I've noticed. * It's good to have a UDP scanning feature. Disadvantages: * Not as useful as the other scans, usually. Description of -sR: Once there was a bug in a Beta version of nmap that killed -sR support temporarily... It went unnoticed for quite some time before Fyodor himself caught the bug. He was somewhat upset, because nobody had tested -sR on the Beta... I'm sorry Fyodor, but I've never once used -sR. Has to do with scanning for SunRPC ports, and finding their versions and whatnot. (See the manpage for info). Personally, I think this scan belongs in an application level scanner, NOT in nmap, but this is, of course, a matter for continuous debate. Description of -sO: This is an interesting scan. It doesn't scan for ports at all. It scans for open internet protocols that the target is accepting... I've only ever used this out of curiosity or to impress clients. :) Description of -sL and -sP: This would be a good time to bring up an excellent feature of nmap. It can scan more than one host from a single command line entry! Yes, that's right, you could scan your whole subnet with this command: nmap -sS 192.168.0.0/24 or nmap -sS 192.168.0.0-255 You can do all sorts of crazy combinations, like: nmap -sS 1,3,9-11.3-9.-1.5- That would scan a LOT of hosts... I REALLY like how Fyodor did this... It's so... useful! Anyways, the -sL scan is handy when you have an extremely complicated IP range to scan, and you just want to make sure nmap is interpreting your command the way you want it. At least, that's the only use *I* can think of for it... See, -sL DOESN'T scan anything... It doesn't send any packets out on your network... -sP is completely different. It pings hosts to see if they're up or not. This is a very useful scan. Say I wanted to see which hosts are up on my subnet, I'd do a: nmap -sP 192.168.0.-254 nmap, by default uses both ICMP and ACK packets to identify wether a host is up or not, although you can change this behaviour with the -P switch, which will be discussed shortly. -P nmap usually wants to confirm that a host is up before scanning it, so it sends out "pings" to the target and waits for its replies. Often, you'll want different methods of pinging hosts, or you don't want to ping at all. This is where the -P switch comes in: See the man page for the different available modes. One of the most useful is -P0. This is for when you KNOW the host is up, but they are dropping pings. -F By default, nmap will scan all ports < 1024, plus the ports listed in nmap's special services file: /usr/local/share/nmap/nmap-services normally. The -F scan will only scan the ports listed in the services file. Actually, the "fast" scan isn't signifigantly faster than a normal scan. You save scanning 435 ports; maybe a few seconds. I almost never use this switch. If you really want a fast scan, think about which ports you are interested in, and use the -p switch (keep reading) to narrow down the scan. IF, however, you want to scan all 65535 ports on a host, you should use this scan: nmap -p 1- target.com Which leads us to our next switch... -p This is one of the most commonly used switches. It specifies what ports you actually want to scan. It uses similar syntax as specifying multiple host scanning, and is equally flexible. Some examples: nmap -p 2-500 target.com nmap -p 2,4,8,29,500-9000 target.com nmap -p -300,60000- target.com nmap -sS -P0 -p 2-500 target.com -O Remote operating system identification is one of nmap's coolest features. The hacker community that develops nmap always sends in new OS "fingerprints" of new or obscure operating systems, so nmap has an incredible ability to remotley identify almost any internet connected computer. Note: You must be root to use this feature. Note: Usually, nmap must know about 1 open and 1 closed port, although there are exceptions. -I This option is designed to find out who "owns" the process that is listening on the open ports you've found. Many default unix installations actually come with an ident daemon running (port 113), so this option can be quite useful. Keep in mind, though, it is trivial to write an ident daemon that responds with any user for any process. Never fully rely on this scan. -g This switch is an interesting one, and is rarely given the credit it deserves. If the target only responds to packets from a certain source port, this switch can help get your scan through, or if a firewall is doing something crazy, like only letting in port 53 as the source port. This is common on many poorly configured firewalls hiding a DNS server, I'm told. (Ideally, it would look at the IP too, not just the source port). As with any cool option, this switch requires root privileges. -S and -e These 2 switches are most commonly used when nmap, for whatever reason, can't detect which IP or interface to use for the port scan. nmap will tell you when you need to use these. The nmap man page raises an interesting point about using the -S switch (probably in parallel with the -e switch) to fake the scan as coming from a certain IP. You won't, of course, be able to see the results of this scan. Also, keep in mind, most properly configured routers at your ISP won't let these packets through if they come from a suspicious IP. See the man page for details. -f Basically, what this switch does is split the IP header over several different fragments so that many firewalls will let pass these otherwise filterable packets. See the man page for details. -D [,decoy2,decoy3,ME,decoy4...] This feature will let you fake scans from different IP addresses, so that the target won't know for sure who is scanning them. Make sure you include ME somewhere in the -D switch argument so that you recieve the results. Note that many ISPs won't send out packets with fishy source addresses on them. Also note that your decoys should be hosts that are up and running during the scan, or you may SYN flood your target. Conversly, if your goal IS to SYN flood the target, this would be an ideal way to do it. Consider this: nmap -sS -P0 -p 1- -D 1.2.3.4,2.3.4.5,3.4.5.6,4.5.6.7 victim.com Given none of the aforementioned IPs are actual hosts, the server's responses to the SYN packets (their SYN/ACK packets) will go unanswered. This will eat up connection queue space on the target for as long as their timeout value is, resulting in a SYN flood. -T This switch controls the speed that you want to portscan. Sometimes, spreading your port scan packets out will get by an IDS on the target system. Other times, you may just want to conserve (or saturate) network bandwidth. See the man page for details. -v and -d Verbose and debugging. It's often a good idea to use the -v switch, as you will often be able to determine more information about anything that went wrong. You can use as many -v switches as you like in the command, and each one cumulatively makes the output more and more verbose. This stops being effective after about 3 -v switches. -d is the debugging mode, and probably isn't necessary for everyday scans, but it helps untold amounts in the debugging process. -iR Picks random IP addresses to scan. nmap recently endured a massive overhaul to ensure that these random scans don't scan private (non-routable) networks, or government computers who probably won't take to kindly to your portscan. This switch is of limited usefulness, but may by valuable for statistical analysis or seeing how a outward-destined packet filtering firewall will filter a random array of IPs. -M This useful option allows you to specify how many sockets you would like to limit nmap to use for scanning. See, nmap will scan multiple ports at once, and for a normal -sT scan, it must go through the BSD sockets interface to use the network. Needless to say, any other type of scan (except possibly -sU) is unaffected by this switch, as it doesn't use the sockets interface at all: It just directly injects packets onto the network, bypassing the operating system altogether. This is why root is required. This switch is especially useful on BSD machines, I've noticed. Some of them (especially on older hardware) seem to jam up and lag a bit while preforming -sT scans, although I've never seen one crash before. Listen to the man page, though: Use -sS over -sT whenever possible. -o Generally, nmap will output its results in human readable form to stdout. Usually, when I want to save my logs, I'll do this: nmap -sS target.com | tee /home/doug/scans/target.com-sS This works just fine for me, but people seem to like using this switch to save output elsewhere. See the man page for details. One useful feature that I haven't experimented much with is the --resume switch that will let you resume a canceled nmap scan. Again, refer to the man page. Practical Scanning ------------------ Many novice scanners don't recognize the importance of cataloging your scans. If you simply port scan to standard output, and read the results, you will often forget your results and be forced to repreform the scan, which is not stealthy in the least. Create a directory for storing your scans, and name them appropriatley, with all the switches in the filename, so as to avoid any confusion. Always carefully consider what information you are actually after BEFORE you start scanning. Nothing will give you away faster than a bunch of blind, thoughtless scans. This is what most IDSs are designed to detect, afterall. For instance, if you want to find the operating system of a webserver NOT running SSL, use this scan: nmap -sS -P0 -O -p 80,443 www.target.com The logic behind this scan is left as an exercise to the reader. Always keep in mind that anything you do can, and often is, logged. The only real way to become an expert portscanner is practise, practise, and more practise. You'll see a lot of strange things if you scan enough computers, and often it is interesting and educational to discover the causes of these anomalies. Scan your own machines, scan your friends machines, and you will learn a lot about scanning and networking in general.