Traffic to ASG servers

It's probably the other way around... the "funny" ports, they are all above 1024, right?  It's the return traffic you are seeing from the Astaro up2date server(s)... the Astaro unit establishes a connection using a randomly selected port locally to the fixed port 80 (and probably 443 too) remotely...

Dear BrucekConvergent, 
Thanks for the reply. 

This is what my packet filter log show: 

11:47:54 Default DROP TCP 85.25.149.192 : 80 
 → 41.244.63.128 : 59456 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

11:47:54 Default DROP TCP 218.213.238.230 : 80 
 → 41.244.63.128 : 35322 
 [ACK PSH] len=265 ttl=62 tos=0x00 
 

I did forget to mention i also get a lot of traffic from 218.213.238.230 : 80 

1) Is this also an ASG update server? 

2) So i guess i should allow these 2 IPs via a packet filter rule? 

3) Why is there no trace of this traffic in the up2date logs? Or am i missing something....

2009:02:10-11:45:11 (none) auisys[6995]: id="3716" severity="info" sys="system" sub="up2date" name="Up2date Package Installer finished, exiting" 
2009:02:10-11:50:02 (none) audld[7171]: Starting Up2Date Package Downloader (Version 1.57) 
2009:02:10-11:50:16 (none) audld[7171]: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful" 


4) PLEASE how can i customise this - these update server IPs are causing 100's of Mbs of traffic per day!! (And it is not even downloading any firmwares...)

5) ASG ADMINS - would it not be possible to please create and maintain a list op ASG update server IPS so that we can know what is legitemate ASG traffic please? 


Thanking you in advance. 

All the very best,
kobie

Hi,
please check the following thread: https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32309
It explains where these packets come from and contains a list of Astaro up2date servers in use, as you requested. 

The default up2date check interval is 15 minutes. It is currently not possible to change it except for switching the automatic download off completely. You would still be able to update your machine manually by triggering it from the Webadmin.

Cheers,
 andreas

Hi Kobie,

I would be happy to discuss any unusual traffic that you believe might be from Astaro. 

I can also tell you that without a packet sniffer in front of the ASG, identification of traffic and intention of same is more difficult.

Have you observed the real-time logs found in "Logging"/"View Log Files"/"Up2date Messages". You can compare times with what you think you maybe seeing.

Also, if you are not familiar with how an enterprise level firewall works there may be some things that you do not as of yet understand.

Let me know if I can help.



Jim

Hi Kobie,

Oh, and you might want to modify how you think about the up2date servers. Identification can be confusing because they do not all respond to a RDNS lookup (using either the ip or hostname) as one might expect. Astaro uses DNS records to point you to the right IP. So you can make a rule in the "Packet Filter" area using the IP addresses of the servers if you want, but it is easier to make a Network Group then within the group, place DNS Host entries such as up2date01.astaro.com. Where 01 is change each entry to 02, 03, 04 and so on depending on what you read there are between 6 and 12 dns records out there. There appear to be twelve but some also appear to be repeats. Only allow services HTTP and HTTPS in the rule. Place the rule before (or above) any other HTTP or HTTPS rules so that the filter will be tweaked for the actual up2date servers. The rules are applied from top to bottom in your packet filter. It is imperative that you understand this and put the rules in the correct order.

This may help you understand:

up2date01.astaro.com is currently pointing at IP address 213.198.93.249. If you use the host name of up2date01.astaro.com when conducting a RDNS lookup, then you get nothing. You may start to think something is very wrong. However, If you already know that up2date01.astaro.com is currently pointing to IP address 213.198.93.249 and you use the IP address for the RDNS, then you get  euu0300091-sip.eu.verio.net. Still confusing, right? Because how does one know if euu0300091-sip.eu.verio.net is a good guy or a bad guy? We do know that euu0300091-sip.eu.verio.net does in fact resolve (RDNS) to 213.198.93.249. Now, if you have made the packet filter rule for astaro up2date servers as I have suggested, you can see that the ASG resolves the host name(s) to the IP address(es). To see this, go to the packet filter rule/group you created using the host names up2date01.astaro.com through up2date10.astaro.com, and hover the cursor above the host name, you will see the IP address (this may take a few minute after rules creation to resolve). You can see the up2date activity in real-time with the packet filter that you placed in front of the ASG.



Jim

Another thing,

If you still have reservations about the connections to the up2date servers, you can, after you create the packet filter rule as I suggested, set the rule to block/drop instead of allow. After you do this, open the "Live Log" of the "up2date messages" then observe the failures. You can only see the ip addresses involved when the connection fails. You will not see the ip address when the authentication to the up2date servers succeeds, only when the authentication fails.

This should help put your mind at ease about what traffic is good and help you isolate any traffic that might not be good.

Don't forget to change your up2date packet filter rule back to allow after your experiment is complete or you will not receive any updates.



Jim

Dear Andreas, 
Thank you for the reply. I will study the post you indicated in more detail. 

Dear Jim Tagert;
Thank you for the replies and assistance. Apologies for my late reply. 
I am sure there is a number of things i dont clearly understand on an enterprise level firewall - an i am very willing to learn [;)]

Perhaps i just miss it or dont know where to look but my up2ate log shows:
2009:03:03-21:34:17 (none) audld[5047]: |========================================================================= 
2009:03:03-21:34:17 (none) audld[5047]: http://213.198.93.249:80/asg/v7/auav/u2d-auav-7.890.tgz.gpg Server Error code=500 
2009:03:03-21:34:17 (none) audld[5047]: 
2009:03:03-21:34:17 (none) audld[5047]: 1. Modules::Getupdates::sync_local:1042() audld.pl 
2009:03:03-21:34:17 (none) audld[5047]: 2. main:[:D]ownload:651() audld.pl 
2009:03:03-21:34:17 (none) audld[5047]: 3. main::run:377() audld.pl 
2009:03:03-21:34:17 (none) audld[5047]: 4. main::top-level:33() audld.pl 


AND my packet filter log shows: 

21:34:05 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip : 52461 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

21:34:06 Default DROP UDP 192.168.1.10 : 1315 
 → 65.55.158.81 : 3544 
 len=105 ttl=127 tos=0x00 srcmac=00:01:29:50:34:17 dstmac=00:1e:58:45:3b:e7 
 

21:34:08 Default DROP UDP 192.168.1.10 : 1315 
 → 65.55.158.81 : 3544 
 len=105 ttl=127 tos=0x00 srcmac=00:01:29:50:34:17 dstmac=00:1e:58:45:3b:e7 
 

21:34:12 Default DROP UDP 192.168.1.10 : 1315 
 → 65.55.158.81 : 3544 
 len=105 ttl=127 tos=0x00 srcmac=00:01:29:50:34:17 dstmac=00:1e:58:45:3b:e7 
 

21:34:15 Default DROP UDP 192.168.1.10 : 1315 
 → 65.55.158.81 : 3544 
 len=105 ttl=127 tos=0x00 srcmac=00:01:29:50:34:17 dstmac=00:1e:58:45:3b:e7 
 

21:34:16 Default DROP TCP 218.213.238.230 : 80 
 → my.external.ip : 34446 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

21:34:31 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip : 52461 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

21:34:48 Default DROP TCP 218.213.238.230 : 80 
 → my.external.ip : 34446 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

21:34:57 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip : 52461 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 
192.168.1.10 is one of my internal machines on the network
218.213.238.230 - i think this may be from asg up2date servers? 


Packet filter rule for up2date servers.
Currently i have defined the following based on information from the up2date live logs. 
source: asg servers from up2date logs e.g. 128.121.10.115, 128.242.114.243, 213.144.15.5
service: http
destination: external (wan) (address)
action: allow

So if i understand correctly i can change the source section of my rule to up2date01.astaro.com to up2date12.astaro.com ??

I have changed the rule as explained above as per your recommendation and will test that and revert. 
Many thanks again. 

All the very best,
kobie

Dear Jim Tagert;
I have created a packet filter rule as explained above for up2date01.astaro.com to up2date12.astaro.com (noticed the host entries remained unresolved). 

I noticed traffic like this which seems to be up2date related (no trace of this in the up2date logs though...)

17:37:20 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip : 43575 
 [ACK PSH FIN] len=548 ttl=61 tos=0x00 
 

17:37:45 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip: 43575 
 [ACK RST] len=40 ttl=61 tos=0x00 
 

17:44:31 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip: 45061 
 [ACK PSH] len=265 ttl=62 tos=0x00 
 

17:44:31 Default DROP TCP 62.248.103.10 : 80 
 → my.external.ip: 45061 
 [ACK PSH] len=335 ttl=62 tos=0x00 
 
Is this still up2date traffic being blocked despite the 12 hosts allowed with the above explained rule?

Many thanks in advance. 
kobie

I'm not sure if I was clear enough...

If you have made separate "dns host" entries in a single group in a packet filter using "up2date01.astaro.com" without the quotes (ex:up2date01.astaro.com, up2date02.astaro.com, up2date03.astaro.com, up2date04.astaro.com and so on...

Then DROP the packets in the rule. Only then will you see which servers the up2date is trying to access in the up2date log. It will take some time before all of the servers have failed to connect.

You should all so be able to hover your cursor over the dns host entry and see the resolved ip address. Write them down for your reference. You will probably have six different ones. The others will be repeats. You can also view the ip addresses for the up2date servers in "Definitions", "Networks" type filter "astaro" (no quotes), and when the entries appear you should be able to see the ip addresses.

After you have determined what the ip addresses are using these two different ways, you should be able to determine whether or not the traffic you are concerned about is valid up2date traffic or not.

After you are satisfied that you know the ip addresses of the astaro up2date servers, turn the packet filter rule off and delete it. The ASG does not require a rule for up2date to function. You may choose to save the entries up2date01.astaro.com (01-06) for future reference. You can always look at them in the definitions/networks area.

Do not leave the rule in "allow" because the ip address could be spoofed if someone knew your wan ip address.

I misspoke. I apologize. Kobie, you'll want to "BLOCK" the servers to see the failed up2date entries in the up2date log. That is the only way you can see the ip addresses. You see them when they fail. You will want to delete the rule when your experiment is complete. Again, you can save the up2date entries for future reference if you desire.

I hope this helps.

If you find out that the traffic you are concerned about is not from or to astaro servers, then you may have some work ahead of you.


Jim

Kobie,

Were you able to identify the up2date servers?

If so, did you determine whether or not the traffic of which you originally spoke was legitimate traffic, or do you have a bigger problem?


Jim