[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 925
  • Last Modified:

Is my Cisco ASA 5505 blocking port 80 traffic to Kaspersky.com? If so, why?

We recently took over a small (1 Poweredge 2900 box running Windows 2003 Standard server, 15 clients, mostly Win7 Pro) network.  The network was previously configured but we've gone over things and modified per best practices.  Part of the reconfiguration has been implementing a paid antivirus solution.  We are using Kaspersky Endpoint Security for Business Select.  The problem we've run into is that the Kaspersky Security Center can't download updates.  

Kaspersky picks a download server from random from a pool.  Servers are in the format of http://dnl-XX.geo.kaspersky.com:80.  Connections always fail.

The router is a Cisco ASA 5505 which I am administering via the web SDM.  Its firewall actively blocks outbound traffic. I've already worked around this for other services by adding Access Rules to the Security Policy tab using the following configuration:
Interface: outside
Action: Permit
Source: Any
Destination: Any
Service: <custom service for the program's specific port>
Traffic Direction: In
Source Service: <blank>
Time Range: <blank>

The other services for which I have created incoming rules on the outside interface have worked properly.  For example, the offsite backup service we use runs on port 444 and after creating a rule for it, it communicates as expected.

Since Kaspersky uses port 80, I have created a rule using the same settings as mentioned above for port 80, but the Security Center is still unable to communicate with the Kaspersky update servers.  

That said, I am able to web-browse from the server with no problems, so obviously outgoing traffic on port 80 is already working.  It was working before I created any rules for port 80 trying to fix Kaspersky.

Stuff I have noticed or tried:
--This problem appears to only affect Kaspersky.com's update addresses.  I can browse and telnet to the Kaspersky website at usa.kaspersky.com:80 but cannot telnet to dnl-XX.geo.kaspersky.com:80.
--I can telnet to services that I have created custom rules for, IE the offsite backup service on port 444.
--DNS resolves dnl-XX.geo.kaspersky.com properly (confirmed by tested elsewhere) but pings time out and tracerts fail part of the way there.  
--The problem does not appear to be ISP-related--other businesses share the same fiber connection (behind different routers--sequestered from each other) and they can browse, ping and telnet to dnl-XX.geo.kaspersky.com with no problems.
--I can't find anything in the ASA's configuration that leads me to believe it's actively blocking anything Kaspersky-related.
--Rebooting the server has no effect.  
--The workstation I tried on that network CAN ping and telnet to dnl-XX.geo.kaspersky.com so the problem appears to be limited to the server.  All workstations get IPs via DHCP on the '03 Server, and all workstations have the '03 Server's DNS as their sole DNS provider.  
--ipconfig /flushdns followed by ipconfig /registerdns on the server has no effect.
--Windows Firewall is not running on the server.  
--There doesn't appear to be any other firewall installed on the server.  (No antivirus is installed currently either--I have just installed Kaspersky Security Center, not the Endpoint client.)
--The server is not configured to use a proxy.  However, it appears that it had been at some point.  The proxy address that had previously been used is an external IP address, on port 2720.
--The server's NIC is a Broadcom NetXtreme II.  The driver is v4.4.15.0, from 5/14/08, so it's ridiculously old.  I'm hesitant to update it since I'm working remotely, but maybe I will and just head over there as soon as they open, if it bombs.
--As far as I know, the server is not having communication problems with any other sites or services.

So, I can't find anything on the server that looks like it might be blocking Kaspersky's update servers, not can I find anything in the ASA that could be blocking them.  What should I try next?
0
SINC_dmack
Asked:
SINC_dmack
  • 13
  • 5
  • 5
3 Solutions
 
MattCommented:
This is what I have on ASA 5505 and it works perfectly:

name 192.168.1.0 LAN

object-group icmp-type DefaultICMP
 description Default ICMP Types permitted
 icmp-object echo-reply
 icmp-object unreachable
 icmp-object time-exceeded
access-list acl_inside_in extended permit ip LAN 255.255.255.0 any
access-list acl_outside_in extended permit icmp any any object-group DefaultICMP  

access-group acl_outside_in in interface outside
access-group acl_inside_in in interface inside

interface Vlan1
 description LAN
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
 description WAN
 nameif outside
 security-level 0
 ip address dhcp setroute
!


Regarding ping and traceroute - can you ping to other sites normally from server? What about ping from clients? Can you ping from server using FQDN name or only using IP address?


ASA Version 8.2(5)50.
0
 
AkinsdNetwork AdministratorCommented:
Confirm the following with the vendor
- That your account is enabled to receive updates
- That the updates will come through port 80


Observation
Please consider narrowing the opened ports to specific IP addresses that the services are connecting to. Opening a port from any source to any destination is a bit risky. There are programs out there that attackers use to scan for open ports. If you know the destination and/or source that your services connect to or from, please specify them instead.

www.canyouseeme.org  (Check your wide open ports)

Check the other port here
http://mxtoolbox.com/PortScan.aspx
0
 
SINC_dmackAuthor Commented:
Hi Matt,

I’m console-dumb so all of my ASA configuring is done via the SDM.  (We come across Cisco equipment maybe once or twice a year so there’s no compelling reason for me to work on acquainting myself with the console.)  So while I sort of understand what you’ve typed, I don’t understand it enough to translate it into something I can enter into the SDM.

The server appears to be able to access ALL other sites via ping, telnet and browsing.  

The clients can access ALL sites via ping, telnet and browsing, including the Kaspersky update sites.

The server resolves DNS for the Kaspersky update sites properly but ping requests time out.  The workstations resolve DNS and ping requests reply normally.

Thanks!
0
2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

 
SINC_dmackAuthor Commented:
Hi Akinsd,

Kaspersky doesn’t do any server-side management of rights to download updates.  The ability to download updates is controlled by the server having a current license for Kaspersky maintenance.  The server does have a current license, but I did just load it yesterday.  I’ll reboot the server after hours (it’s currently doing a RAID5 -> RAID6 migration) but I am skeptical that will help.

The updates definitely come through port 80.  The log for the updater specifically lists http://dnlXX.geo.kaspersky.com:80. (XX is a random number from at least 01-10, and probably higher.)

While I do have the firewall currently set to allow traffic on specified ports from any external or internal IP address, I only have one port forward in NAT, which is 3389.  The port forward is configured to only allow incoming traffic on a couple of authorized IP addresses, even though the firewall is set to allow 3389 traffic from all internal and external IPs.  For example, the client can RDP in from their approved IP, but I can't RDP in from my office because my IP address is not one of the ones that is specifically trusted for the port 3389 forward in NAT.  

Correct me if I’m wrong, but I’m pretty sure that NAT will automatically block unsolicited packets from outside IP addresses regardless of whether I’ve got the firewall set to allow or deny traffic on those ports.  IE, if the firewall is set to allow all traffic on port 80, the server should be able to use port 80 to its heart’s content, but if some hacker tries to come in on port 80 (which does not have any port forward in NAT), then the hacker’s packets should be blocked.

Thanks!
0
 
MattCommented:
For you to access your PC using Remote Desktop Protocol (TCP port 3389)...to make it much more secure and flexible, configure either IPSEC VPN or SSL VPN on your ASA. Using VPN, you will then be able to access your PC from anywhere as long as there is VPN tunnel up and runinng.

Can you see any log on ASA device? Is there any "Deny" statement?
0
 
AkinsdNetwork AdministratorCommented:
NAT is not a security feature. All it does is translate one IP to another.
ACLs are not necessarily enough either. That is why most firewalls run IDS (Intrusion Detection System) and IPS (Intrusion Prevention System).

You may be aware how teenagers get to buy drugs or get access into clubs etc. Similarly, Hackers can hack systems when they spend enough time on it. Man In The Middle Attack or Spoofing atacks are possible. Let's say you allow IP 10.10.10.10 to be NATted through port 3389. If spoofed, the hacker will intercept the traffic, replace the content and forward it on. The source IP still shows as 10.10.10.10 but it's no longer the authentic address.

Encryption through IPSEC as Matt mentioned is a very good idea.
0
 
SINC_dmackAuthor Commented:
I appreciate the comments about NAT and security.  The remote clients are actually connecting via VPN before using RDP, so I feel reasonably confident that they're secure.  

The Security Policy has Deny rules for both Inside and Outside connections; the Deny rules are the last ones for Inside and Outside, meaning that anything that is not specifically allowed by a higher-up rule is blocked.  

I just updated the Broadcom network adapter's driver and firmware to the most recent versions available. The server is a Poweredge 2900, so the most recent stuff is still a couple of years old.  Regardless, that had no effect.  

To reiterate, the server cannot ping or tracert to dnl-XX.geo.kaspersky.com (XX being a number) but it can ping and tracert to every other internet address I've tried so it appears that something is specifically blocking kaspersky.com's update sites.  Workstations on the same network can ping and tracert to the same dnl-XX.geo.kaspersky.com addresses with no problems.  

I've tried viewing the "Latest ASDM Syslog Messages" but I haven't seen anything where the destination IP matches any of the Kaspersky servers that I am unable to communicate with.
0
 
SINC_dmackAuthor Commented:
It occurred to me that since I don't see anything in the ADSM Syslog Messages indicating that traffic is being blocked to the Kaspersky update servers (but I do occasionally see other traffic being blocked, such as when I tried to ping the ASA from my remote office), it seems likely that the problem is on the server itself, not on the Cisco.
0
 
SINC_dmackAuthor Commented:
I just did a route print on the server and there are a bunch of existing Active Routes.  The IPs of those active routes coincide with the IP addresses of the Kaspersky update servers.  For example:
Network Destination - 4.28.136.36
Netmask - 255.255.255.255
Gateway - 192.168.51.7
Interface - 192.168.51.5

This is the problem--the gateway is actually 192.168.51.1.  There is no gateway (or any device whatsoever) on 192.168.51.7.

So, why in the world would the server be creating active routes for just the Kaspersky update server IPs, and try to gateway them out on the wrong IP address?!  More importantly, how do I fix it permanently?  (I don't want to just throw a route /f at it as I'm logged in remotely and I'm pretty sure that will kill my connection and probably require a server reboot to restore.  And I don't want to manually create a route statement for all of those Kaspersky servers--that seems like a poor band-aid fix.)
0
 
SINC_dmackAuthor Commented:
I manually deleted one of the bogus active routes using:

route delete 4.28.136.36 mask 255.255.255.255 192.168.51.7

And I was then able to ping and tracert to that IP address.  Unfortunately, Kaspersky picks its update servers at random so even if I tell it to update, it may be several retries before it attempts to connect to that specific IP.  So I think what I'm going to do is schedule a reboot of the server after hours and then run the route /f command.  (There are literally 70-80 bad active routes--not really wanting to remove them all manually.)  That should clear out all of the bad routes (hopefully it won't reappear) but re-establish the good route once the server does its scheduled reboot.
0
 
SINC_dmackAuthor Commented:
Last night, I scheduled a server reboot with a 60-second delay using shutdown -i.  I then ran a route -f, which cleared out all of the gateways and kicked me out of the server.  The scheduled reboot brought it back online, but all of the undesired active routes reappeared.  

I checked your link, Akinsd, and ICMP Redirect was enabled, so I've disabled it.  I won't be able to reboot the server until this evening, but hopefully that fixes it.  I'll update the thread once I know.  Thanks!
0
 
MattCommented:
Hm, are the routes on server persistent?
0
 
SINC_dmackAuthor Commented:
Disabling ICMP Redirect had no effect--all of the active routes returned after a reboot of the server.
0
 
SINC_dmackAuthor Commented:
The routes are active, not persistent.  routes1.jpgroutes2.jpg
0
 
MattCommented:
What is behind IP 192.168.51.7 ?

192.168.51.1 is Gateway defined on ASA device?

Default route is passing the traffic via 192.168.51.1, all other is on 192.168.51.7? Why?
0
 
SINC_dmackAuthor Commented:
There's nothing on 192.168.51.7--there is no response to pings, and nothing when I browse to http://192.168.51.7:80 or :443.  We've only recently taken over this site, so it's certainly possible that some sort of router was on that IP address previously.  

192.168.51.1 is the IP address of the ASA, and the default gateway for all of the devices on the network.

I have no idea what's causing the server to try gateway some traffic through 192.168.51.7--that's the last piece of the puzzle.
0
 
SINC_dmackAuthor Commented:
What I did last night was paste the entire route print statement into a Notepad document and make a script that does "route delete" for all of the active routes that are attempting to gateway through 192.168.5.7.  I've set it to run as a daily scheduled task, in case those active routes come back.  That's fixed the symptom, but I'd still like to know where the bogus active routes are coming from, so I can fix the problem at the source.  

If anyone has any idea how to figure out what's creating these active routes, please let me know.
0
 
AkinsdNetwork AdministratorCommented:
Your server may be running "RRAS" or there may be a script that's adding those routes also.
If using RIP, you mentioned that the router may have been removed, which means the server is still learning RIP routes from somewhere. The only alternative to that is scripting.

You can use advanced IP scanner to determine if that address is still on your network and see what the name, type of device etc it is

http://www.advanced-ip-scanner.com/

Check this other link below for RRAS
http://www.windowsnetworking.com/articles-tutorials/network-protocols/How-configure-Windows-2008-Server-IP-Routing.html 

If nothing on RIP routes, check your group policies or local policies on the server for any auto script
0
 
SINC_dmackAuthor Commented:
Akinsd, I checked Routing and Remote Access and its status is "stopped (unconfigured)", so it appears that RRAS is not in use.  Thanks for the link for Advanced IP Scanner.  I've previously used Angry IP Scanner, and GFI LANGuard 2.0 (so old it's free)--Advanced IP Scanner appears to offer comparable functionality.  Alas, nothing responds on 192.168.51.7.  

As far as I can tell, if RRAS is not installed, RIP would not be in use, so that shouldn't be where the routes are coming from.

The only group policy objects are Default Domain Controllers Policy and Default Domain Policy, and they both appear to be only slightly modified.  None of the modifications appear to affect routing whatsoever--the closest thing I can find is a Windows Firewall/Domain Profile entry that's configured to "allow unsolicited incoming messages from 192.168.51.5/24".
0
 
AkinsdNetwork AdministratorCommented:
This is really mind buggling.

I will research further on this. Good thing is you have a temporary fix for now, but the desired permanent fix will be to identify the source of those routes.

I will let you know if I find something

All the best
0
 
MattCommented:
Do you have any service installed on server that might be connected to routing?

Try in command prompt on the server:

netstat

and also

netstat -bn

So you can see which service or application is listening on your ports. Maybe you Will find something interesting.
0
 
SINC_dmackAuthor Commented:
Using the workaround of making a script to delete the problematic active routes fixed the problem.  Matt's suggestion that I check the logs on the ASA helped me realize that the blocked traffic wasn't even making it to the ASA.  I rated the solution a B as it's more of a Band-Aid workaround than truly fixing the problem.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 13
  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now