Firewall log entries split across 2 lines?
c0 last edited by
I'm trying to sending my firewall logs to an OSSIM box I've been messing with and have been having a hard time getting OSSIM to interprete the logs. Looking at the pfsense firewall logs, they get split across 2 lines for whatever reason:
Aug 4 13:35:07 192.168.4.10 pf: 00:00:00.000016 rule 1/0(match): block in on em0: (tos 0x0, ttl 38, id 4474, offset 0, flags [none], proto TCP (6), length 40)
Aug 4 13:35:07 192.168.4.10 pf: 192.168.4.3.36115 > 192.168.4.10.1259: Flags [.], cksum 0x62c5 (correct), ack 2003742276, win 3072, length 0
While OSSIM is expecting to see something like this:
Nov 23 16:50:37 192.168.1.2 pf: 927014 rule 142/0(match): block in on rl1: (tos 0x0, ttl 114, id 49298, offset 0, flags [none], proto: TCP (6), length 52) 126.96.36.199.64686 > 192.168.241.5.1500: S, cksum 0x4c19 (correct), 2825964646:2825964646(0) win 8192 <mss 1432,nop,wscale="" 2,nop,nop,sackok="">Any reason why pfsense splits the log entry like this? and is there any way to configure it differently?
That's how the log are in the OS - we didn't do that.
We had to code around that in 2.0, the log parser was a bit of fun to do with that…
Whatever parses the pf logs in your software needs updated to account for that.
c0 last edited by
Thanks for the response… kind of what expected :(
I think the problem I'm going to run into is that there's no definitive way to link those 2 separate log lines on the recieving syslog server since there's no identifier that says the 2 lines are really the same log entry. While I could try assuming that sequential lines are really the same entry, what happens during heavy traffic loads (like a port scan)... is it possible those lines could end up out of sequence on the recieving syslog server? I'm also not sure how customizable OSSIM is for pairing different syslog entries together, but I'll take another look at it. Any hints as to how you did it with the log parser?
It sucks since the only thing I really care about from the 1st line of the Protocol being used... all the rest of the goodies are really already in that 2nd line (source, destination, port).
I'm pretty new to BSD... any idea why they did it this way? I'm assuming this was different in pfsense 1.x?
Look at our log parsing code (in /etc/inc/filter_log.inc) there are definitely ways to know if a line is a single entry or a continuation.
They couldn't end up out of sequence that I'm aware of, but when doing UDP syslog across the network, anything is possible.
Most software like that should have some code for actually parsing the logs that can be edited/hacked/adjusted/etc.