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

reply to Link Logger

Re: UDP Port scans and you

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

1. To a TCP scan the Linky returns nothing (you can stealth a TCP port, ie returning nothing). 2. The Linksys techies have promised a posting concerning SPI so I will leave it to them. It meant to validate which side of the Router traffic its found own, with the direction it claims to be traveling. 3. Was he connected to you (IRC) during the scan in which case he might have scanned the port you were already using for IRC? Stealth packets make no difference to the Linky. And again what were the ports he was claiming were open (UDP for example, as that was the reason for the original post).

Blake

Here is our conversation (excuse the "very casual" jargon), with our IRC nicks taken out , of course Notice the PORT names he got from the Linky?? What is that about?

***IRC scan by friend (very good scriptor)**************

me: can you scan me for trojans?
him: sure
me: I scanned myself, and was clean
him: well
me: but when this damn program joined warez-central
him: that doesnt mean you are
him: let me nmap you
me: someone said I tried to send them something
him: ah
him: thats not good
me: yes, but it is a trick
me: like yesterday, so that you go download their program
me: from some no name site
me: with no description
me: that I believe is a trojan
him: you g ot a firewall u p?
me: yes
me: hardware firewall
me: spammers have new trick
me: they tell people they are infected, and need to get clean
him: nothings getting past your firewall
him: damn
me: then ppl go download
me: some cleaner program
me: from some unknown site
me: and put trojan ON their PC!
him: im trying to trick your firewall
him: lol
him: damn
him: thats not good
me: hey
me: firewall working good?
him: huh
him: LOL
me: I scanned my system with this
him: yes
him: so far
him: I'm trying to make it think something e lse
him: hold on
me: »www.agnitum.com/products/tauscan/
me: the guys on DSLR said to use that
me: it is true trojan scanning program
me: took 1hr
me: took 30 minutes
him: its sending me a SO_ERROR
him: for my little trick :/
him: hmmm
me: but scanned entire PC, I was clean
him: good
me: I think spammers trying to trick me
me: into downloading their trojan
me: hey, what you doing now?
me: my modem blinking?
him: im trying to trick your firewall
him: so I can run a scan
him: im sending stealth packets to get through
him: it might work
him: hold on
him: it wont hurt you
him: im just seeing if i can do it
me: don't send me anything bad
me: you packeting?
him: i wont
him: no
him: no no
him: i wouldnt do that to ya
him: damnit the scan is bailing
him: you got a good firewall
me: (you said) its sending me a SO_ERROR
him: hehe
me: that is good right?
him: yeah
him: its good
me: ok
him: i tried tricking it
him: thinking it was coming from localhost
me: ok, that's good
me: I feel better now
him: and it gave an error
him: it usually works
him: woops
him: i g ot through
him: somewhat :/
him: your running an ftp arent you
me: no
me: serv-u is down
him: but people cant connect
him: heh
him: hrm
me: that is because I do have ports open
me: but the firewall won't let in
him: it shows the port open but closed from the public
me: if serv-u closed
me: yah
me: lol
me: I told router to allow "few" ports open
him: rmonitor_secure
him: whas that
me: but only if I allow (serv-u or dcc)
him: hacl
him: mmcc
him: cfengine
him: weird
me: what? the program?
him: pcduo
him: lol
him: you got weird stuff open
him: but your firewall makes you safe
me: what is that stuff?
him: just ports
me: uh, maybe port names?
me: linky maybe did that?
me: obviously, some ports open
me: to be on IRC )
him: well
him: port names
him: yeah
me: kew
me: kewl
me: congrats on your new software!
him: lol
him: huh
me: the new release
him: ohh
me: new release/update
him: thanks =]
me: ;p
me: so, whats up?
him: nothing much
him: tryin to get my page up
me: heh
him: hehe
me: this is the trojan scan program I was told to use, might want to keep the link
me: »www.agnitum.com/products/tauscan/
him: alright
him: thanks
me: k
me: aight
[text was edited by author 2001-06-24 10:36:08]

Gee, can I bet what DCC ports you have forwarded?

hacl-hb 5300/tcp # HA cluster heartbeat
hacl-hb 5300/udp # HA cluster heartbeat
hacl-gs 5301/tcp # HA cluster general services
hacl-gs 5301/udp # HA cluster general services
hacl-cfg 5302/tcp # HA cluster configuration
hacl-cfg 5302/udp # HA cluster configuration
hacl-probe 5303/tcp # HA cluster probing
hacl-probe 5303/udp # HA cluster probing
hacl-local 5304/tcp # HA Cluster Commands
hacl-local 5304/udp
hacl-test 5305/tcp # HA Cluster Test
hacl-test 5305/udp
cfengine 5308/tcp CFengine
cfengine 5308/udp CFengine
mmcc 5050/tcp multimedia conference control tool
mmcc 5050/udp multimedia conference control tool

Does this mean they were all detectable due to being on IRC or because they are forwarded on Linky? Second, are those names (hacl, cfengine, etc) assigned to the port by Linky? or mIRC?

English please? I left my WonderWoman Decoder Ring at home today

Dee

said by deecadams:

---

Does this mean they were all detectable due to being on IRC or because they are forwarded on Linky?

---

said by deecadams:

---

Second, are those names (hacl, cfengine, etc) assigned to the port by Linky? or mIRC?

---

Bill...yes, kind of

Yes, I have a "particular range" forwarded for DCC receives/sends on IRC I assume that is why they were exposed, but the Linky still told my scanner they were, "open, but not available to the public", which was fine with me

Second, I don't know how he knew their names, but I"m sure he has all those special hacker/scriptor tools that many guys do on IRC

thanks,

Dee

Gee, Dee. If I exposed something you don't want public I'll be happy to edit mine if you'll edit yours (oh my... it's that picture....)

Your hacker friend has a tool that only finds a port by number... he scans them all and finds, say, a "closed" reply on port 5300. His tools has some list that tells him:

hacl-hb 5300/tcp # HA cluster heartbeat

Someone, somewhere in the world (I bet this one is Cisco) used port 5300 to monitor the heartbeat of a High-Availability Cluster and labeled it "hacl-hb". It means nothing to your computer, you just used the same port # for something else - with me?

Bill

Yup , thanks. ...And now you are under hypnosis of my avatar, "Send deecadams all your money , now....all of it, sell your house".....

"(oh my... it's that picture....)------really funny

Dee