Matt Jezorek

There are times when you need to know if you are leaking SSN or PAN information into the wild west of your network or possibly someone else’s network. Or it’s possible that you know this information is moving from your box to specific boxes and you want to make sure it goes only to those boxes. It’s also unfortunately a possibility that you do not know if they are leaking and were they are going. If you understand and have any of these conditions then we can leverage Snort and OSSEC to help us defeat the evilness of passing around credit card information or social security numbers in clear text.

You will need to have OSSEC as well as snort installed in order to use this quick guide. Let me remind you that false positives can happen with this and it will probably need to be adjusted to your network slightly, you may be able to have “-” optional in your numbers or you may not. The rules below are the “-” are not optional.

Let’s start with the rules we are going to need for snort, these rules will be looking for different cards or social security numbers so each has a different rule, the rule id(sid) can be changed to meet your environment as well.

alert tcp any any <> any any (pcre:"/4\d{3}(\s|-)\d{4}(\s|-)\d{4}(\s|-)\d{4}/"; msg:"VISA card number detected in clear text";content:"visa";nocase;sid:9000000;rev:1;)
alert tcp any any <> any any (pcre:"/5\d{3}(\s|-)\d{4}(\s|-)\d{4}(\s|-)\d{4}/"; msg:"MasterCard number detected in clear text";content:"mastercard";nocase;sid:9000001;rev:1;)
alert tcp any any <> any any (pcre:"/6011(\s|-)\d{4}(\s|-)\d{4}(\s|-)\d{4}/"; msg:"Discover card number detected in clear text";content:"discover";nocase;sid:9000002;rev:1;)
alert tcp any any <> any any (pcre:"/3\d{3}(\s|-)\d{6}(\s|-)\d{5}/"; msg:"American Express card number detected in clear text";content:"amex";nocase;sid:9000003;rev:1;)
alert tcp any any <> any any (pcre:"/\d{3}(\s|-)\d{2}(\s|-)\d{4}/"; msg: "Social Security number detected in clear text";content:"ssn";nocase;sid:9000004;rev:1;)

Now that we have the rules in place and snort is looking for them we need to make sure that snort is logging in a syslog fashion and that we know where the log is. I prefer to use syslog logging because I can push all logs to a central logging server so if the machine is compromised chances are I have all the logs. We can gain syslog logging with snort by using the following configuration.

snort.conf

output alert_syslog: LOG_LOCAL3 LOG_ALERT

syslog.conf

local3.debug     /var/log/snort.log

Now that we have Snort logging the way we want and the rules are in place let’s look at OSSEC. In my case I use an agent based solution so we will need to first modify the agents ossec.conf file to include the file we are logging to above.

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/snort.log</location>
</localfile>

After we do that we can login to the server and it’s time to start putting our new rules to work. We must first create a decoder for our snort alerts so create your decoder in $OSSEC_HOME/etc/decoder.xml.

<!--
 - Snort Alerts
 - Aug 10 05:04:28 testmachine local3:alert snort[1986722]: [1:9000000:1] American Express card number detected in clear text {TCP} 10.10.10.10:310 -> 20.20.20.20:20
 - Aug 10 05:04:28 testmachine local3:alert snort[1986722]: [1:9000000:1] MasterCard card number detected in clear text {TCP} 10.10.10.10:310 -> 20.20.20.20:20
 - Aug 10 05:04:28 testmachine local3:alert snort[1986722]: [1:9000000:1] VISA card number detected in clear text {TCP} 10.10.10.10:310 -> 20.20.20.20:20
 - Aug 10 12:01:50 testmachine local3:alert snort[1986722]: [1:9000004:1] Social Security number detected in clear text {TCP} 10.10.10.10:310 -> 20.20.20.20:20
 - Matt Jezorek
-->
<decoder name="my-snort">
 <prematch>snort[\d+]:\s+[\d+:\d+:\d+]</prematch>
 <regex offset="after_prematch">{(\S+)}\s+(\d+.\d+.\d+.\d+):(\d+)\s+->\s+(\d+.\d+.\d+.\d+):(\d+)</regex>
 <order>protocol,srcip,srcport,dstip,dstport</order>
</decoder>

After we have our decoder we can now go to $OSSEC_HOME/rules/local_rules.xml and add our rules which would look like this:

<group name="snort,syslog,">
 <rule id="110000" level="3">
  <decoded_as>my-snort</decoded_as>
  <description>SNORT IDS Alerts</description>
 </rule>

 <rule id="110001" level="5">
  <if_sid>110000</if_sid>
  <match>VISA</match>
  <options>alert_by_email</options>
  <description>VISA card number transmited in clear text</description>
 </rule>

 <rule id="110002" level="5">
  <if_sid>110000</if_sid>
  <match>MasterCard</match>
  <options>alert_by_email</options>
  <description>MasterCard number transmited in clear text</description>
 </rule>

 <rule id="110003" level="5">
  <if_sid>110000</if_sid>
  <match>American Express</match>
  <options>alert_by_email</options>
  <description>American Express number transmited in clear text</description>
 </rule>

 <rule id="110004" level="5">
  <if_sid>110000</if_sid>
  <match>Social Security</match>
  <options>alert_by_email</options>
  <description>Social Security Number transmited in clear text</description>
 </rule>
</group>

We can modify these rules as we see fit and make sure that they are the levels we want. One thing please do not do what I did, I put the alerts at a level 10 this triggered active response and blocked everything from talking to this machine, keep your alert levels below your active response threshold unless you want to block people.
For reference sake if you are reading this and saying well I get alerts all the time that are level 10 and they do not get blocked, I submit the following reply “They do not contain a source ip”. The active response of adding to the firewall requires a source ip so if no source ip is available it will not trigger active response. Since our decoder will give a source ip address we will be able to trigger active response. I have seen a lot of people giving tutorials about how to integrate this with OSSEC and that with OSSEC and all of them seem to make alerts at level 10 and provide a source ip but they never seem to mention that active response can be a problem with this.