Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 25 replies
  • Subscribers 2 subscribers
  • Views 9147 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unknown Outbound Traffic (revisited)

Jim Tagert
https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32198

Lets try this again...

I am curious about the traffic from IP addresses:
128.242.114.242 (rdns mail2.after.college.com) at NTT America.
218.213.238.228 (no rdns) at HKNET-Hong Kong.
213.198.65.27 (rdns euu0300091-pip.eu.verio.net) NTT/Verio Europe.
69.10.147.66 (rdns unknown.rackforce.com) at RackForce Hosting.

Specifically regarding src port 2080.

src port is always 2080
dst port varies (30000-59999)
all traffic is tcp
The only proxys involved are on/in the ASG box. If any other proxies outside my modem exist I would like to know.

Since from what I have observed, up2date appears to use only ports 443 and 80. Because of this belief, the traffic described herein appears odd to me. 

Does up2date also require port 2080 to function correctly or close a connection? The packet data captured in front of the ASG indicates that the connection is trying to close and is retransmitting. These retransmissions are what the ASG's packet capture feature is logging. I do not know what the standard is for making sure a port is closed, but since the traffic is tcp and not udp I do not believe that 24 packets are required to close a connection. Which is what the ASG logged this morning from 09:38 to 10:00 GMT from IP 128.242.114.242 to two different dst ports (48775 and 37739). Am I wrong about anything I have stated?

Note: I have port 2080 blocked in the packet filter rules (along with many other ports). 

This traffic causes me some anxiety since I do not know the purpose of the traffic's original cause.

Will someone please explain this traffic?

Note: All my log data is sent to both Mynetwatchman and Dshield.

out.


This thread was automatically locked due to age.
  • 0 in reply to andreas
    Yes. 443 is used for authentication, 80 is used for download.

    You don't need to unblock port 2080. The fact that you are seeing packets coming from that port is a malfunction on our side. TCP check/retransmission mechanisms will take care of this, so you don't need to do anything.

    Cheers,
     andreas


    I looks as if the problem has been resolved. At least from the one server that I have watched. I guess it is the closest/fastest ping time. I could probably block that server and test the others but I feel terrible today.  After action was taken, assuming you actually found something, I received a few packets in error, they were TCP "ACK" retransmissons from IPaddresses 213.198.65.27 from NTT/Verio Europe at 14:00:25 1-14-2009, 128.121.46.239 from NTT America at 20:01:05 1-13-2009, and the very last packet was an "ACK" (not retransmission) from IP 69.10.147.66 from the nice folks at Rackspace Canada at 07:02:35 1-14-2009. Time zone is GMT/UTC -5.

    Since then, all is clear from port 2080.

    The only odd thing now appears to be a intermitent delay between the authentication and the actual check for new files/download.

    Was there anything about the problem that can share? I am just curious about what you/others found or did not find...

    Alot of other activity seemed to stop shortly there after I'm wondering if that is just a coinicidence???


    Thanks,

    Jim
  • 0 in reply to andreas
    Yes. 443 is used for authentication, 80 is used for download.

    You don't need to unblock port 2080. The fact that you are seeing packets coming from that port is a malfunction on our side. 

    Cheers,
     andreas


    I hate to be the bringer of bad news instead of gifts of alcohol and ribeye, but the malfunctions continue...

    The last on logged at 13:58 CST/DST today. There have been others.

    Would you like the server ip addresses?
  • 0 in reply to Jim Tagert
    I forwarded the issue to the developers who are handling kernel/netfilter problems, and they are trying to reproduce this in our testlab. We didn't change anything at the moment. Given the fact that this is difficult and risky to touch, paired with the relatively low impact of this problem, it will probably take a while until it is addressed. If you want to get rid of those stray packets in your log file you might want to consider dropping those packets without a log message, at least until this is finally resolved.

    Cheers,
     andreas
  • 0 in reply to andreas
    I forwarded the issue to the developers who are handling kernel/netfilter problems, and they are trying to reproduce this in our testlab. We didn't change anything at the moment...

    Cheers,
     andreas


    It appears that the NTT America servers are the habitual offenders. Maybe those servers are the heaviest loaded? Well, as I was writing this, the server at NTT/Verio Europe did its thing.

    It is very interesting that you said that not changes were implemented; but from my end, the frequency of events dropped dramatically until your latest post. I have observed three, oop four occurrences since noon today CST/DST.


    Jim

    NOTE: There is no substitute to watching the real-time activity in any troubleshooting endeavor. I can provide the data from my end if the engineers can capture the data from in front of the netfilter. That would at the least help with the problem...or not...
  • 0 in reply to Jim Tagert
    It is  necessary to compare traffic before and after the device, but since we can create dumps on both interfaces (incoming/outgoing) and the wrong packets match a strict and reliable pattern it should be no problem to get this data without bugging you any more. Thank you for the offer, your help is appreciated!

    Regards,
     andreas