<< Click to Display Table of Contents >> Navigation:  Event and Object Analysis > Capture Results Filtering > Filter Use Cases > Use of both HTTP filter and message filter

Problem

If the message is received or sent using the HTTP GET method, and the server address is in the dnsbl list (for example, dnsbl.sorbs.net), the message should be labeled as "possible malware or proxy".

Solution Logic

Check HTTP request method using the HTTP filter. To make sure the server address is in a DNSBL list, we need to use the message filter. Therefore, two filters will form the solution of the entire problem: the HTTP filter and the message filter. The HTTP filter will check the GET method and label all GET requests (for example, as "HTTP_GET").

The label will be kept in messages extracted from these requests and will become available in the message filter. For all messages that have "HTTP_GET" label, the message filter will check if the server address is in a DNSBL list. To do this, it completes "dnsbl" action. If the server address is in a DNSBL list, the message will get a second label (for example, "DNSBL_EXIST"). Then the message filter will have to check two labels for each message ("HTTP_GET" and "DNSBL_EXIST") and set "possible malware or proxy" label for messages that have both.

For the "dnsbl" action to work correctly, we need to set up DNS servers to check DNSBL in the EtherSensor Analyser service configuration.

Solution

1. Set up DNS servers in the EtherSensor Analyser service configuration to check DNSBL.

You can do this in the configuration tool or the configuration file.

In the EtherSensor Analyser service configuration file:

<AnalyserConfig> root tag, then <RawHttpFilter> nested tag - enable HTTP filter. The <Filter> filter settings tag (enable message filter). Then the nested <DnsBl> tag - DNS server settings to check addresses in DNSBL lists in the message filter.

<?xml version="1.0" encoding="utf-8"?>
<AnalyserConfig version="3.2">
 
<!-- other service settings -->
 <RawHttpFilter enabled="true" filename="http-filter.xml" />
 <Filter enabled="true" filename="msg_filter.xml">
 
<!-- other filter settings -->
 
   <DnsBl>
     <AttemptsCount>3</AttemptsCount>
     <TtlForUnknown>3600</TtlForUnknown>
     <MinTtl>300</MinTtl>
     <MaxTtl>604800</MaxTtl>
     <Server ipaddress="127.0.0.1" port="53" />
   </DnsBl>
 
 </Filter>
</AnalyserConfig>

Here we assume that the DNS server's IP address is 127.0.0.1:53.

2. The HTTP filter file may look like this (http-filter.xml):

<?xml version="1.0" encoding="utf-8"?>
<filter name="HTTP filter" version="1.0">
 
 <table name="main">
 
   <rule enabled="true">
     <match>
       <c name="method" value="GET"/>
     </match>
     <action name="tag" value="HTTP_GET"/>
   </rule>
 
   <rule enabled="true">
     <action name="accept" />
   </rule>
 </table>
</filter>

For a detailed description of the "method" filtering condition and the "tag" action, refer to "METHOD Condition" and "TAG Action"sections.

3. The message filter file may look like this (msg_filter.xml):

<?xml version="1.0" encoding="utf-8"?>
<filter name="Message filter" version="1.0">
 
 <table name="main">
 
   <rule enabled="true">
     <match>
       <c name="tag" tag="HTTP_GET"/>
     </match>
     <action name="dnsbl-rh"
             address="both"
             tag="DNSBL_EXIST"
             value="dnsbl.sorbs.net" />
   </rule>
 
   <rule enabled="true">
     <match>
       <and>
         <c name="tag" tag="HTTP_GET"/>
         <c name="tag" tag="DNSBL_EXIST"/>
       </and>
     </match>
     <action name="tag" value="MALWARE_OR_PROXY"/>
   </rule>
 
 </table>
</filter>

For a detailed description of the "tag" condition, "tag" action and the "dnsbl" action, refer to "TAG Condition", "TAG Action" and "DNSBL-LH, DNSBL-RH Action" sections.

Comments and General Recommendations

1. For faster DNS name resolution, it is recommended to specify the fastest DNS servers in the EtherSensor Analyser service configuration. These may be your ISP servers or your own DNS servers.

2. "dnsbl" action (DNS name resolution for DNSBL) is a lengthy operation (especially if you specify several DNSBL services to use); for this reason, make sure you run it in the filter only for the message that really require this.

3. Try to run the "dnsbl" action at the end of the filter where its results are required.

4. Remember that at the stage of the HTTP filtering, messages don't exist; the traffic will be checked for these messages later. However, at this stage labels and tags set for requests will be saved to the message (if the message is extracted from these requests).