Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 25 replies
  • Subscribers 2 subscribers
  • Views 9120 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.
Parents
  • 0
    Aaahhhh, come on guys...

    Somebody take a shot at it...
  • 0 in reply to Jim Tagert
    Is it hitting you from the internet, or coming from your network?

    There are apparently some trojans which use 2080.

    Barry
  • 0 in reply to andreas
    Thank you.

    I was hoping that it was something like that and not rouge Astaro folks snooping. If the NSA can abuse their power and post your and my most intimate momnets on a big screen for their buddies to see anyone can abuse their access. I am glad that is not the case.

    Here is my orgininal question:

    http://www.astaro.org/astaro-gateway-products/management-networking-logging-reporting/21301-unknown-outbound-traffic.html

    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.


    Unanswered Questions:

    1) Am I correct about up2date only using port 443 and 80.

    2) Shoud I include port 2080 in my packetfilter rule for the up2date servers? Or do I leave the port blocked (two separate rules)? You did say that port 2080 should never have been seen at all? Yes, I think that is what you said (internal network only). Did you say that? So, I gues I should leave it blocked, right?

    Previously, I was asked if I used a proxy. The only proxy of which I know is the CMTS of my ISP. (and now Astaro's) I have had my suspicions since when my LAN was on a 10/8 net and so is their CMTS I had some major problems with unauthorized access. Just a hop across a router I thought...But that is another story. I now own the modem as well.

    3) Could a proxy cause a delay? Or has the actual problem been identified as problems with the Astaro proxy's SNAT... (not DNAT???)... since I received the "ACK"?

    If you would like, I can go all the way back to Jan 2008 and tell you all of the servers that have sent out the proxy port 2080 and the dates and times they did it. This is not an isolated incident it happens daily. I should have pursued this back on March 25th of 2008 when I first posted. I had my hands full then, sorry. My initial inclination says that having the proxy port on the internet is a bad thing. Is it? Does the ASG do it too?

    Thanks again for your time.

    Jim
  • 0 in reply to Jim Tagert

    1) Am I correct about up2date only using port 443 and 80. 

    Yes. 443 is used for authentication, 80 is used for download.

    2) Shoud I include port 2080 in my packetfilter rule for the up2date servers? Or do I leave the port blocked (two separate rules)? You did say that port 2080 should never have been seen at all? Yes, I think that is what you said (internal network only). Did you say that? So, I gues I should leave it blocked, right?

    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.


    3) Could a proxy cause a delay? Or has the actual problem been identified as problems with the Astaro proxy's SNAT... (not DNAT???)... since I received the "ACK"?

    First of all, we don't use the proxy functionality on the ASGs that shield the up2date servers. The ASGs are using DNAT to rewrite the destination of the initial connection. The source address in the reply packets for this connection is automatically rewritten by the netfilter. And yes, having a proxy port open to the internet is not a good idea. The ASG will not do this unless you configure it explicitly to do so.

    Cheers,
     andreas
  • 0 in reply to BarryG
    Hmm... something's definitely making a full connection.

    Where are you sniffing? on the firewall, or in the LAN, or outside the firewall?

    Are either of these IPs in your LAN/DMZ?
    128.121.10.114 
    24.243.46.239 

    If not, AND if you're sniffing your internet connection, then your ISP may have your router (or modem) misconfigured, letting you see other customer's connections.

    Barry


    I am cocerned about a CMTS misconfiguration or some sort of bleed-over hardware failure, and have been for some time. Except, it would be other folks seeing my connections. My ISP is less than helpful. As of yet, they have not written a readable script for someone to read to me from tech support. It appears that as long as I can connect and surf, then everything is A-OK. Tier three support is next to impossible to get transferred to now. A great new policy...

    I own my modem. From what I can see, config appears ok. However, my understanding may be lacking in what "normal" looks like.

    The original problem has been addressed.

    I appreciate everyone's time and effort.

    Jim
  • 0 in reply to Jim Tagert
    Hi Jim,
    I think it would have been a little less confusing to me if you had identified which IP was yours.
    Glad it's straightened out now.

    Barry
  • 0 in reply to BarryG
    Sorry.

    I thought everyone had a laminated list of Astaro server IP addresses hanging on a lanyard around their neck for reference.


    But Seriously, thanks for your help.


    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. 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
Reply
  • 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
Children
No Data