 Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3
 ·Shaw
| reply to Komputerguy
Re: UDP Port scans and you If it was my call, I'd suggest that the Linky be rude about UDP port scans and just not return anything (similar results to using the dummy IP address in the DMZ). This means to some scanners the Linksys would appear wide open at the UDP level, but as I mentioned UDP scans are not very common, practical or useful (to a point, open UDP ports can be bad, but finding them isn't exactly straight forward).
HOWEVER there is a downside to this which certainly doesn't apply to everyone, but certainly it applies to some of Linksys's customers. What happens to the guy who is trying to figure out how to setup NetMeeting or other software that uses UDP ports? Right now he might get a message from the software stating there is a connection problem because of the ICMP_PORT_UNREACH message returned from the router. If the message isn’t returned the software just might go stupid (because that’s the nature of UDP) and becomes a b*stard to figure out what is wrong. I’m sure we have all been there and were not overly fond of it either. Frankly I would have thought that Block WAN request would have killed the ICMP_PORT_UNREACH messages as well as ping replies etc. This way when someone is trying to install nasty UDP using software they could enable WAN requests to receive pings, ICMP_PORT_UNREACH messages etc and then setup whatever ports needed forwarding, triggered, or whatever and then Block WAN requests (if possible).
As Bill mentioned with all the flack that Linksys has taken over UDP scans I wonder also if they have changed something to suit customer expectations (wanting those ports closed, whatever). I’m also willing to bet that Linksys fears the support calls, etc they would see if they killed ICMP_PORT_UNREACH messages, as most people do not understand the nature of UDP scans. From their standpoint (and I tend to agree with them), if people really want to kill ICMP_PORT_UNREACH then let them do it themselves with a dummy IP address in the DMZ. I’m just a little concerned about the couple of reports of problems (hanging the Linky) with this approach. As I mentioned I don't use this approach, but that because I'm comfortable with how my Linky handles UDP scans, others may not be. Security is a personal thing, as it is your butt on the line. Do as you feel comfortable.
When hackers scan they might get your IP address from newsgroup postings, or whatever, but most of the time they are just scanning an IP block (don't want to scan dialup blocks, just those juicy 7x24 high speed blocks, or educational systems, etc) or randomly scanning (another reason to avoid using a UDP scan as there may or may not be a machine at the generated IP address, and that can mess up the time required and the results for a UDP scan). They also tend to target scan (pick a single port like a subseven scan which is a TCP scan), so they can scan more machines in less time, or spread the scan out over time as many IDS system will trigger alarms if they detect x ports scanned within some unit of time from a single IP. Most scans are TCP scans and there are a number of different TCP scans (vanilla, SYN (half open), FIN (stealth), ftp proxy (bounce attack), SYN/FIN using IP fragments, etc).
Some hackers don’t even bother with scanning; they go right for the attack. When I ran a Windows honey pot I was surprised how many hackers went straight for the juggler (netshare connection with the C drive). They didn’t bother scanning for open shares, or which shares were open, they went straight for the C drive and if it wasn’t available they moved on, even through other shares might have been available (I don't see many of these anymore, but I did see one a couple of days ago).
As I mentioned to someone else, think of a NAT as a door with a handle on only the inside. Unless something opens the door from the inside, nothing from the outside is getting in (we hope Linksys!). Port scanning is like someone knocking on the door. The best thing to do is to disguise the door to look like its part of the wall and not answer and hopefully they'll go away or not bother knocking at all, or at least that's the plan. The hacker's plan is to find systems that are easily compromised, which means if they do the special knock (ie TCP port 27374) and no one answers, then it’s simply on to the next machine. The more systems processed the higher the chances of success, so waste as little time as possible (and of course cover their tracks as best as possible).
Want to learn some more about scanning, look into nmap. The tool of choice of security professional and hackers alike, BUT remember scanning is most likely in violation of your ISP's AUP (Acceptable Use Policy), and you can lose your account for scanning (some places its against the law so you can go to jail as well), so read about it but don't do it OK.
Blake |
| This is been a very interesting and useful discussion. Thanks for this information and thought provoking points.
A slight tangent I would like to take...
One thing that I am wondering about is if there is any reason that SPI can't be used concurrently with DMZ? I suspect that there is no reason it can't. Or would this largely be irrelevant and/or redundant? I think I could see cases where you would want both operating. I have not come across a firmware version yet from Linksys that allows this. As soon as SPI is turned on, DMZ seems to get disabled - at least as far as "revealing" UDP ports. To me it is a bit confusing if you had to choose between the two which one would provide better security.
Thanks
--
What can possibly go wrong? |
