Printable View
Hi,
I know that Nmap is a scan software. It is useful for administrators to monitor networks. But on the other side, for an intrunder can also uses this software to scan my network and servers. How to defend this on network devices, include routers and switches.
The best to defend against it (in the way you described) would be to have a hardware firewall between your internet connection and your routers/switches/computers. Ideally, the firewall would not respond at all to the scans so that the attacker would have no clue that your computer was there.
- Xierox
The information you are looking for simply cannot be answered in a single post, or a single thread. People spend entire careers learning what you are asking. There is no one simple method to defend agains a scan. You are also assuming that a scan is indeed a threat.
But to give you an idea of where to look, I would suggest reading up on common methods used in IDS systems and firewalls. Antionline has a number of excellent tutorials on IDS systems, packet sniffing and port scanning, and firewalls.
Once you have a better understanding of how nmap scanning works, you will have a better idea of how to defend against it
But, the short answer is that port scanning can be defended against with proper firewalls and IDS systems.
IMO the most relevant solution to your problem would be something called a tarpit.
In a nutshell:
Its software designed to keep port scanners 'tied up'. It accomplishes this by tricking the computer initiating the scan into thinking the TCP connection is open, when in reality, its only half open, and thus has to time out.
The name of hte software I'm refering to is <a href="http://www.hackbusters.net/">LaBrea</a>.
Once you get the theory down behind it, there are more than a few ways to implement it.
Hope this helps! :)
Jonesy: While the initiating computer might be dumb enough to be messed up by LaBrea it's operator, if he knows what he is doing, will certainly conclude that all is not well. The resulting information gleaned would be:-
"The admin of this network is, quite probably, security aware......."
That's a very useful piece of information to have at hand if you are trying to break in and thus, in some ways, you just helped the attacker. I am a big fan of "looking stupid", (please direct all comments to 127.0.0.1. Thank you ;)). If my network appears to be bristling with self defense mechanisms then the attacker automatically goes into "stealth mode" making my life more difficult. If he's allowed to scan for a while, then probe a bit without going to hardcore "steath" then he rings my alarm bells - but he doesn't know it. From that point on I have a much better chance of successfully preventing him from completing his attack.
Obviously you can't stop people port scanning your network. What you can do, is ensure that they don't find anything open that you are not officially aware of.
You can do this by having a proper management system for your firewall, i.e. All open ports / services are catalogued by your network administrator and their purpose is known.
When something isn't required any more, it can then be shut down at the network level.
Clearly allowing people detect open services which are designed to be open to the world anyway (for example, your mail server, web server, DNS etc), is not a security risk.
Having things open that you didn't intend to, IS.
Of course you can detect port scans using an IDS, but to be quite honest, there is very little point. Almost all of them are carried out by automated programs which have no "kiddie" holding the wheel (as you might other wise imagine, some teenager in a bedroom looking at nmap logs, but it's not true).
These automated programs are usually worms or other malware, and have no kiddie anywhere near them, in fact they're more likely to be controlled by some criminal gang looking for hosts exploit for use in DDoS, Phishing, etc. The scans will almost certainly be coming from already "owned" machines.
Slarty
/Tiger opens big can of worms
Quote:
I am a big fan of "looking stupid", (please direct all comments to 127.0.0.1. Thank you ). If my network appears to be bristling with self defense mechanisms then the attacker automatically goes into "stealth mode" making my life more difficult. If he's allowed to scan for a while, then probe a bit without going to hardcore "steath" then he rings my alarm bells - but he doesn't know it. From that point on I have a much better chance of successfully preventing him from completing his attack.
The approach of leaving one or two avenues of attack open should only be used in an environment that is ripe for attack - Financial institutions etc. I have three small networks, no ecommerce, voip or wireless. The only thing worth stealing here is bandwidth. Of course perimeter seeding is a concern; however, in the event of compromised router/switch, I'll still see the loss of bandwidth.
Er... I don't leave avenues open for attack.... But I don't make it obvious that I am watching either. All my monitoring systems are passive and "stealthed". You won't receive anything from my network that you wouldn't expect until I decide to show you that I'm there - then you'll really know it unless you are a dumbass - every alarm bell of yours should ring quite nicely and you'll know I have been and am watching your activity.
Slarty is bang on with this:-
Though I would add "and are absolutely necessary for the purpose of the network". That allows for honeypots for example in a research environment but not necessarily in a corporate environment.Quote:
What you can do, is ensure that they don't find anything open that you are not officially aware of.
Ok, I think I understand what you're saying. If I scan your network I'll see lot's lf well known ports [closed] and what not, instead of no ports at all?
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
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) ;)
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.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
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.
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.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
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.
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..... :DQuote:
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.
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.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
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.
;-)
That's illogical Captain......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.
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.
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:
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???
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:
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:
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.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.
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..
To be quite honest, (and remain on the topic of "how to defend against scans"), there is no defense against many of the information gathering techniques because, in it's own way, no information is information in itself.
Example. Bill Nasty hates a co-worker and wants to hack into his home computer to get information. Joe Victim has a Linksys BEFSR41 router/firewall, (NAT), in front of his computer. Bill sends an email with an embedded link to his web server and waits for Joe to open it to find Joe's IP address. When it is opened Bill NMap's the reported IP address without even using OS guessing. He gets no response and NMAP indicates that all ports are filtered or that the computer is down. Bill knows it isn't down because Joe told him he leaves it on constantly. Reasonable conclusion: Bill can conclude that the computer is most probably behind a consumer grade router with no ports forwarded to the internal, and therefore, NAT'ed machine.
That's information... Turn on OS Guessing in later versions of NMap and it will include the LinkSys in it's short list guesses of the target machine..... But if Bill is reasonably knowledgeable he didn't really need the OS Guessing ability of NMap. He worked out the consumer grade router pretty much on his own.
If he was smart he would have fired up p0f when he sent the email and waited till he had the IP address of Joe. Then, by looking in the p0f log and matching the IP addresses he would see the operating system of Joe's computer behind the firewall..... Yes, he bypassed the protections that the firewall afforded Joe in protecting his OS type from outside snooping and now has a rather accurate idea of the internal OS right down to the SP level..... The fun thing is that p0f is undetectable.... I use it 24/7 for every incoming connection but you'll never know it's there, the NIC won't respond to any stimulus unless you are on the same subnet.
[EDIT]
Nice post Frosted:
I don't mind the use of the word "stealth" when it is used appropriately. In the case of a stealth scan you are doing something "magical", (or, at least, you used to be), you were avoiding many logging systems, though this is no longer the case.Quote:
sorry to use the word stealth TS
As to the effectiveness of NMap Fin, Xmas etc. scans Snort alerts on them very nicely... ;)
[/EDIT]
[Bookmark for later fun and tweakage]
Why not just go download a Port Scanner detector like Genius?
You can't defend against a Port Scan itself, really, but you can tell when someone does one and you can put up things so the ports aren't open.
Snort's portscan preprocessor works just fine.... Why add a level of complexity and therefore add resource use for no reason?
If he's a Windows guy and doesn't like configuring Unix tools this is easier.
*COUGH*
I'm a "Windows guy" and it's a piece of cake...... In Windows.....
Why add the complexity?
Dude, I'm trying to be helpful, if he doesn't feel like running Snort, I made it so he knows there is another.
alright, i think we pretty much summed up how to "defend" against port scans. There are many many different solutions. You should look at your network, the time/resources you have to defend port scans, and the cost benefits of protection. If you analyze and take some of these things into account, you should be able to come up with an appropriate solution for your needs. Just remember, good hackers always find a way, so don't start thinking once you implement a "solution" that you are now safe. I'm done..