[Oisf-devel] [PATCH] numlog: new alert output

[Victor Julien]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/01/2011 04:39 PM, Eric Leblond wrote:
> Hello,
> 
> On Sat, 2011-10-01 at 15:43 +0200, Victor Julien wrote:
>> On 10/01/2011 02:14 AM, Eric Leblond wrote:
>>> Hello,
>>> 
>>> Attached to this mail is a patch which brings a new output
>>> module which aim is to provide a way to interact between
>>> suricata and pcap parser like wireshark. This is a line based
>>> logging with a very simple format: PKT_ID:SID:0:0:MSG The two
>>> zero values are to permit to indicate the byte start and byte
>>> end of the matches. This has not yet been done because it
>>> requires more modifications and it is more intrusive. Using the
>>> PKT_ID, pcap parsers can then easily do a link between suricata
>>> alerts and packets.
>>> 
>>> I've developed a wireshark plugin which uses this output to
>>> provide a clean and efficient way to add suricata alerts
>>> information inside wireshark:
>>> http://home.regit.org/software/suriwire/ This is currently in
>>> alpha stage but it is already usable.
>>> 
>>> BR,
>> 
>> Good stuff Eric!
> 
> Thanks
> 
>> I think the format could include a few more parts of info: - rev
>> and gid in addition to sid
> 
> Good idea.
> 
>> - http transaction id (I guess a generic tx id field)
> 
> Which structure is involved in that ? I've done a quick search
> without success.

Using AppLayerTransactionGetInspectId you can get the id of the
current tx. You should probably store it in the PacketAlert structure,
as by the time the alert is processed by your module it may have been
updated already.

>> A possible issue is that in certain conditions Suricata creates
>> pseudo packets: ending streams that time out, handling tunnels,
>> etc. In those cases the pcap_cnt will be 0.
> 
> Ok, in this case, I do not trigger an alert:
> 
> if (p->pcap_cnt != 0) {
> 
> Maybe, it could be interesting to log the alert the parent packet
> if it is not already done by suricata itself ?

This is not done currently. It's easy though the root packet is
accessable through p->root. It's read only after the initial setting
of it and it should never change during the lifetime of the
tunnel/pseudo packets. So access w/o a lock should be safe.

Btw, I think the name "numlog" is a bit non-descriptive. Maybe just
call it "wiresuri"? Maybe not ideal either.

- -- 
- ---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
- ---------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6HqxMACgkQiSMBBAuniMfTuQCeMzC42eVo/5KZ5OK23He5uIyn
ksIAn39g3MeVbE2uapt+ed2mJNvvp3Tr
=RMrx
-----END PGP SIGNATURE-----