Hello, I've just tried what you advice me, and it's work fine! Thank you!
On 29 juil, 15:20, "dan (ddp)" <[email protected]> wrote: > I think we rely on user contributions forportsentrylogs. > Try changingportsentry-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 forportsentryon the 2.6 > > released maybe don't pay attention at the good log lines (in my > > opinion!) and if I underestant well the process. > > > Myportsentrylogs are like this (on Ubuntu, Suse and Redhat), > > depending on the portscan (udp, tcp, xmas, fin...): > > ************************************************************************** > > Jul 28 17:10:18 testdevportsentry[9166]: attackalert: Host: > > 192.168.18.22/192.168.18.22 is already blocked Ignoring > > Jul 29 09:19:30 testdevportsentry[25522]: attackalert: Host: > > 192.168.18.22/192.168.18.22 is already blocked Ignoring > > Jul 29 09:19:30 testdevportsentry[25522]: attackalert: TCP NULL scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 804 > > Jul 29 09:45:07 testdevportsentry[779]: attackalert: Host: > > 192.168.18.22/192.168.18.22 is already blocked Ignoring > > Jul 29 09:45:07 testdevportsentry[779]: attackalert: TCP FIN scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 23 > > Jul 29 09:45:07 testdevportsentry[779]: attackalert: TCP FIN scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 636 > > Jul 29 09:45:27 testdevportsentry[779]: attackalert: TCP XMAS scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 50 > > Jul 29 09:45:27 testdevportsentry[779]: attackalert: TCP XMAS scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 1023 > > Jul 29 09:45:27 testdevportsentry[779]: attackalert: TCP XMAS scan > > from host: 192.168.18.22/192.168.18.22 to TCP port: 251 > > Jul 29 09:49:22 testdevportsentry[782]: attackalert: UDP scan from > > host: 192.168.18.22/192.168.18.22 to UDP port: 541 > > Jul 29 09:49:22 testdevportsentry[782]: attackalert: Host: > > 192.168.18.22/192.168.18.22 is already blocked Ignoring > > Jul 29 09:49:22 testdevportsentry[782]: attackalert: UDP scan from > > host: 192.168.18.22/192.168.18.22 to UDP port: 135 > > ************************************************************************** > > > And default decoder forportsentryis 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 theportsentry-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?
