Monday 16 April 2012

Symantec Antivirus SAV 10.x goes End of life (well EOSL) sort of..

7ish years ago SAV 10.x was at the forefront of corporate AV protection.  I personally thought it was great and we happily upgraded a year after its launch from the 9.x version on our network.

An announcement has been made that it is now going EOSL in July 2012.  Its interesting to note that it will go end of support life rather than end of life - yet the message we have received and seen can be a bit worrying...

Firstly, the use of 'support' life will cause many admins to raise an eyebrow.  Does this mean that we can still get definition files/updates?  if not, we'll have to hastily migrate to the SEP 12.1 product within 3 months - or switch vendors all together.

Secondly, there is no mention of this in the emails sent to customers and/or on the website.  By not announcing eitherway whether definitions are allowed passed July 2012 will potentially scare customers into going with SEP 12 anyway - a clever marketing ploy I think.  This could backfire though, like I said, its a choice to upgrade to SEP 12.1 and its just as much of a change than it would be to switch vendors altogether.

The news from our camp (after contacting Symantec) is that XDB updates will not be available online for SAV 10.x installations.  We rely on manually updating the definition files daily - whilst many employ the LiveUpdate application to do this for them - we're old fashioned and like to see the file download + run.  BUT.... if you continue to use LiveUpdate for SAV 10.x installations after July 2012 then you 'should' still be ok.

Make of that what you will.

I noticed that you can pay to have definitions available beyond July too!  So Symantec would charge you for packaging the update and hosting it for download - when LiveUpdate will continue to work for free?  Money for old rope? - I think so.

Now, many people will question why you're still on a legacy AV product anyway - what with security and all, being a top priority in most organisations.  I do have some sympathy for the folk left behind - I've managed migrations to SEP and it is a task - one that should be project managed if you're doing a large scale deployment and its features and functions are massively different from the 10.x platform to boot.  Smaller organisations might have employed better edge protection and thus have decided to stick with 10.x or there might be financial reasons.  The best case I've heard is of a small business running 10.x because when they paid for contracted resource to install it (in 2008) it has just 'worked' ever since.

I still think that Symantec could have/can do this better.  Their clever/not-so-clever decision to omit the definitions question with either alienate or force the hand (neither make good customer relations).  Why not announce that defintions will continue to be available for 6 months after the EOSL period or tie in with the renewal period of current licence holders?  Sack off the fee for updates idea (that just makes you look greedy) and distribute trials of SEP to current 10.x customers so they can use the 6 months to familiarise?

Anyway, goodbye to SAV - thanks for all the phish(ing) emails you've not protected me against - only joking Symantec.  Can I have a job please?

Wednesday 11 April 2012

EIGRP Route filtering (from CCNP study)

I have managed to mock up the 'work' network using GNS3 = great success.
As such, I can apply the CCNP knowledge learned through study on the work based topology to enhance my comfort levels with the various commands.

Today (and the past few weeks) have been focusing on EIGRP which we do not use at work (from the ICND1 days, you'll know that EIGRP is Cisco's proprietory routing protocol) because we have some HP (peh) equipment at the core.

Route Filtering with EIGRP
Filtering inbound routes by source (using a route-map)

I set myself a small task of filtering EIGRP routing updates on an inbound interface.  I inserted the following commands:

acccess-list 99 permit 192.168.240.2and then:route-map test deny 10
match ip address 99
route-map test permit 20
and then (under the router eirgrp <process number>:
distribute-list route-map test in


Explaining the above: I wanted to block routing updates from a device with I.P 192.168.240.2 listed in the ACL 99 I created first.  I then created a route-map called 'test' and denied anything that matched the ip address defined in the ACL 99.  Route-maps end with an explicit deny, so a permit statement with a later sequence number (20) was added to permit everything else.
I then inserted the distribute-list command referencing the route-map name and specified it as inbound.

Sounds good - but it didn't work! LOL.

The answer was with the match statement in the route-map:

match ip route-source 99

With this in place, routing updates from 192.168.240.2 were not in the routing table - leason learnt.


Filtering inbound routes by what is inside the route advertisement (Using an ACL)

Now lets say we wanted to receive routing updates from the router 192.168.240.2 but within its route advertisement it was advertising a route to 192.168.15.0/24 and we would like to remove that.

Distribute lists do not work with extended ACL's so its best to create an standard IP ACL.

ip access-list standard test
 deny   192.168.15.0 0.0.0.255
 permit any


Like so.  We have created a standard ACL called 'test' and denied our subnet we want out of the routing update.
Under the router process we define the distribute list:

distribute-list test in

To check the ACL is matching packets you can run a show access-list command and the show ip route command should confirm that the route is being filtered.

I will state as a mini-disclaimer that I do not like route filtering inbound unless it is a real requirement for complex networks.  Route re-distribution plays a role in inbound filtering but for most networks the inbound filtering component can be a headache to manage and understand (especially if not documented correctly).  Also in most enterprises a branch site router over some WAN link would want a route filtered before it traverses the WAN link!  otherwise the bandwidth is being used, only to the have the route removed at destination.
The stages of learning early CCNP text reference route filtering on outbound interfaces only - obviously to keep you sane! but also, its far easier to define what is being filtered out than in (in my opinion) at this early stage of learning.