I think we rely on user contributions for portsentry logs. Try changing portsentry-scan to look like this: <decoder name="portsentry-scan"> <parent>portsentry</parent> <prematch>^attackalert: TCP |^attackalert: UDP </prematch> <regex offset="after_prematch">scan from host: (\S+)/\S+ to \S+ port: (\d+)$</regex> <order>srcip, dstport</order> </decoder>
On Fri, Jul 29, 2011 at 4:30 AM, Blauch Armand <[email protected]> wrote: > Hello, > > I just want to add that the default decoder for portsentry on the 2.6 > released maybe don't pay attention at the good log lines (in my > opinion!) and if I underestant well the process. > > My portsentry logs are like this (on Ubuntu, Suse and Redhat), > depending on the portscan (udp, tcp, xmas, fin...): > ************************************************************************** > Jul 28 17:10:18 testdev portsentry[9166]: attackalert: Host: > 192.168.18.22/192.168.18.22 is already blocked Ignoring > Jul 29 09:19:30 testdev portsentry[25522]: attackalert: Host: > 192.168.18.22/192.168.18.22 is already blocked Ignoring > Jul 29 09:19:30 testdev portsentry[25522]: attackalert: TCP NULL scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 804 > Jul 29 09:45:07 testdev portsentry[779]: attackalert: Host: > 192.168.18.22/192.168.18.22 is already blocked Ignoring > Jul 29 09:45:07 testdev portsentry[779]: attackalert: TCP FIN scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 23 > Jul 29 09:45:07 testdev portsentry[779]: attackalert: TCP FIN scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 636 > Jul 29 09:45:27 testdev portsentry[779]: attackalert: TCP XMAS scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 50 > Jul 29 09:45:27 testdev portsentry[779]: attackalert: TCP XMAS scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 1023 > Jul 29 09:45:27 testdev portsentry[779]: attackalert: TCP XMAS scan > from host: 192.168.18.22/192.168.18.22 to TCP port: 251 > Jul 29 09:49:22 testdev portsentry[782]: attackalert: UDP scan from > host: 192.168.18.22/192.168.18.22 to UDP port: 541 > Jul 29 09:49:22 testdev portsentry[782]: attackalert: Host: > 192.168.18.22/192.168.18.22 is already blocked Ignoring > Jul 29 09:49:22 testdev portsentry[782]: attackalert: UDP scan from > host: 192.168.18.22/192.168.18.22 to UDP port: 135 > ************************************************************************** > > And default decoder for portsentry is like this: > ************************************************************************* > <decoder name="portsentry"> > <program_name>^portsentry</program_name> > </decoder> > > <decoder name="portsentry-attackalert"> > <parent>portsentry</parent> > <prematch>attackalert: Connect from host: </prematch> > <regex offset="after_prematch">(\S+)/\S+ to (\S+) port: (\d+)$</ > regex> > <order>srcip,protocol,dstport</order> > </decoder> > > <decoder name="portsentry-blocked"> > <parent>portsentry</parent> > <prematch>is already blocked. Ignoring$</prematch> > <regex>Host: (\S+) is</regex> > <order>srcip</order> > </decoder> > ************************************************************************** > > It seems that decoder don't extract the srcip, proto and dstport, I > don't have these values with ossec-logtest. > > If I change prematch by: <prematch>have been scanned from </prematch> > on decoder "portsentry-attackalert", it works fine. I have the srcip, > proto and dstport values. > > May be some people has other kind of logs with "Connect from host:" > words? > > > On 28 juil, 17:29, Blauch Armand <[email protected]> wrote: >> Thanks! >> I had not thought of this possibility, next time I check. >> Sorry. >> >> On 28 juil, 17:13, Daniel Cid <[email protected]> wrote: >> >> >> >> >> >> >> >> > Hey, >> >> > The issue is that the portsentry-attackalert was added to the release >> > already :) So it fails due to the >> > duplicated names... >> >> > Thanks, >> >> > -- >> > Daniel B. Cid >> > dcid @ ossec.net >> >> > On Thu, Jul 28, 2011 at 11:56 AM, Blauch Armand <[email protected]> wrote: >> > > Hello, >> >> > > I've tested before OSSEC 2.5 and I've use some decoder for porsentry. >> > > When I tried these decoders on OSSEC 2.6 I have some mistakes like >> > > theses: >> > > ******************************************************************* >> > > Started ossec-remoted... >> > > 2011/07/28 16:42:04 ossec-syscheckd(1210): ERROR: Queue '/etc/ossec/ >> > > queue/ossec/queue' not accessible: 'Connection refused'. >> > > 2011/07/28 16:42:04 ossec-rootcheck(1210): ERROR: Queue '/etc/ossec/ >> > > queue/ossec/queue' not accessible: 'Connection refused'. >> > > 2011/07/28 16:42:12 ossec-syscheckd(1210): ERROR: Queue '/etc/ossec/ >> > > queue/ossec/queue' not accessible: 'Connection refused'. >> > > 2011/07/28 16:42:12 ossec-rootcheck(1210): ERROR: Queue '/etc/ossec/ >> > > queue/ossec/queue' not accessible: 'Connection refused'. >> > > 2011/07/28 16:42:25 ossec-syscheckd(1210): ERROR: Queue '/etc/ossec/ >> > > queue/ossec/queue' not accessible: 'Connection refused'. >> > > 2011/07/28 16:42:25 ossec-rootcheck(1211): ERROR: Unable to access >> > > queue: '/etc/ossec/queue/ossec/queue'. Giving up.. >> > > ***************************************************************** >> >> > > I tried many, many things, and I find my error, the new ossec 2.6 >> > > doesn't accept anymore the "-" in the decoder name. >> >> > > When my decoder name is <decoder name="portsentry-attackalert">, ossec >> > > doesn't want to restart. >> > > When my decoder name is <decoder name="portsentryattackalert"> ossec >> > > restart without any problem. >> > > When my decoder name is <decoder name="portsentryattackalert2"> ossec >> > > restart without any problem. >> >> > > I'm sorry if this issue was already documented, I haven't find the >> > > explanation on ossec website or in the 2.6 "What is new?" web page. >> > > May be this can help somebody. >> >> > > It is normal? or it's a "bug" of the 2.6 release?
