Dear Risto,
If i use SingleWithSuppress rule, can i count how many logs has been
suppressed in the time window?
Thanks
On Fri, Dec 27, 2013 at 11:48 PM, Risto Vaarandi <[email protected]>wrote:
> hi,
>
> from your log sample it appears that you have pfsense version which
> generates multiline messages, and relevant messages span over 2
> consecutive lines. For matching such events, you would need RegExp2
> pattern type. Also, are you interested in matching *all* pfsense
> messages or just those which concern blocked packets? If you want to
> process events for blocked packets only, your regular expression might
> look like follows:
>
> ptype=RegExp2
> pattern=pf: [\d.:]+ rule [\d/]+\(match\): block .* proto
> (\w+).*\n.*pf:\s+([\d.]+) > ([\d.]+)
>
> This regular expression will set $1 to protocol, $2 to source IP and
> port, and $3 to destination IP and port. Note that in the case of ICMP,
> the $2 and $3 variables will just hold IP addresses without port
> numbers. However, if you would like to assign port numbers to separate
> variables, you could also try:
>
> ptype=RegExp2
> pattern=pf: [\d.:]+ rule [\d/]+\(match\): block .* proto
> (\w+).*\n.*pf:\s+((?:\d+\.){3}\d+)(?:\.(\d+))? >
> ((?:\d+\.){3}\d+)(?:\.(\d+))?
>
> Also, you have to keep in mind that when you are doing multiline
> matching, it is recommended to start SEC with the --nojointbuf flag
> which will set up a separate input buffer for each input file. For example:
>
> sec --conf=/etc/sec/pfsense.rules --input=/var/log/pf.log --nojointbuf
>
> Without the --nojointbuf flag, lines from several input files and
> synthetic events would end up in a single input buffer which would break
> multi-line matching.
>
> Also, have I understood correctly that you would like to report only the
> first event for given source and destination endpoint, and suppress the
> following ones? If my understanding is correct, the best way would be to
> use SingleWithSuppress rule:
>
> type=SingleWithSuppress
> ptype=RegExp2
> pattern=pf: [\d.:]+ rule [\d/]+\(match\): block .* proto
> (\w+).*\n.*pf:\s+((?:\d+\.){3}\d+)(?:\.(\d+))? >
> ((?:\d+\.){3}\d+)(?:\.(\d+))?
> desc=Blocked packets for proto $1 srcIP $2 srcport $3 destIP $4 destport $5
> action=write - %s
> window=60
>
> The above rule reacts to the first event for some protocol ID, source
> and destination IP, and source and destination port, and ignores during
> 60 seconds the following events with the *same* protocol,
> source/destination IP, and source/destination port.
>
> However, this means that if from some IP address the same destination
> service is probed, using a different source port number, another output
> event is triggered. To prevent this from happening, you need to change
> the 'desc' field of the rule and exclude source port number from it:
>
> type=SingleWithSuppress
> ptype=RegExp2
> pattern=pf: [\d.:]+ rule [\d/]+\(match\): block .* proto
> (\w+).*\n.*pf:\s+((?:\d+\.){3}\d+)(?:\.(\d+))? >
> ((?:\d+\.){3}\d+)(?:\.(\d+))?
> desc=Blocked packets for proto $1 srcIP $2 destIP $4 destport $5
> action=write - %s
> window=60
>
> Also, if you would like to do repeated event suppression on IP address
> basis only, you could set the 'desc' field as follows:
>
> desc=Blocked packets for srcIP $2 destIP $4
>
> Now you would be getting just one output event for each unique pair of
> (sourceIP, destinationIP), no matter if the transport protocol or port
> numbers change during the 60 second period.
>
> Hope this helps,
> risto
>
>
> On 12/26/2013 02:53 PM, termvrl term wrote:
> > HI Thanks for your reply...
> >
> > I have another question, i am wondering what is the best rules type for
> > this situation,
> >
> > This is firewall logs form pfsense,
> >
> > Dec 17 23:25:05 192.168.0.120 pf: 00:00:13.146869 rule 62/0(match):
> > block in on em0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> > (17), length 92)
> > Dec 17 23:25:05 192.168.0.120 pf: 10.0.0.2.57185 > 192.168.0.112.53:
> > 26220 updateMA+ [b2&3=0x6f6f] [25600q] Type0 (Class 0)? . Type0 (Class
> > 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0
> > (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? .
> > Type0 (Class 0)? .[|domain]
> > Dec 17 23:25:05 192.168.0.120 pf: 00:00:00.000101 rule 62/0(match):
> > block in on em0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> > (17), length 92)
> > Dec 17 23:25:05 192.168.0.120 pf: 10.0.0.2.57185 > 192.168.0.112.53:
> > 26220 updateMA+ [b2&3=0x6f6f] [25600q] Type0 (Class 0)? . Type0 (Class
> > 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0
> > (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? . Type0 (Class 0)? .
> > Type0 (Class 0)? .[|domain]
> >
> > I want to already have the regex pattern to match with, but i not sure
> > to use which rule type.
> >
> > I want the final output would be like this,
> >
> > Firewall Alert - UDP Blocked. Source IP : 10.0.0.2 Port: 57185
> > Destination IP: 192.168.0.112 Destination Port: 53
> >
> > and can it be suppressed ?
> >
> >
> >
> > On Fri, Dec 20, 2013 at 4:20 AM, Risto Vaarandi
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > I had a look into your logs and to me the EventGroup2 rule is working
> > exactly it is supposed to. First, the rule will match the following
> > event:
> >
> > Dec 16 23:04:53 ubuntu apache-errors: [Mon Dec 16 23:04:50 2013]
> > [error] [client 192.168.0.119] ModSecurity: Warning. Pattern match
> >
> "(?i:([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\\\(\\\\)]*)?([\\\\d\\\\w]+)([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\\\(\\\\)]*)?(?:=|<=>|r?like|sounds\\\\s+like|regexp)([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\\\(\\\\)]*)?\\\\2|([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\
> > ..." at ARGS:name. [file
> >
> "/etc/modsecurity/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
> > [line "77"] [id "950901"] [rev "2.2.5"] [msg "SQL Injection Attack"]
> > [data "script>alert"] [severity "CRITICAL"] [tag
> > "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag
> > "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
> > [hostname "192.168.0.112"] [uri "/dvwa/vulnerabilities/xss_r/"]
> > [unique_id "Uq-3kn8AAQEAAANQBJ8AAAAE"]
> >
> > After seeing this event, the rule starts an event correlation
> > operation for the client 192.168.0.119 and uniqueID
> > Uq-3kn8AAQEAAANQBJ8AAAAE, with the lifetime of the operation being 60
> > seconds.
> > The rule will then match further SQL events for the same client and
> > unique ID, and they will therefore be all correlated by the
> previously
> > started operation.
> > Finally, the rule will match an XSS event for client 192.168.0.119
> and
> > uniqueID Uq-3kn8AAQEAAANQBJ8AAAAE, which will also handled by the
> > operation. At this point, the operation has seen at least 1 instance
> > of both events (described by pattern and pattern2) which will trigger
> > the execution of the rule action. After this, the rule will continue
> > running for the remainder of the 60 second correlation window,
> > terminating at 23:05:53. During this time frame, any further events
> > are silently consumed by the operation, without triggering any
> action.
> >
> > A similar event processing flow will take place at 23:11:43. This is
> > the reason why you are seeing only two "High probability XSS attacks"
> > events in the log.
> > (Also, it seems to me that your clocks are not very well
> synchronized
> > across systems, because at some points in time simultaneous events at
> > different systems are more than 2 minutes apart by their timestamps.)
> >
> > It seems to me that you have somehow misunderstood how EventGroup
> rule
> > operates. Have you looked into its documentation at
> > http://simple-evcorr.sourceforge.net/man.html#lbAR ? This section of
> > the docs contains an example how EventGroup rule can reset the
> > counting process immediately after triggering the action. If this is
> > what you want to do, I'd recommend to have a look into this example.
> >
> > regards, risto
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Simple-evcorr-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
> >
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
