Can anyone suggest what traffic coming in to port 53662 might be? It originates from a number of different IP addresses. My router firewall is set to stop anything not resulting from an outgoing request which leads me to believe it's the result of browsing the web but that traffic is being stopped by my internal (software) firewall which has taken exception to it. If I think that it could be harmless I'll let it pass but I don't want to do that at present as I've no idea what it might be. -- Barry Samuels http://www.beenthere-donethat.org.uk The Unofficial Guide to Great Britain
Hi, On 14 April 2010 18:49, Barry Samuels <bjsamuels@beenthere-donethat.org.uk> wrote:
Can anyone suggest what traffic coming in to port 53662 might be? It originates from a number of different IP addresses.
Can you run tcpdump and capture the packets? What protocol is it? Some references to that port from different sources are mentioned in some Snort mailing list threads that mention a possible NOP sled attack. Srdjan
On 14 April 2010 19:07, Srdjan Todorovic <todorovic.s@googlemail.com> wrote:
Some references to that port from different sources are mentioned in some Snort mailing list threads that mention a possible NOP sled attack.
A NOP sled can be on any port, or no port. Like Srdjan said, get a dump or find out what process has that port open (through netstat possibly?). Also what is the IP? Have you resolved it to see what it is? Who does it belong to? -- Regards, James. http://www.jamesbensley.co.cc/
On 14/04/10 20:12:48, James Bensley wrote:
On 14 April 2010 19:07, Srdjan Todorovic <todorovic.s@googlemail.com> wrote:
Some references to that port from different sources are mentioned in some Snort mailing list threads that mention a possible NOP sled attack.
A NOP sled can be on any port, or no port. Like Srdjan said, get a dump or find out what process has that port open (through netstat possibly?). Also what is the IP? Have you resolved it to see what it is? Who does it belong to?
-- Regards, James.
tcp 0 0 *:53662 *:* LISTEN 5127/skype That clears it up I think. It must be something new because I've been using Skype for a long time and this has not occurred before. So I think I can let it through. Thanks to eveyone for the prompts. I probably wouldn't have thought of trying tcpdump and netstat otherwise. -- Barry Samuels http://www.beenthere-donethat.org.uk The Unofficial Guide to Great Britain
On 14/04/10 19:07:37, Srdjan Todorovic wrote:
Hi,
On 14 April 2010 18:49, Barry Samuels <bjsamuels@beenthere-donethat.org.uk> wrote:
Can anyone suggest what traffic coming in to port 53662 might be? It originates from a number of different IP addresses.
Can you run tcpdump and capture the packets? What protocol is it?
Some references to that port from different sources are mentioned in some Snort mailing list threads that mention a possible NOP sled attack.
Srdjan
21:14:22.990731 IP dataman1.home.net.53662 > 229.185.249.62.customer.cdi.no.3625: UDP, length 33 21:14:22.990768 IP dataman1.home.net.53662 > c-71-192-110-50.hsd1.ma.comcast.net.16876: UDP, length 32 21:14:23.083431 IP 229.185.249.62.customer.cdi.no.3625 > dataman1.home.net.53662: UDP, length 18 21:14:23.135477 IP c-71-192-110-50.hsd1.ma.comcast.net.16876 > dataman1.home.net.53662: UDP, length 19 Those few lines make me think that my machine is sending out on that port first and getting a reply back on the same port later. Would that be a correct interpretation? -- Barry Samuels http://www.beenthere-donethat.org.uk The Unofficial Guide to Great Britain
Excuse my ignorance, but isn't 53622 the default port for bittorrent?
21:14:22.990731 IP dataman1.home.net.53662 > 229.185.249.62.customer.cdi.no.3625: UDP, length 33
21:14:22.990768 IP dataman1.home.net.53662 > c-71-192-110-50.hsd1.ma.comcast.net.16876: UDP, length 32
21:14:23.083431 IP 229.185.249.62.customer.cdi.no.3625 > dataman1.home.net.53662: UDP, length 18
21:14:23.135477 IP c-71-192-110-50.hsd1.ma.comcast.net.16876 > dataman1.home.net.53662: UDP, length 19
these all look like connections to residential broadband peeps.... so leads to the conclusion of bittorrent too do you know how much bandwidth it's creating? I concur with James, run netstat to see what's using the ports.. Hope you get it resolved
On 14 April 2010 21:40, Alex Scotton <alex.scotton@gmail.com> wrote:
Excuse my ignorance, but isn't 53622 the default port for bittorrent?
Google results for "53622 bittorrent port" return nothing of significance.
21:14:22.990731 IP dataman1.home.net.53662 > 229.185.249.62.customer.cdi.no.3625: UDP, length 33
21:14:22.990768 IP dataman1.home.net.53662 > c-71-192-110-50.hsd1.ma.comcast.net.16876: UDP, length 32
21:14:23.083431 IP 229.185.249.62.customer.cdi.no.3625 > dataman1.home.net.53662: UDP, length 18
21:14:23.135477 IP c-71-192-110-50.hsd1.ma.comcast.net.16876 > dataman1.home.net.53662: UDP, length 19
these all look like connections to residential broadband peeps.... so leads to the conclusion of bittorrent too
Or they could be zombie machines part of a botnet. Can you decode the data in the packets? (perhaps use -X option for tcpdump) Allegedly udp/tcp 3625 is "Volley", whatever that is. http://www.sharkyforums.com/showthread.php?t=214101 suggests you are not alone, though that's a very old thread. I think I might have hit one reference to Toredo (UDP tunnel broker) for one of the ports in your logs. Good luck. Srdjan
On 14 April 2010 23:15, Srdjan Todorovic <todorovic.s@googlemail.com> wrote:
21:14:22.990731 IP dataman1.home.net.53662 > 229.185.249.62.customer.cdi.no.3625: UDP, length 33
I think I might have hit one reference to Toredo (UDP tunnel broker) for one of the ports in your logs.
"The 53662 port was being used for Teredo tunneling when this scan was performed." www.symantec.com/avcenter/reference/ATR-VistaAttackSurface.pdf Not sure if that's relevant though. Srdjan
On 14-Apr-10 17:49:45, Barry Samuels wrote:
[...] My router firewall is set to stop anything not resulting from an outgoing request [...]
Interesting -- I hadn't heard of such a thing before (may well be a standard thing -- the fact that I don't know about it doesn't mean a thing). Anyway -- how can one go about setting up such a block? Does it depend on the router (even as to whether it's possible)? With thanks, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 14-Apr-10 Time: 22:49:28 ------------------------------ XFMail ------------------------------
On Wed, 14 Apr 2010, Ted.Harding@manchester.ac.uk wrote:
On 14-Apr-10 17:49:45, Barry Samuels wrote:
My router firewall is set to stop anything not resulting from an outgoing request [...]
Interesting -- I hadn't heard of such a thing before (may well be a standard thing -- the fact that I don't know about it doesn't mean a thing).
Anyway -- how can one go about setting up such a block? Does it depend on the router (even as to whether it's possible)?
If it's a Linux router, <http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-iptables-stronger> suggests a way to do something similar using the "--state ESTABLISHED,RELATED" option to iptables. -- Regards, Dan
You could use IPTABLES to just block the connections and see if anything stops working? Also; On 14 April 2010 22:49, Ted Harding <Ted.Harding@manchester.ac.uk> wrote:
On 14-Apr-10 17:49:45, Barry Samuels wrote:
[...] My router firewall is set to stop anything not resulting from an outgoing request [...]
Interesting -- I hadn't heard of such a thing before (may well be a standard thing -- the fact that I don't know about it doesn't mean a thing).
This is just the NAT/PAT aspect of the router. Unless specific inbound port/IP forwarding has been setup all incoming connections are dropping as they could be for any internal host within the LAN subnet so unless a connection has originated from the LAN side of the router to the WAN side (thusly making an entry in the NAT/PAT tables) and no port/ip/dmz forwarding is set up incoming connections are dropped. HTH. -- Regards, James. http://www.jamesbensley.co.cc/
participants (6)
-
Alex Scotton -
Barry Samuels -
Dan -
James Bensley -
Srdjan Todorovic -
Ted.Harding＠manchester.ac.uk