Thanks! Running the snapshot now. It looks good. I took a look at the new decode. Quite a bit more complex now, but I do have a better understanding of the decoder.xml.
Thanks,
On Sun, 2006-08-20 at 17:26 -0300, Daniel Cid wrote:
Hi Scott, I will try to answer both of your e-mails in here. First, you found a bug in the iptables decoder :) The action is missing for some reason, so it is being assigned as the srcip and the srcip is being assigned the dstip (what a mess). I think this problem happened when I merged the decoders and added the "offset" options... Because of that I also found a small bug in the decoders and fixed everything in the latest snapshot: http://www.ossec.net/files/snapshots/ossec-hids-060820.tar.gz Can you give it a try to see if it works now? I tried using your logs and it worked fine. About the regexes, you guys (Gentuxx and Scott) are right. Our regexes are somewhat perl compatible, but not fully. We only support what is in the wiki (thanks gentux). Basically, we have our own regex library for performance reasons, since both PCRE and the posix regexes support a lot of stuff not needed by us and they always try the "best pattern" algorithm, which is *slow... *For example, if you do "\d+\w+" against "12awbc12345677888wwwwwwww", ossec will match on "12a", while PCRE or posix regex will match on "12 awbc12345677888wwwwwwww".. Hope it helps.. -- Daniel B. Cid dcid ( at ) ossec.net On 8/19/06, G E Scott Knauss <[EMAIL PROTECTED]> wrote: > > > Is anyone else seeing this problem ? I've played with the decoder rules a bit, I'm fairly certain I understand them, but no matter what I do, I always get UNKNOWN for the srcip and (null) for the action. Although admittedly, I don't see where the decoder gets the action ... Here's how I think it works ????? > > <decoder name="iptables"> ### defines the decoder rule name > <type>firewall</type> ### type of rule. > <prematch>^kernel: [\d+.\d+] \S+ IN=|^kernel: \S+ IN=eth0 OUT=</prematch> ### how to determine if log line fits for this rule > > <regex offset="after_prematch"> MAC=\.+ SRC="" DST=(\S+) \.+ </regex> ### begins marking variables. each portion in () is a variable > <regex>PROTO=(\w+) SPT=(\d+) DPT=(\d+) </regex> ### More variables > <order>action,srcip,dstip,protocol,srcport,dstport</order> ### the variable names in the order they show as defined by the () > </decoder> > > (this is not the default iptables decoder entry,) However it works the same way. It would seem to me that the regex defines the entire line from the log ???? Is that correct ? isolating portions with (). These portions are then exported in the order specified in the last line. Also, I'm guessing at what all of the escape secquences are based on the sample logs in the decoder XML. Is there a list of them somewhere ? I couldn't find any of the ones in the decoder.xml in any of the normal places I look for regex help ... (man regex, man grep) > > Thanks, > > > > > > > > On Thu, 2006-08-17 at 11:18 +0200, G E Scott Knauss wrote: > > I've read the posts on the decoder.xml, but I still can't quite figure out what is going on here... As I understand it, the second rule in the default firewall rules should fire if there are more than 16 hits in from the same IP in 45 seconds. So if I insane nmap from a machine, it should get blocked right ? > > Its not ... > > I think the decoder is missing the srcip from my firewall log. I'm runing SuSE10.1 and the default SuSEfirewall2. Nothing fancy on this box for the firewall rules. Here's a sample from the syslog firewall.log: > > Aug 17 10:03:37 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=28 TOS=0x00 PREC=0x00 TTL=44 ID=60200 PROTO=ICMP TYPE=8 CODE=0 ID=10466 SEQ=21229 > Aug 17 10:03:37 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=46512 PROTO=TCP SPT=56113 DPT=80 WINDOW=3072 RES=0x00 ACK URGP=0 > Aug 17 10:03:37 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=28 TOS=0x00 PREC=0x00 TTL=51 ID=11781 PROTO=ICMP TYPE=8 CODE=0 ID=10466 SEQ=21485 > Aug 17 10:03:37 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=55879 PROTO=TCP SPT=56109 DPT=80 WINDOW=3072 RES=0x00 ACK URGP=0 > Aug 17 10:03:58 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=28 TOS=0x00 PREC=0x00 TTL=55 ID=18094 PROTO=ICMP TYPE=8 CODE=0 ID=33513 SEQ=11805 > Aug 17 10:03:58 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=40 TOS=0x00 PREC=0x00 TTL=44 ID=48370 PROTO=TCP SPT=54589 DPT=80 WINDOW=2048 RES=0x00 ACK URGP=0 > Aug 17 10:03:58 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=28 TOS=0x00 PREC=0x00 TTL=44 ID=39406 PROTO=ICMP TYPE=8 CODE=0 ID=33513 SEQ=12061 > Aug 17 10:03:58 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=40 TOS=0x00 PREC=0x00 TTL=41 ID=15291 PROTO=TCP SPT=54590 DPT=80 WINDOW=3072 RES=0x00 ACK URGP=0 > Aug 17 10:05:01 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=446 TOS=0x00 PREC=0x00 TTL=45 ID=23451 DF PROTO=TCP SPT=80 DPT=10634 WINDOW=1716 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A6B711D860028094B) > Aug 17 10:05:09 myhostname kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:08:02:da:c8:51:00:0f:f7:74:31:8a:08:00 SRC= "" DST=1.2.3.194 LEN=446 TOS=0x00 PREC=0x00 TTL=45 ID=38538 DF PROTO=TCP SPT=80 DPT=1595 WINDOW=1716 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A6B713B4F002813F7) > > > > > However, if I look at the ossec firewall log in /opt/ossec/logs/firewall/firewall.log, all of the entries look like this ..... > > 2006 Aug 17 10:02:19 UNKNOWN 80 1.2.3.194:10634->TCP:(null) > 2006 Aug 17 10:02:29 UNKNOWN 80 1.2.3.194:1595->TCP:(null) > 2006 Aug 17 10:03:13 UNKNOWN 80 1.2.3.194:10634->TCP:(null) > 2006 Aug 17 10:03:23 UNKNOWN 80 1.2.3.194:1595->TCP:(null) > 2006 Aug 17 10:03:39 UNKNOWN 56113 1.2.3.194:80->TCP:(null) > 2006 Aug 17 10:03:39 UNKNOWN 56109 1.2.3.194:80->TCP:(null) > 2006 Aug 17 10:03:59 UNKNOWN 54589 1.2.3.194:80->TCP:(null) > 2006 Aug 17 10:03:59 UNKNOWN 54590 1.2.3.194:80->TCP:(null) > 2006 Aug 17 10:05:03 UNKNOWN 80 1.2.3.194:10634->TCP:(null) > 2006 Aug 17 10:05:11 UNKNOWN 80 1.2.3.194:1595->TCP:(null) > > I'm guessing this may have something to do with the options SuSE gives to all of the log statements ? (LOG flags 6 level 4 prefix someprefix) > > > Thanks, > > > > > > > G E Scott Knauss [EMAIL PROTECTED] or [EMAIL PROTECTED] > ECRNOC Naples, IT [EMAIL PROTECTED] > Lead Network Engineer > DSN: 314-626-4854 > Comm: 39-333-224-9323 > Cell: 39-333-224-9323 > > G E Scott Knauss [EMAIL PROTECTED] or [EMAIL PROTECTED] > ECRNOC Naples, IT [EMAIL PROTECTED] > Lead Network Engineer > DSN: 314-626-4854 > Comm: 39-333-224-9323 > Cell: 39-333-224-9323 >
