[Oisf-users] VLAN info and unified2 logs

[Eric Leblond]

Hello,

This is an excellent point. Explanation below.

On Wed, 2014-09-10 at 12:16 +0200, Carlos Terrón wrote:
> 
> 
> Hi
> 
> 
> I have some problems retrieving log info about events fired by network
> packets encapsulate  in VLAN. I have monitoring traffic in a tagged
> vlan, and sometimes, the unified2 logs have info about the VLAN
> packets, sometimes no.
> 
> 
> In my setup I have a a computer connected to a switch port with a
> tagged vlan. There are events that were stored in the unified2 with
> the VLAN info. For example,  if Suricata detects traffic that fire up
> this rule
> 
> 
> ET POLICY Dropbox Client Broadcasting [**] [Classification: Potential
> Corporate Privacy Violation] [Priority: 
> 1] {UDP} 192.168.x.x:17500 -> 255.255.255.255:17500
> 
> 
> Using barnyard2 to obtain the pcap capture of the event, I see the
> next info:
> 
> 
> 08:32:10.545100 68:5b:35:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype
> 802.1Q (0x8100), length 199: vlan 2, p 0, ethertype IPv4,
> 192.168.9.4.17500 > 255.255.2
> 55.255.17500: UDP, length 153
> 
> 
> I see correctly the VLAN information in the packet.
> 
> 
> But when Suricata fire up this rule  (downloading a exploit from
> www.explout-db.com)
> 
> 
> 09/09-08:32:13.920616  [**] [1:2011346:7] ET SHELLCODE Possible
> Unescape %u Shellcode/Heap Spray [**] [Classification: Executable Code
> was Detected] [Priority: 1] {TCP} 198.58.102.135:80 ->
> 192.168.x.x:59703
> 
> 
> And I analyze the pcap capture:
> 
> 
> 08:32:13.920616 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 471: 198.58.102.135.80 > 192.168.x.x.59703: Flags [],
> seq 0:417, 
> win 0, length 417
> 
> 
> There aren’t any info about
> 
> 
>       * VLAN
>       * Source MAC
>       * Destination MAC
> 
> 
> I don’t now if this is a configuration issue I have with Suricata or
> that Suricata doesn’t store VLAN info in certain fired rules.

This is not a configuration issue. The differences are due to the types of rule which are different.
First rule is 

alert udp $HOME_NET 17500 -> any 17500 (msg:"ET POLICY Dropbox Client
Broadcasting"; content:"{|22|host_int|22 3a| ";
...
depth:13;  sid:2012648; rev:3;)

Second one is

alert http $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET SHELLCODE
Possible 
Unescape %u Shellcode/Heap Spray"; flow:established,to_client;
content:"unescape";
...
pcre:"/unescape.+\x25u[0-9,a-f]{2,4}\x25u[0-9,a-f]{2,4}/smi"; 
reference:url,www.w3schools.com/jsref/jsref_unescape.asp; 
 classtype:shellcode-detect; 
sid:2011346; rev:7;)


So first one is matching on packet content and second one is a
application/stream alert. As the first one is matching on packet
content, the packet is available when generating the alert in unified2.
That's why you have real data in the ethernet part.

In the second case, the matching is done on stream. We don't have a the
real packet here as in IDS mode (opposed to inline mode) the detection
is run when the data in a stream has been acknowledge by the host. So we
don't have the real packet and don't know how is looking the ethernet
part. So suricata is generating an unified2 alerts for every stream part
filling the required ethernet part with 0.

BR,
-- 
Eric Leblond <eric at regit.org>