Equipment Support > Hardware By Brand > Linksys > UDP Port scans and you

UDP Port scans and you

said by Link Logger:

---

... Of course this raises the question as to what a Stealthed UDP port is. Either you get a ICMP_PORT_UNREACH back or you don't, its either open or closed, so what’s a stealthed UDP port (returns a FOAD message maybe)?? Remember getting nothing back on a UDP scan assumes Open.

---

Follow-up Question:

Is the probe of a true "unassigned" (non-existent/off) IP the same or different than a dummy DMZ Host?

reply to ashbestush
Concerning placing a dummy IP address in the DMZ. I don't think this is bad and suggest people try it if they want. I'm just saying how UDP port scans work so when people say they can't get 'stealthed' on their UDP scans, this could be the reason. It should also be mentioned that hackers scanning UDP ports is somewhat uncommon because of the problems mentioned. Note I said 'somewhat uncommon' and not 'never' as sometime they do scan for UDP ports (Solaris rcpbind hole would be an example of a possible UDP scan. Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn't matter that 111 is blocked by the firewall, as you can you find which of the more than 30,000 high ports it is listening on with a UDP scan. While this would be a painful scan, it is possible).

Myself I don't use the DMZ trick, but security levels are something you must feel comfortable with yourself.

Sorry about the URL link, as its a habit of mine to enclose things in parentheses. Hopefully you were able to find the Link Logger web site, if you were interested.

Blake

Hi Blake. I'm glad you brought up the backwards nature of UDP vs. TCP. I got whacked on this one when this difference completely got me off track when a site (I forget which one) called UDP ports "Open" and I'm thinking the TCP sense all the way.

"Open" was exactly what I wanted. That is, emulating no host is present (same as ashbestush's "unassigned").

I'm just repeating what you've said but it can't be emphasized enough. I wonder... if LinkSys changed the UDP behavior because of the way security sites label the behavior?

reply to Link Logger
Thanks, Blake, for the excellent explanation of an obscure topic.

I could use a little more elaboration on one point: does the LinkSys normally return an ICMP_PORT_UNREACH when scanned, or does it just not say anything?

I'm wondering how the DSLReports scan concludes that UDP ports are closed and not missing, and I assume it's because of the ICMP error returns.

I don't use a bogus DMZ address here simply because I don't want port scans and other extraneous traffic on the LAN, even if it's addressed to a dummy address. Better to keep it off the network than to have every ethernet device read each packet and see that the dummy address isn't theirs. But I suspect there's of room for controversy there.

reply to Link Logger
Useful summary. Thanks.
--
dave

reply to Mwewe

Re: UDP Port scans and you

said by Link Logger:

---

For some reason it is considered polite to return an ICMP_PORT_UNREACH message if the port is closed and your Linksys Router would be the one sending it back (if you not doing the DMZ thing). Keeps networks from beating their heads against the wall I guess.

Lets talk about some differences in scanners. Some scanners require your system to reply to a ping (indicates that the system being scanned is really there), some don't (maybe its scanning a real system maybe its not, but it just goes for it anyways). This always makes me wonder how smart online scanners are. The fact that something connected to the web site and requested the scan, means it has an IP address and therefore (??) assumes that the system does exist. Is this what they mean by stealthed? The system exists (I sent a UDP port scan to it and got nothing back)? But this could also indicate that the port is really open (remember nothing back indicates possible open for a UDP scan, or maybe your ISP filtered it, whatever). Or do they say Sleathed is the correct response (got back a ICMP_PORT_UNREACH message) for a closed port. UDP ports are either open or closed and closed means closed, your not getting in. Open could mean there is nothing there, or maybe there is something just waiting to be exploited. This is one reason why UDP scans are not commonly used by hackers as its indeterminate at best.

I would tend to agree with you that I don’t want dummy IP traffic on my network behind the firewall. Good stuff on this side, junk other there thank you. To me the DMZ is a function with a purpose and this isn’t it, but it can still be used that way, if you wish. Like I said security is a personal matter, as it only matters to you in the long run and its your butt on the line, so do as you believe best.

Blake

---

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?

reply to Link Logger

said by Link Logger(Blake):

---

...If your ISP filters some UDP ports then the scanner will receive nothing back (as your ISP ate the port scan before it got to you, so your unable send anything back), so you don't send the ICMP_PORT_UNREACH back, and the scan reports these ports as open. NOTE some ISP filter UDP traffic on Netbios ports (137, 138, 139, such as some subnets of Mediaone/AT&T RoadRunner networks, my @Home network filters UDP traffic on port 31337 (as nothing good ever rode into town on that port, black orifice), but not on NetBios UDP ports).

When running a UDP scan you should know about what ports the ISP is filtering (if any), or run logging to see what ports are actually receiving traffic (of course I'm going to suggest Link Logger here), such that you can see which ports are open because the ISP ate the scan for that port (ie you don't see a log hit for that port).

Of course this raises the question as to what a Stealthed UDP port is. Either you get a ICMP_PORT_UNREACH back or you don't, its either open or closed, so what’s a stealthed UDP port ( returns a FOAD message maybe )?? Remember getting nothing back on a UDP scan assumes Open.

---

said by ashbestush:

---

One last question: What's FOAD in the snip above???

---

reply to ashbestush

said by ashbestush:

---

said by Link Logger(Blake):

---

...If your ISP filters some UDP ports then the scanner will receive nothing back (as your ISP ate the port scan before it got to you, so your unable send anything back), so you don't send the ICMP_PORT_UNREACH back, and the scan reports these ports as open. NOTE some ISP filter UDP traffic on Netbios ports (137, 138, 139, such as some subnets of Mediaone/AT&T RoadRunner networks, my @Home network filters UDP traffic on port 31337 (as nothing good ever rode into town on that port, black orifice), but not on NetBios UDP ports).

When running a UDP scan you should know about what ports the ISP is filtering (if any), or run logging to see what ports are actually receiving traffic (of course I'm going to suggest Link Logger here), such that you can see which ports are open because the ISP ate the scan for that port (ie you don't see a log hit for that port).

Of course this raises the question as to what a Stealthed UDP port is. Either you get a ICMP_PORT_UNREACH back or you don't, its either open or closed, so what’s a stealthed UDP port ( returns a FOAD message maybe )?? Remember getting nothing back on a UDP scan assumes Open.

---

Blake...

After rereading the above about 6 times, I finally got it!!!

---

[QUOTE=Komputerguy]

quote:

---

I just kind of got it too but need some clarification based in what I saw on my Linksys log. I saw a hit on every port for the Sygate UDP scan when I changed my configuration to SPI on and DMZ off. But it was not coming in to the IP of my PC behind the Linksys (192.168.1.xxx), it was going to the IP address that the WAN (RoadRunner) assigned to me (65.35.84.xxx). When I changed it back I saw a lot of stuff going into my DMZ black hole IP, but not quite as much since Sygate gives up with what it considers a blocking device on the UDP.

So my question is this... Does this mean that RoadRunner is fitering every UDP port that Sygate scans on? And therefore I can go ahead and turn the DMZ off and SPI on since if RoadRunner is filtering it, nothing is going to get to me on UDP anyway? I wouldn't be in any danger unless those UDP scans were getting to the IP of my PC, right? I appreciate any clarification on this.

Thanks

---

reply to Komputerguy
First a rule of thumb that should help here. Unsolicited inbound traffic is always directed at the IP address that your ISP assigned you, UNLESS it is for a forwarded, or triggered port, or you have a machine in the DMZ.

NAT stands for Network Address Translation, which means your Linky keeps a table as to where inbound traffic should be directed. If the inbound traffic is in response to an outbound connection (ie a table entry exists), then the traffic is directed back to the internal machine that made the connection. For example you see the outbound log message for your system to connect to DSLReports, and all the traffic the DSLReports sends back (using your ISP assigned IP address) is then translated by the linky to the IP address of the system your surfing DSLReports with. Since this connection is already made you do not get a log event for this. This also applies in the case of port forwarding. When inbound traffic arrives for some port, by having port forwarding setup, you are instructing your linky to translate all traffic arriving on this port to the IP you entered to forward to (since there is no connection, one is made and it appears in your logs as traffic going to the forwarded machine). The DMZ is just a bigger extension of this, where all unconnected traffic is translated to go the system you placed in the DMZ. So lets say you placed machine x.x.x.x in the DMZ and your ISP assigned IP address is y.y.y.y. Looking at the traffic immediately before your linky, the packets say, send to y.y.y.y and then in your linky, it looks at the packet and sees that its unconnected inbound traffic and translates y.y.y.y into x.x.x.x and passes it through to the DMZ system (and its logged as a connection to the system in the DMZ). If you don’t have DMZ enabled, then the packets just before your linky still say send to y.y.y.y but in your linky, if the traffic is unconnected inbound traffic, it doesn’t know where to forward the packets to and punts/blocks them (and logs it as a connection to your ISP IP address which really is the external IP address of your linky).

So again if the logged traffic (meaning as it appears in your logs) is addressed to your ISP assigned address, then it was blocked at the linky. If logged traffic is addressed to an internal IP, then it was either forwarded, Triggered, or sent there because DMZ was enabled. This is why Forwarding and DMZ (and to a much much lesser degree Triggering) can be dangerous as it in effect bypasses the security of a NAT. Also remember that SPI and DMZ are mutually exclusive in the current firmware versions and SPI rules. Meaning if SPI is enabled, it disables DMZ. Bill_MI had mentioned a reason why he thought there were some problems with Linkys hanging using the dummy IP address in the DMZ, and I’m betting he right on the money (the table is only so big and connection last x amount of time by default, so if you send lots of connections (for each IP, and for each Port a separate connection is created in the NAT table, then you over flow the table and crash the linky). I would think a hard reset should restore the Linky, unless the over flow trashes some code in memory (possible).

So RoadRunner is not filtering every port, the addresses are just being translated as per your configuration instructions. Are you seeing UDP traffic (a log entry) for all the ports Sygate scans? If so then they don’t filter any ports. The most UDP ports I’ve ever seen an ISP filter is three and those were the NetBIOS ports of 137, 138, and 139. Sometimes I think my local ISP is somewhat unique in filtering UDP port 31337.

Whew, this is more then I wanted to write here, but its still somewhat of a simplified view of what the linky does, but I hope it helps you understand what the the NAT does and how a couple of different features (forwarding, DMZ, logging, etc) work in your linky and how they would impact scans. As you can imagine setting up a dummy IP address in the DMZ tell the linky to forward all unconnected traffic to the bit bucket as there isn't a real machine there to return anything.

Maybe I should have put this in a new topic called NAT and you.

Blake

reply to CrazyM
I do see a difference in behavior and it looks like the Linksys settings affect it. Dummy DMZ on, the UDP probes go the the dummy DMZ IP. DMZ off, SPI on, the UDP probes go to the WAN IP. DMZ off, SPI off, the Sygate Scan never finishes. I am wondering why. I assume that the SPI on never allows the UDP packets pass into the LAN but somehow the WAN IP is responding in a way that makes Sygate think that the port is there (but closed). Curious.

If I have both SPI and DMZ on the behavior seems to be the same as if just SPI was on.
--

What can possibly go wrong?

reply to Link Logger

said by Link Logger:

---

The DMZ is just a bigger extension of this, where all unconnected traffic is translated to go the system you placed in the DMZ. So lets say you placed machine x.x.x.x in the DMZ and your ISP assigned IP address is y.y.y.y. Looking at the traffic immediately before your linky, the packets say, send to y.y.y.y and then in your linky, it looks at the packet and sees that its unconnected inbound traffic and translates y.y.y.y into x.x.x.x and passes it through to the DMZ system (and its logged as a connection to the system in the DMZ). If you don’t have DMZ enabled, then the packets just before your linky still say send to y.y.y.y but in your linky, if the traffic is unconnected inbound traffic, it doesn’t know where to forward the packets to and punts/blocks them (and logs it as a connection to your ISP IP address which really is the external IP address of your linky).

---

said by Link Logger:

---

Bill_MI had mentioned a reason why he thought there were some problems with Linkys hanging using the dummy IP address in the DMZ, and I’m betting he right on the money (the table is only so big and connection last x amount of time by default, so if you send lots of connections (for each IP, and for each Port a separate connection is created in the NAT table, then you over flow the table and crash the linky). I would think a hard reset should restore the Linky, unless the over flow trashes some code in memory (possible).

---

reply to Komputerguy

said by Komputerguy:

---

If I have both SPI and DMZ on the behavior seems to be the same as if just SPI was on.

---

Blake, I don't use DMZ, and left SPI at default, which I believe is "disabled" setting. Question, #1
What is the message the Linky gives to TCP or UDP scans? (Again, talking about "unsolicited traffic requests, of course)....

Thanks.....trying to figure out what the heck you guys are all saying ))) Q #2 Still don't know what the purpose of SPI is? But did read up on DMZ port, which seems dangerous to enable......

FYI: I had a friend scan me while on IRC.....and he said the Linky gave him some _SO_ERROR message back when he tried to get in (behind it), so then he tried to trick the Linky with "stealth" packets? (don't ask me, he was just telling me what he is doing next, lol), and that didn't work..... He was able to see, however, that I had open ports (should, on IRC, after all), but the Linky said something like, "ports open, but not available to public"...... Q #3 Sound right?

thanks in advance! This is some lesson! Linksys 101!!!!

Dee