Endpoint Protection

 View Only
  • 1.  SEP custom IPS signatures question on variables and localhost

    Posted May 22, 2014 11:05 AM

    I have read that $LOCALHOST is pre-defined in SEP's custom IPS.

    However, it seems to me that in 11.xxx it used to be listed in the variables tab. I could see it there, but I MAY BE WRONG, I may be remembering SEP 11 incorrectly as that was a long time ago.
    * Currently I see a pre-defined variable named "any" which I did not put it there in the variables tab list yet it exists.  
    $LOCALHOST does not exist in that Variables tab, while 'any' does.

    So - What is meant by "predefined" ??
    Does that mean I should see it in that variables list/tab along with "any",
    or does predefined mean that it's hard-coded into SEP and needs no further definition?

    And if it is not needed in the list we "see" in the variables tab - and it's hard-coded directly into SEP - then if I do not define either daddr=(xxxx) or saddr=(xxxx) in a custom IPS signature, does SEP automatically ASSUME "$LOCALHOST" or should I put it into the signature such as saddr=$LOCALHOST   ?
    If I do not specify a source address or destination address, do it assume ANY address at all? That seems to make more sense - if I don't specify an address for source or destination, and if I do not specify source or destination as LOCALHOST, can I assume that the sig will apply to ANY address at all?

    I'm trying to figure out how so many people here are getting through to blocked things-  it's almost as if the computer or user tries so hard they eventually over-run SEP's custom IPS and they get through anyway.
    If I had a signature that said block and content="ebay.com" I would see some people STILL getting to ebay.com while others would not, and of those it appears to block, I see in their history that they still somehow end up getting to ebay.com/login or similar, JUST for an example I can think of fast!

    If I block some cloud document or file sharing, again just as a fast example, googledocs - the sig will specifiy googledocs url, but in the computer history I see where they not only got there, but opened a shared document.  How can that be?

    I say that because I see in the logs where a person/computer triggered a rule, and it says it was blocked and it's listed in the logs, so I assume it was blocked, and yet I see in the web history of that computer that they successfully accessed the blocked site, logged in and actually used it for a while, dozens of hits in the history, and the sequence of pages proves they met with success getting there, yet SEP's custom IPS logs show that attempts were blocked.  So I have to assume SEP blocks some attempts, but not all, and they eventually make it! Perhaps SEP logs blocking 10 attempts, but they tried 11 times and the 11th made it for example.  IS that possible?

    I'm trying to figure out where the problem is - are there so many rules defined in the custom IPS that SEP just plain can't keep up and so half the traffic is blocked, half can't be blocked and all it does is slow them down getting there?

    Is there a problem with the "$LOCALHOST" variable - I no longer see it defined in the variables tab, I thought it USED to be years ago, but it sure isn't now. And if not there, why is an ANY definition in there? Why one and not the other as "ANY" is also predefined by someone! Not me.......

    And if the rules DO block, why can some folks get through if they keep trying hard enough?



  • 2.  RE: SEP custom IPS signatures question on variables and localhost

    Posted May 22, 2014 11:26 AM

    I can't speak to this because I don't have 11.x around any more but curious as to why you're using custom IPS to block sites? Or are you just blocking specific content on sites?

    A firewall rule to block sites is probably much easier/preferred. I know you get pretty advanced with SEP but just curious...



  • 3.  RE: SEP custom IPS signatures question on variables and localhost

    Posted May 22, 2014 12:28 PM

    Because firewall rules are worthless with the state having an AKAMAI server around.

    I thnk I may have said before - if you block an IP address assuming that because it resolves to eBay.com today - you'll find that tomorrow people can't get to walmart.com.
    The state's AKAMAI server really screws up the ability to use firewall rules with specified remote host IP addresses IN SOME CASES. Some are pretty static - some I find the AKAMAI server tells the DNS server one thing at one moment, then changes later.

    And, because you must know ALL of the IP addresses - for example, try to block symantec.com using an IP address - or even any other large entity. Most today have servers all over, and a domain can move like I have found out the hard way blocking IP addresses, suddenly I get calls because someone can't get to some legit training site - only to find that the owner moved to a different host and that host is GODADDY and we block so many of their IP addresses due to their "see no evil" policy, we find the legit site now blocked. I have found that if I block one IP address or range, there's another they can get there with.
    doubleclick.net, or other AD sites, I have 173.194.46.95 shown to resolve to doubleclick.net
    OK, so that's the address. I also show 74.125.225.58 to resolve to doubleclick.net
    MAYBE that's not a great example because that's GOOGLE, but that's my point - to avoid being blocked by firewalls, ad serving servers/hosts tend to have IP addresses all over the map. You'd have to list every single possible range.

    "IP to domain" is a moving target.

    Plus, like you said - If needed I can block only PARTS of a destination with these rules. That's very handy because with MALWARE - the IP address is a moving target changing daily.
    Check the domain hosting records - they keep moving the domain around, and if you block some specific parts of the malware path, you usually block the malware. But block the IP and they simply move to a different host or IP.

    I checked the records for some sites I knew had malware and were pretty much specifically for that purpose and find that some of the "owners of record" were very active, buying new names and moving to different hosts sometimes more than once a day. So in those cases I block some strings I know will be in common regardless. They can move to a different host or IP - but for malware, phishing and that sort of thing to work, the URL must remain the same. Block the URL and the IP is irrelavent. Can't do that with a firewall.

    IF there was no AKAMAI, if a site we needed to block or restrict would keep the same IP address and it wasn't 10 ranges all over the addressing map, and they ddn't move around, I'd prefer the firewall myself. The firewall does apply before IPS with SEP anyway, and it's quite reliable. And simple! I do have a list of addresses known to be hosting malware, and I have a list of IP addresses of other countries that we just plain block as we have no business in Saudi Arabia, for example, and we don't do business with China, so some of these ranges are just plain blocked and that's very simple with the SEP firewall.

    But due all of the other above info - it can't be used to block some domains or some parts of domains.