Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Issues with PortScan detections

Created: 05 Jul 2012 • Updated: 05 Jul 2012 | 9 comments

Maybe this is a coincidence and maybe it is related to NTP module 07.04 definitions update. But i will describe whole situations. Our internal network was on SEP 11.0.7101.1056. 2 weeks ago i have installed newest version (11.0.7200.1147) via client install packages on 10 PCs (testing group) varying from Win7 to Vista and XP (all 32 bit). Everything was fine for 2 weeks and today i have pushed this version to all PCs. Also those 10 PCs were moved back to their groups and so install package was applied to them again. But usually this doesn't cause problems and those computers doesn't get to install the same version. Also those 10 PCs didn't get the notification about the upgrade. So maybe this is not related to this new version and only a coincidence, but almost after a 30 minutes PortScan messages started popping up on random computers with random IP addresses and then active response blocking turned on (was enabled by default). But it is blocking whole internet connection, not just one IP which is mentioned in the message. So the user has to restart the PC to get back internet connection. I myself got few such messages and i can't say where those IPs maybe be coming from (e.g. 204.93.223.146, 193.0.6.139). It looks like this is happening only when using IE. Maybe IE updates suggested sites from this IPs or something. Also a while ago it was showing IP address of Canon site in our country (canon.lt) and other legit and trusted sites. It looks to me that SEP is going nuts with those portscans detections and blocks all connections instead of the ones in the messages.

So far i had 7 reports about lost internet connection and all those PCs are now on 11.0.7200.1147. So maybe it is related to this version or maybe this version and today's definitions. I have disabled portscan detections and active response blocking as this feature makes our network unreliable and i doubt about its usefulness.

Can anyone explain what and how is happening here and what's the purpose of portscan detections. Should i leave it disabled? As we already have Fortigate firewall on the edge and everyone is going through it to the internet.

This is not a completely new issue. I have older thread about portscans, which is already locked without any clear answer from Symantec. Though last time it wasn't such a big issue because it wasn't blocking internet connection. Maybe such blocking was introduced in this newer version?

Comments 9 CommentsJump to latest comment

Mithun Sanghavi's picture

Hello,

Check this Article:

What triggers a port scan detection in Symantec Endpoint Protection (SEP)

http://www.symantec.com/docs/TECH165237

This could be caused when the traffic will go through subsequent ports in a fairly rapid succession on the host's network adaptor. Due to the nature of the Intrusion Protection System (IPS) detection, which is hard coded within the product, this will trigger a port scan detection. Symantec development has reviewed this issue and determined that the product is working as designed. Modifying port scan detections to allow this type of behavior would potentially impact the ability of the product to detect a malicious port scan attack.

Try this workaround to stop detections:

1. Create exceptions within IPS to exclude relevant hosts in your environment. (Recommended)
2. Using NAT networking for VMs, rather than bridged networking.
3. Use a server OS such as Windows 2003 or Windows 2008 as the host OS for virtual machines.
4. Uninstall NTP and IPS from the SEP client on the host machine.

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

wroot's picture

I can't create exceptions as the IPs shown in the detection messages are unknown to me (some US or Europe ISPs), i have no clue where from they are coming.

You said it is by design. Is it by design to block all Internet connections when it detects a portscan from one or two IPs? Because it is what was happening last time. After a few messages about detected portscans i had to reboot my PC because i couldn't load any web page with both IE and Firefox.

greg12's picture

To trigger ActiveResponse, Port scan needs a firewall rule that detects packets hammering on a client. To get better informations, check the traffic log on an affected client. If there is nothing, you could enable logging for the firewall rule that is responsible (must be one at the bottom of the rule list).

With these informations, it's possible to exclude "attacking" IP addresses that are harmless. See here:

Setting up a list of excluded computers

http://www.symantec.com/docs/HOWTO27084

So you can keep port scan detection enabled if you want to. Of course, if there are a lot of IP addresses triggering port scan alerts, this doesn't make sense, and it's better to disable it.

ActiveResponse not only blocks port scans but all other attacks detected by Intrusion Prevention. Thus, I would keep it enabled.

wroot's picture

Worse upgrade ever.. Today i have internet loss issues all over the place. I see that i'm not alone in this https://www-secure.symantec.com/connect/forums/sep... I don't have to play with logs and debug. I see nothing special in the traffic log and connection is getting lost even if users are only browsing to the legitimate information system like this https://dms.finmin.lt/dms/faces/pages/welcome.jspx 220 of ou users has to use this system all the day. And now many of them has to reboot their PCs every few minutes. I see nothing special in the traffic or other logs. Here's from mine PC:

2012.07.09 15:05:56    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-7F    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 15:05:38    2012.07.09 15:05:38    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:37    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:35    2012.07.09 14:50:35    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0x8137]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0xE0E0]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0xE0E0]    0.0.0.0    00-C0-EE-8A-23-8C    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
2012.07.09 14:51:31    Blocked    5    Incoming    ETHERNET [type=0xFF]    0.0.0.0    00-C0-EE-8A-23-A7    0    0.0.0.0    FF-FF-FF-FF-FF-FF    0        wroot    ESFA    Default    1    2012.07.09 14:50:30    2012.07.09 14:50:30    VPN Rule 6    
 

VPN Rule 6 is our house rule which is bloking all traffic which is not qualifying in rules 1-5. Rule 1 is letting any outgoing connections from LAN IP addresses. These rules are made years ago and it works ok with SEP 11.0.7101.1056. I have dowgraded one PC and so far it works fine for 4 hours. So now i'm facing the manual dowgrade of 220 clients feat.. Not the first time! Last time it was becase SEP was braking SMB2, then we managed to workaround by reverting to SMB1 via GPO. Now i can't find any other workaround. Thinking to disable firewall policies until i downgrade every client.

wroot's picture

I have enabled Notifications on Firewall policy and i just got a message that traffic was blocked from ntoskernel.exe and svchost.exe, which is very weird to block such system core parts.

J3d1's picture

The traffic blocked on svchost.exe could be IPv6 and your firewall policies have a rule to block it as default

wroot's picture

I have IPv6 protocol disabled on my LAN connection Properties.

Simon-P's picture

wroot,

Did you ever resolve or find the underlying problem to this issue?

Your scenario described is near identical to mind.  I logged a ticket with Symantec, but they don't seem to acknowledge there's a problem.

wroot's picture

No. I didn't do much investigation further. Had to make all systems working, so i just did a manual dowgrade of all our users to an older version 11.0.7101 (12 version was working fine, but another system stopped working on our servers, so i couldn't just upgrade to 12 on top of 11 via deployment.

A temporary workaround (as i describe here http://www.symantec.com/connect/forums/sep-1107200...) could be to disable firewall policy for the users, which i had to do before i downgrade everyone.