Endpoint Protection

I use a lot of custom IPS sigs to block certain web sites when IP addresses won't work, or when they use proxies, etc- as the content of the packet can be defined in the sig.

For example, if I want to block traffic to phony-av.com no matter where it's hosted I create a rule with
rule tcp, dest=(80), msg="phony-av site",content="phony-av.com"

as content.

HOWEVER, it has come up that we need to allow 1 single person in one office to access such a site, while preventing anyone else from accessing this site. They have good reason to (no it's not the phony-av.com thing, but another site we normally block, but one person needs it badly for their job, it's legit for them)

SO, is it possible to create a rule in the Custom Intrusion Prevention Signatures area that will do
rule tcp, dest=(80), msg="phony-av site",content="phony-av.com"
but maybe have some qualifier in it - like block this unless the request comes from or goes to IP 123.321.33.32/27 for example??

That would allow that one office in, or even narrow it down farther........

I need to use these rules, they are handy, they work, they are simple, and it's in some ways better than a firewall where the resolution of the IP address of the blocked site can change, like some porn and fake av sites do - different host, different country, different IP address, but the URL is almost always the same. That's where custom IPS shines! Can I put a qualifier in there to block it in general, UNLESS it's a certain IP or range or even computer name involved??

Please? Thanks.

I think you can just add a variable to the custom policy. Try the Variables tab

Add your range of IPs or obviously you can just create another group but not sure if that works for you.

would rather not create a new group for each exception........ that gets a bit cumbersome to have to move computers around to different groups and then maintaining all the other polcies between groups.

A variable is something to take the place of something that might change in several rules - so that isn't something I can see working. Even at that, so what would I do with it if I created it?

There's got to be something in the rule syntax (like the example above) that says if not this IP, follow this rule, or if = this IP, then don't follow this rule........

It uses Snort syntax so if you're familar with that, you may be able to work something.

I stopped writing these custom signatures long ago. Problem is there isn't much documentation out there from Symantec on it. There a few page PDF but that's all I've found.

Do you have a link to the PDF? I believe I got something from Symantec one time, but can't find it.

Not at all familiar with snort, and do have the PDF since I did a comprehensive search of the entire connect area before asking. the one I have is from Andrew Willetts, https://www-secure.symantec.com/connect/sites/default/files/Steps_to_create_a_custom_IDS_signature.pdf

 

HOWEVER, there's no talk of criteria other than what's in the packet - it shows a lot of the basics.

But if we were to use that PDF as an example - what if.... I want to block FTP downloads of MP3 files just like he shows in that PDF document, BUT, allow one user or one IP or one range of IP addresses to download MP3 files, how would I do that? Say I made his example - and it blocks FTP access fine - but I've got a person who needs to download MP3 via FTP - how can I make that rule say do it only if the IP address is not xxx.xxx.xxx.xxx

I know snort has a "pass" parameter which will allow ou to exclude IPs but I'm not sure how the syntax would fit for SEP.

Try adding "pass ip 10.x.x.x" or similar

May have to play around with it.

You need to add saddr or daddr to your IPS signature. In your example you create two signatures and list the one you want to allow first. Define the saddr(source address) as the IP or subnet (CIDR notation) that you want to allow. Set the action to allow. The second signature will look almost the exact same except saddr will use $LOCALHOST and you set the action to block.

i.e. (Destination of 0 means any port but you can use specific ports like 80,443,8080) (saddr = source address)

Action Allow

rule tcp, dest=(0), saddr=(123.231.33.32/27), msg="[SID: Allow-Phony-AV-Site]", content="phony-av.com"

Action Block

rule tcp, dest=(0), saddr=$LOCALHOST, msg="[SID: Block-Phony-AV-Site]", content="phony-av.com"

Let me give that a shot in testing - it looks easy enough. Thanks - that's as close as I've been so far, and if this works, they'll be REALLY happy.  I should be able to test that with ANY site pretty easily, even google, and see how it works. 

The tests failed. I put in a specific address for one computer, and $LOCALHOST in the next rule down in the list to block for all others.

It lets them all through. Before I put in any saddr parts it blocked quite well. Must be a formatting/syntax issue.

Give me about 15 minutes and I'll test it on my end. It is very picky aboutsyntax but I've written many custom signatures and my coworker has as well.

I completed testing and it works. Here are the example rules I used. Please note that it appears you need to list the block rule above the allow rule.

rule tcp, dest=(0), saddr=$LOCALHOST, msg="[SID: Block Website]", content="google.com"

rule tcp, dest=(0), saddr=(192.168.1.31/32), msg="[SID: Allow Website]", content="google.com"

Results -

My client with the 192.168.1.31 address could access google.com

My client on a different subnet could not access google.com

Thanks dude

I wish there was a list of accepted syntax or just an official guide put out by Symantec. I know it's based off Snort but as you already mentioned, it can be VERY picky sometimes.

I agree and I've asked Symantec to design a wizard that will either take a snort signature and output Syntax for SEP or at the very least a wizard that takes input from an admin and then spits out the syntax so we don't have to worry about guessing it correctly. Please vote for the idea if you agree. Also look at SEPM help files for mor info on Custom IPS signatures. Believe it or not it does have some detailed information.

Just to add one more note if you use IT Analytics then make sure you follow the correct syntax I'm the message field. If you don't it won't show up in Analytics. I posted an article on how to correctly create IPS signatures so they appear in IT Analytics. Please also mark this as resolved if what I posted worked for you.

Gotta leave for now - but so far, it won't work. It either blocks all, or allows all, depending on which I put in the top spot over the other.

Granted, both computers I have to test with are on the same subnet, I don't have any on a different subnet to test with today, so I was using a specific IP instead of the /xx range bit.

But it currently blocks both test computers from the site, and in the test signature group, the block is the top one, allow is the bottom one and I did a copy and paste of your examples, and only changed IP address in the one, otherwise it's a direct copy.

I've noticed that one must wait several minutes to do a true test, at least here, as the policies don't always seem to apply as fast as you'd think - evne "manually" applying up updating them from either end.

Did you try using a /32 at the end of the IP address you want to allow?

Check your system log to ensure the new IPS library was downloaded successfully. Sometimes it fails due to incorrect syntax.

Thatdude - no, I was just using an IP address.......... I've tried using the IP address with a /32 and so far, it's looking a lot better. Will know in about an hour I think.

I need to allow a range of 32 addresses since it's possible that her computer COULD get a different IP address if the ASA gets rebooted (router).  The only OTHER option is if it would take user names, or computer names, but I don't see that as an option?

brian - I did see some errors, but wasn't sure which "test policy" triggered them since the client getting policies can happen fast, or slow, even if you "refresh", but the fact that I saw an error at all made me take note. Seems these are REALLY REALLY picky and if there's a slight mistake at all, the whole thing is bad, all of it, not just the one section you are working with, but the whole thing stops working completely. WOW

Correct, the entire signature will not work even if it off even by the slightest of margins.

In my environment we have a couple of groups we setup to receive policy configurations or updates first before we send out to the masses. We also use this group to test new custom IPS signatures. You cant start testing until you verify that the IPS signature was applied. The easiest thing to do is look at the details tab of the group and make sure it reflects the most recent update. I've seen IPS changes take 30 seconds to a minute to reflect in the group. Then force an update on a SEP client and look at the the system logs. It will either show that it applied a new IPS library and the 4 digit alpha numeric number should match the details tab in SEPM for that group. If you do not see this then you will most likely experience the error failed to apply IPS library. This is an indication that you have a IPS signature incorrectly written. Note that I've have written signatures that apply to the system and still dont work so you cant just use this method to validate everything is working properly. A signature can be written with correct Syntax but it still wont work if the information you enter is incorrect

One thing I've found - I can change a CUSTOM IPS sig, and it won't reflect in the group's "policy serial number"  - at least not here, and not right away if ever. I made a number of changes in the custom IPS, and applied it to a small group and when I was in the console, looking at the client status info in that group, the policy serial number didn't change. Now it has, but I've probably made some other changes, too - even just clicking ok instead of cancel changes things.

What I was trying to do here was not very easy to test - in most cases we're blocking things but don't want it announced, and in this case, wanting 1 single person to be able to access the site - in our environment, simply letting someone know there's testing going on all of a sudden releases a flood of emails and complaints that you've messed something up - even if you have not actually started yet.

We have the most un-computer-able bunch I've ever seen, and even a simple email about something causes mass confusion. That, and the fact that we need to have some controls in place "unannounced" means it's a bit trickier. (and if it failed, it was likely to fail in a way as to open up a whole mess of security issues, and didn't want that to happen with our group) So the testing is in a very small controlled area.

Looks like it's working fine now - thanks again.

Oh, a quick PS - any way to do this on a MAC or USER or machine name basis? Reason is that our IP addresses are DHCP, and if we want this to work for a single computer, well........... it could change addresses next week if a router is bounced or computers get turned off, etc. 

Happy to hear you got it working. I'm not sure if MAC or username can be added to the rule but it's a good question. Do you know if your DHCP server supports static DHCP? This would resolve your issues with a particular client getting random IP addresses since static dhcp would always assign the same ip to this particular system.

Yea, ideally you could just set a dhcp reservation for that box so you wouldn't have to worry about it, and I probably would for just one box, but you get multiples boxes and things start to get too complicated...

I never thought to look at the Help files until you mentioned it.

Good thing you did because there seems to a wealth of knowledge in them and just maybe the best we will get at this point.

The section on Signature syntax and conventions is gold

I know our server here does (2008 R2 DCs running DHCP), in the field, we're using the DHCP server feature of Cisco ASA5505s, then the DNS and WINS info gets forwarded to the server here so the DNS is always current.