How to defend Nmap

Tigershark, I agree with your methodology 100%. However In reccomending a tarpit I was just trying to be subjective to this thread. :) Now that I think about it, does'nt Cisco offer some type of protection against port scans? I forget the name of the feature but it basically causes the scans to be routed to a null address once it picks up that some distant IP is attempting to open connections to many ports in X amont of time.

Another great way to defend against Nmap scans is LIoIP (lethal injection over IP) ;)

Quote:

---

causes the scans to be routed to a null address once it picks up that some distant IP is attempting to open connections to many ports in X amont of time

---

While this seems like a good idea in theory, it is relatively easily exploited. If I scan your network and spoof the source address on those packets to appear as if they were coming from your webserver, your router would null route all webserver requests. The same could be done to a nameserver. Null routing is generally a very basic form of defense and very limited in its application. PortSentry has null routing capabilities if you want to experiment with them.

Besides, null routing, when used as a portscan defense, usually works by routing the replies, and not the scan itself. This is also easily exploited. All one needs to do is again, spoof the source address on the scan packets to appear as if they are coming from a critical upstream server, such as an ISP gateway or a web proxy. No internal hosts would be able to contact these servers after this attack.

Defending against portscans is far more difficult than would appear at first glance. A properly configured firewall should allow a portscan to detect only services which are publicly available, and as such, a port scan will not reveal any information not obtainable elsewhere, aside from possible OS fingerprinting and uptime discovery (which can also be screened). Preventing the leak of information which is already considered public is time and money better spent elsewhere.

On the other hand, I like to detect, prevent, and defend against portscans for the sheer science of it. The patch-o-matic tree has portscan detection capability which I use for this purpose, and redirect these packets to other targets to do my evil bidding. The tarpit target is quite fun, it does the same thing as LeBrea in that it stops RST packets from being sent to the attacker. My favorite, though, is the mirror target, which switches the source and destination addresses and retransmits the packet, so the attacker is in fact scanning him/herself. It's really rather entertaining.

Of course, the odd time or two, someone figures me out and uses my amusement park against me and I have to disable the portscan detection, firewall the attacker, or just let the scan run its course. But would methods like this be a good solution for a portscan defense? No. It's just too time consuming, and the information gained through a portscan isn't all that sensitive anyway.

Quote:

---

Originally posted here by Tiger Shark
No.... You'll see lots of ports "filtered". There's a firewall there but it will only allow access to the services my network _needs_ to function. So you will find several "open" ports, no closed ports and a gazillion "filtered" ports. Information gleaned:-

1. There is a firewall.
2. The network has probably been audited and checked for unecessary ports.
3. You may or may not have _accurate_ information regarding my services and OS's.... ;)

Outside that you know nothing more. You sure don't know for sure that I have already begun tracking your activity in voluminous logs, but I have..... :D

---

you must have a lot of free time on your hands. the luxury to track any dip$hit who happens to stumble into you your network boundres with OSS scanning tools. must be nice.

we do the absolute opposite of what you do. not stealth bullcrap. it is very plainly advertized that the area is a secure environment so keep moving. last thing we need is someone snooping around the network who shouldn't be there.

Quote:

---

you must have a lot of free time on your hands. the luxury to track any dip$hit who happens to stumble into you your network boundres with OSS scanning tools. must be nice.

---

Not really, when I get to work my scripts have pulled out all the "interesting" stuff from the logs so all I have to do it glance through them to see if there is anything of real interest. If there is I take a look to see if the logged activities indicate that there is actually a brain on the other end as opposed to a skiddie. If there is I use some other systems to get about the same information about the attacker as he now has about me and decide what to do. I spend maybe 30 minutes a day on it now..... :D

Quote:

---

Originally posted here by Tiger Shark
Not really, when I get to work my scripts have pulled out all the "interesting" stuff from the logs so all I have to do it glance through them to see if there is anything of real interest. If there is I take a look to see if the logged activities indicate that there is actually a brain on the other end as opposed to a skiddie. If there is I use some other systems to get about the same information about the attacker as he now has about me and decide what to do. I spend maybe 30 minutes a day on it now..... :D

---

in order for that to work you MUST have a very VERY acurate baseline. how good is your "what is normal" vs "what is abnormal" activity? how do you intelligently and efficiently handle updates and changes to "what is normal"? if you were to do that in my environment I would have peers audit your methodology on a regular basis.

but thats not what this is about. what this is about is following security as per security model established by people that have been doing it a lot longer and are more successfully at securty than InfoSec. Follow military and law enforement models.

If you are going to establist a very secure boundry - you pull out your 10 foot barbwire fences, your CCTV, your guards andn yourt gates. you establish a very strong and real psycological detterent. the intruder needs to be reminded at every step of the way "this is a bad idea!". "this is a mistake!". "turn back!" e.t.c.. no stealth. if you approach guantanamo bay - trust me, you will be*very aware* that you are approaching guantanamo bay and you won't ever forget it!

the difference being that if you act like an idiot at guantanamo bay, you will get your head shot off. but the perception is, if you act like an idiot online, nothing will happen. thats because there are no percieved real work repercussions to the action. you need to establish a real world repercussion. fines. cancelation of service. litigation. baseball bat to the head. whatever you can get away with.

;-)

Quote:

---

the difference being that if you act like an idiot at guantanamo bay, you will get your head shot off. but the perception is, if you act like an idiot online, nothing will happen. thats because there are no percieved real work repercussions to the action. you need to establish a real world repercussion. fines. cancelation of service. litigation. baseball bat to the head. whatever you can get away with.

---

That's illogical Captain......

If I am still determined to enter Gitmo unharmed I _will_ find a way to do it regardless of the "signs"....

When I was being trained I was required to take and pass the same tests snipers take for their concealment and approach to their chosen firing point. The most memorable phrase in the entire course was "Take any risks you need to take early in your approach", (ie: when the enemy is furthest away and least likely to detect you). The principle is valid in many situations including this one. If you have your "signs" up clearly for everyone to see from a distance you only make the attacker take his "risks" even earlier and you may not detect his activity. By removing your "signs" you leave the attacker with no definitive point at which early becomes too late - similar to the enemy having a well concealed observation post, (OP), 1000m in front of their positions. At that point the risk I take thinking I am 2000m from my enemy is more likely to compromise me because I am, in fact, only 1000m from my enemy. Now my approach is compromised I risk "death" from an unseen and undetected location where I _thought_ I was still safe. If the idiot, (Read: Skiddie), comes blundering on in who cares.... I know he's there and, by his blundering, I will know that he probably lacks the skills to work around the problems he is yet to face. Thus he is not a significant threat. The significant threat is the attacker that wants "in" and has the skills to work around those issues and, worse yet, has the skills to do it largely undetected. He's the one I want taking his risks late, too late hopefully.

In addition to that I also leave "tripwires" should he make it inside by some devious means. For example I might allow Telnet from any computer in the network to any computer in the world because I know my users don't have the level of sophistication required to initiate and use a Telnet connection. So if I see a Telnet connection going outbound I know I need to investigate... But I will do it quietly so if it is an attacker rather than a false positive then I can observe him and determine an appropriate course of action - which might, indeed, include the dextrous use of a baseball bat.

As to consequences in the digital world.... For all intents and purposes there are none. You can whine all you like to that Chinese ISP and, if they can even read your complaint, they don't give a rats ass about your predicament. Add to that the fact that unless you are dealing with _the_ most incompetent skiddie on the planet you are complaining to the wrong ISP because you aren't being attacked from the attackers home PC but rather from one of his pwned boxen you are further wasting your time. All your "signs" and "large men with big sticks" mean nothing because the attacker, for the most part, is risking nothing.

Thus you adapt your defenses to suit the landscape. Since the landscape is the digital world where information is the key then your defenses must gather information yet not reveal any to the enemy, hence my philosophy:

Look like a network that had a contractor come in and set it up but has now left and that monitoring etc. is something that went away with them too.

This way they take their risk at 2000m when I have my OP's 1500m in front of my lines.... Now they are right under my nose and they don't know it.... :D

tiger shark ... maybe i'm waaaaay off, but bear w/ me

are you saying that you have certain ports on the "intended" target nonexistant/closed but they appear to be configured BUT filtered because you have set it like that at the firewall? right???

why don't you also make sure that the system won't convey any info which will indicate that the IP is indeed alive and in use. that way you can be a complete ghost. at that point you know that the attacker:

1. is either random BUT has the capability to discover you even though you are stealth
2. knows you you exist from a IP left on a board or IRC etc.

also ... i think that the issue here is who has lower chance of becoming a target ... one way or the other you aren't more/less secure.

Quote:

---

are you saying that you have certain ports on the "intended" target nonexistant/closed but they appear to be configured BUT filtered because you have set it like that at the firewall? right???

---

No, I'm saying I have perfectly viable servers providing public services that are firewalled. There is no such thing as non-existent ports - if there is a computer there then there are 65,355 ports there, period... See this for my feelings/thoughts on "filtered".

Quote:

---

why don't you also make sure that the system won't convey any info which will indicate that the IP is indeed alive and in use. that way you can be a complete ghost. at that point you know that the attacker:

---

These are publicly accessible servers. The provide email, DNS, Web etc. thus they have to respond on certain ports and the firewall has to allow the traffic to those ports that provide service. The "filtered" ports are the ones that the firewall has been told to protect. Internally they might or might not be open but it makes no difference - the attacker can't tell nor get to them directly.

Quote:

---

also ... i think that the issue here is who has lower chance of becoming a target ... one way or the other you aren't more/less secure.

---

No, wrong. It's not about the probability of becoming a target it's about getting the maximum amount of early warning _when_ you become a target.

Hope that helps.

you might not have the same configuration as i am imagining. what i ment was. if you have a firewall in front of the server and that firewall is dropping data for FTP that doesn't mean that you even have FTP configured on your server. attacker may then assume that FTP is filtered, yet its' non existent. ...talking about banging your head on the wall.

although, you need to have publicly accessible services the system should not respond to ping sweepers and such. yes, i know there are other ways to make sure that IP is ready to dance but you at least eliminate the drive-by's

Here is my opinion:

Port scans cannot be entirely stopped. The idea should be to minimize the information leak and to make it as difficult as possible for an experienced hacker to obtain any information. This way you can stop a little script kiddies that don't know what they are doing, and maybe deter an experienced hacker from getting the information he wants by making it difficult/time consuming. Anyways, you have your basic TCP connection scans, which are easily logged so i wont mention them. You have your Stealth (sorry to use the word stealth TS) SYN scans, and then you have the nonsensical packet scans (FIN, X-mas, NULL).

Anyways, stleath syn scan does the whole half open thing. Send a SYN to the server, if it responds with a SYN/ACK the port is open, finally send a RST to avoid a SYN flood. FIN, XMAS, and NULL use those odd TCP flags set. Listening ports drop the packet, closed ports respond with a RST (RFC 793 or something i think).

Alright, first you can hide from a FIN, X-mas, and NULL scan by a really simple kernel modification. In the kernel there is a function resonsible for sending RST packets. You can throw in a return statement before the function actually sends the RST packet. This causes the kernel NOT to send any RST packets, effectively hiding from the FIN, X-mas, and NULL scans. See the code below:


/usr/src/linux/net/ipv4/tcp_ipv4.c

.....
.....
.....
static void tcp_v4_send_reset(struct sk_buff *skb)
{
struct tcphdr *th = skb->h.th;
struct tcphdr rth;
struct ip_reply_arg arg;

/* Never send a reset in response to a reset. */
if(the->rst)
return;
....
....
....


Throw in a return statement right after the struct declarations and this send reset function will return without sending a reset packet. Now when a FIN, X-mas, or NULL scan is conducted, NO ports will show up as open because none of the ports (open or closed) returned with a reset packet.

That is a possible solution for FIN, X-mas, and NULL scans. Now let's look at the stealth SYN scans. The SS scan gets its information by determining which ports respond with a SYN/ACK. If we can inject a SYN/ACK packet destined for the host that sent the SYN (with correct syn/ack numbers), we can fake a closed port as open. This script uses TCPDUMP and NEMESIS to inject a SYN/ACK packet destined for the host that sent the SYN packet to the closed port. Since certain ports are actually open, the script must disregard packets destined for ports that are open. Check it out:


#!/bin/sh
HOST="192.168.1.1"
/usr/sbin/tcpdump -e -S -n -p -l "(tcp[13] == 2) and (dst host $HOST) and !(dst port 22)" | /bin/awk '{

CONVFMT="%u%; # unsigned output numbers
srand(); #seeds the randomizer

#parse the tcpdump info for packet information
dst_mac = $2;
src_mac = $3;
split($6, dst, ".");
split($8, src, ".");
src_ip = src[1]"."src[2]"."src[3]"."src[4];
dst_ip = dst[1]"."dst[2]"."dst[3]"."dst[4];
src_port = substr(src[5], 1, length(src[5])-1);
dst_port = dst[5];

#new ack number is seq number + 1
ack_num = substr($10,1,index($10,":")-1)+1;
#generate random seq number
seq_num = rand() * 4294967296

exec_string = "nemesis tcp -v -fS -fA -S "src_ip" -x "src_port" -H "src_mac" -D "dst_ip" -y "dst_port" -M "dst_mac" -s "seq_num" -a "ack_num"";

system(exec_string);
}'


mouthful. Basically this script looks for a SYN packet to a closed port (any port other than 22 assuming that SSH is the only service running. Add more 'and !(dst port XXXX)' lines for more open ports). When a SYN packet is discovered to a closed port by tcpdump, the necessary information is stripped from the tcpdump output and fed into nemesis, which injects a SYN/ACK packet back the host. This makes it appear as if the port is open. When a stealth syn scan is run, it will look as if EVERY single port is open. This masks the only open port (SSH/22) in a crapload of false positives. If someone really wants the info, they could telnet to each port and check the banners, however you could modify this script to send false banners.

Nevertheless, these are some examples of methods to try to avoid/minimize port scans and the information they can uncover. Play around with this as you like.


****The script from this post came from the text HACKING: The Art of Exploitation. ****
^^ Just giving credit where it is due..