Re: [ossec-list] Re: Whitelisting the IP of an internal vulnerability scanner
and 11000 are set to the same level, my guess is that it's the order in which your rules are loading - but I can't say for sure. But simply set your rule to either level="0" or level ="15" and you should be fine. - Bruce On Tuesday, March 10, 2020 at 4:32:04 PM UTC-4, Olivier Ragain wrote: > > Hi, > I've changed: > > 1 > 8 > > and i ve changed the rule to : > > > 7 > no_email_alert > *my_ip_scanner* > Ignoring all alerts triggered by our > scanner > > > > The alert is triggered by: Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: > Bad protocol version identification '\026\003\001\003\241\001' from > *my_scanner_ip* port 36632 > > The result of the test is: > **Phase 1: Completed pre-decoding. >full event: 'Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad > protocol version identification '\026\003\001\003\241\001' from > my_scanner_ip port 36632' >hostname: 'a-sv-prd-oss-01' >program_name: 'sshd' >log: 'Bad protocol version identification > '\026\003\001\003\241\001' from my_scanner_ip port 36632' > > **Phase 2: Completed decoding. >decoder: 'sshd' > > **Rule debugging: > Trying rule: 1 - Generic template for all syslog rules. >*Rule 1 matched. >*Trying child rules. > Trying rule: 5500 - Grouping of the pam_unix rules. > Trying rule: 5700 - SSHD messages grouped. >*Rule 5700 matched. >*Trying child rules. > Trying rule: 5709 - Useless SSHD message without an user/ip and > context. > Trying rule: 5711 - Useless/Duplicated SSHD message without a user/ip. > Trying rule: 5721 - System disconnected from sshd. > Trying rule: 5722 - ssh connection closed. > Trying rule: 5723 - SSHD key error. > Trying rule: 5724 - SSHD key error. > Trying rule: 5725 - Host ungracefully disconnected. > Trying rule: 5727 - Attempt to start sshd when something already bound > to the port. > Trying rule: 5729 - Debug message. > Trying rule: 5732 - Possible port forwarding failure. > Trying rule: 5733 - User entered incorrect password. > Trying rule: 5734 - sshd could not load one or more host keys. > Trying rule: 5735 - Failed write due to one host disappearing. > Trying rule: 5736 - Connection reset or aborted. > Trying rule: 5707 - OpenSSH challenge-response exploit. > Trying rule: 5701 - Possible attack on the ssh server (or version > gathering). >*Rule 5701 matched. >*Trying child rules. > Trying rule: 11 - Ignoring all alerts triggered by our scanner > > **Phase 3: Completed filtering (rules). >Rule id: '5701' >Level: '8' >Description: 'Possible attack on the ssh server (or version > gathering).' > **Alert to be generated. > > -- > > > So somehow that rule is being triggered but OSSEC does not know the source > so it matches it ? > > Should I just add a regular expression to the above rule so that it works > whether on Source IP or on the text ? > > Thanks > > > On Tue, Mar 10, 2020 at 2:37 PM Bruce Westbrook > wrote: > >> Since you created the rule as level="0", the >> no_email_alert line doesn't matter and you can leave >> it out. When you set a rule to level 0 it doesn't log or alert anyway, >> plus level 0 doesn't get overridden by a higher level rule so that's not >> the issue. >> >> Check the alert level of the alerts you're getting. If they are lower >> than 7 then you have your OSSEC config alerting on lower level rules. >> You'll just have to modify the rule's to match your global >> alert level. If you want to drop and not log anything you could just set >> it as 0. >> >> To test the rule, copy the content of the alert, and on your OSSEC server >> execute: >> ossec-logtest -v >> >> ...then paste the alert content and hit [ENTER]. The output will walk >> through the rules it is checking against. Use this output to help >> troubleshoot. >> >> - Bruce >> >> >> On Tuesday, March 10, 2020 at 12:34:41 PM UTC-4, Olivier Ragain wrote: >>> >>> Hi, >>> I ve configured ossec to load rules from a custom folder to avoid having >>> to touch any of the other files and facilitate updates. Some rules that are >>> in that custom folder work properly >>> So i've added the following in a custom rule file: >>> >>> >>> >>> 7 >>> n
Re: [ossec-list] Re: Whitelisting the IP of an internal vulnerability scanner
Since you created the rule as level="0", the no_email_alert line doesn't matter and you can leave it out. When you set a rule to level 0 it doesn't log or alert anyway, plus level 0 doesn't get overridden by a higher level rule so that's not the issue. Check the alert level of the alerts you're getting. If they are lower than 7 then you have your OSSEC config alerting on lower level rules. You'll just have to modify the rule's to match your global alert level. If you want to drop and not log anything you could just set it as 0. To test the rule, copy the content of the alert, and on your OSSEC server execute: ossec-logtest -v ...then paste the alert content and hit [ENTER]. The output will walk through the rules it is checking against. Use this output to help troubleshoot. - Bruce On Tuesday, March 10, 2020 at 12:34:41 PM UTC-4, Olivier Ragain wrote: > > Hi, > I ve configured ossec to load rules from a custom folder to avoid having > to touch any of the other files and facilitate updates. Some rules that are > in that custom folder work properly > So i've added the following in a custom rule file: > > > > 7 > no_email_alert > my_scanner_ip > Ignoring all alerts triggered by our > scanner > > > --- > Unfortunately I am still getting alerts by email. How can I test that rule > via the tester ? > Thanks > > > On Thu, Mar 5, 2020 at 10:30 AM 'Binet, Valere (NIH/NIA/IRP) [C]' via > ossec-list > wrote: > >> The whitelist works with active response. If you have OSSEC blocking >> misbehaving IPs on your firewall, you definitely have to whitelist the >> scanner IP. Past experience with one scanner I won’t promote here has shown >> that you might have to also whitelist its FQDN. >> >> If you just want to stop the deluge of emails, a local rule as shown by >> Bruce is the way to go. >> >> >> >> Valère Binet >> >> >> >> *From: *Bruce Westbrook > >> *Reply-To: *"ossec...@googlegroups.com " < >> ossec...@googlegroups.com > >> *Date: *Thursday, March 5, 2020 at 9:04 AM >> *To: *ossec-list > >> *Subject: *[ossec-list] Re: Whitelisting the IP of an internal >> vulnerability scanner >> >> >> >> oops -- I made a typo. The second example should be 7 >> too, not level 1. >> >> >> >> You can use level 1 but that will ignore everything from the source IP >> and not log anything at all. >> >> >> >> >> >> On Thursday, March 5, 2020 at 8:59:59 AM UTC-5, Bruce Westbrook wrote: >> >> Morning, >> >> >> >> Couple of ways to do this for just a single IP address. It depends on >> whether you just want to skip the emails alerts but still keep alerts in >> your database, or if you want to ignore them completely. >> >> >> >> Examples assume you have your email alerts set to level 7 or above. Note >> that matches rules at the given level or anything above it. >> >> >> >> To skip emails but still keep the alert data: >> >> >> >> >> 7 >> no_email_alert >> 10.10.10.10 >> Do not send emails for our scanner alerts >> >> >> >> >> >> >> >> >> To ignore all rule matches completely, set your rule to level 0: >> >> >> >> >> 1 >> 10.10.10.10 >> Ignoring all alerts triggered by our scanner >> >> >> >> >> >> >> >> Personally I use the second example, which ignores sending any alerts and >> doesn't even log them, but still logs any non-email events (levels 1-6) so >> I can still prove to an auditor that the scans are actually running against >> various hosts (some auditors want multiple proof points like that). >> >> >> >> Hope that helps! >> >> - Bruce >> >> >> On Thursday, March 5, 2020 at 8:42:01 AM UTC-5, Olivier Ragain wrote: >> >> Good morning, >> >> I've been trying to whitelist the IP of my scanner so that I never get >> notifications from it and that alerts are ignored for it. >> >> I've tried adding it to the whitelist in the ossec configuration file >> (And as I understand, that configuration is not used for the notification >> whitelisting) >> >> I've tried adding as a list and then added to the ossec configuration >> >> >> >> So, what is the best way to
[ossec-list] Re: Whitelisting the IP of an internal vulnerability scanner
oops -- I made a typo. The second example should be 7 too, not level 1. You can use level 1 but that will ignore everything from the source IP and not log anything at all. On Thursday, March 5, 2020 at 8:59:59 AM UTC-5, Bruce Westbrook wrote: > > Morning, > > Couple of ways to do this for just a single IP address. It depends on > whether you just want to skip the emails alerts but still keep alerts in > your database, or if you want to ignore them completely. > > Examples assume you have your email alerts set to level 7 or above. Note > that matches rules at the given level or anything above it. > > To skip emails but still keep the alert data: > > > 7 > no_email_alert > 10.10.10.10 > Do not send emails for our scanner alerts > > > > > To ignore all rule matches completely, set your rule to level 0: > > > 1 > 10.10.10.10 > Ignoring all alerts triggered by our scanner > > > > > Personally I use the second example, which ignores sending any alerts and > doesn't even log them, but still logs any non-email events (levels 1-6) so > I can still prove to an auditor that the scans are actually running against > various hosts (some auditors want multiple proof points like that). > > Hope that helps! > - Bruce > > > On Thursday, March 5, 2020 at 8:42:01 AM UTC-5, Olivier Ragain wrote: >> >> Good morning, >> I've been trying to whitelist the IP of my scanner so that I never get >> notifications from it and that alerts are ignored for it. >> I've tried adding it to the whitelist in the ossec configuration file >> (And as I understand, that configuration is not used for the notification >> whitelisting) >> I've tried adding as a list and then added to the ossec configuration >> >> So, what is the best way to whitelist a scanner IP so that nothing sends >> email for it? Do I need to create a custom rule that matches all rule IDs >> and the IP of the scanner host to disable email notifications? >> Thanks >> > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/85801125-b8d7-471b-869c-adea3d36cf2e%40googlegroups.com.
[ossec-list] Re: Whitelisting the IP of an internal vulnerability scanner
Morning, Couple of ways to do this for just a single IP address. It depends on whether you just want to skip the emails alerts but still keep alerts in your database, or if you want to ignore them completely. Examples assume you have your email alerts set to level 7 or above. Note that matches rules at the given level or anything above it. To skip emails but still keep the alert data: 7 no_email_alert 10.10.10.10 Do not send emails for our scanner alerts To ignore all rule matches completely, set your rule to level 0: 1 10.10.10.10 Ignoring all alerts triggered by our scanner Personally I use the second example, which ignores sending any alerts and doesn't even log them, but still logs any non-email events (levels 1-6) so I can still prove to an auditor that the scans are actually running against various hosts (some auditors want multiple proof points like that). Hope that helps! - Bruce On Thursday, March 5, 2020 at 8:42:01 AM UTC-5, Olivier Ragain wrote: > > Good morning, > I've been trying to whitelist the IP of my scanner so that I never get > notifications from it and that alerts are ignored for it. > I've tried adding it to the whitelist in the ossec configuration file (And > as I understand, that configuration is not used for the notification > whitelisting) > I've tried adding as a list and then added to the ossec configuration > > So, what is the best way to whitelist a scanner IP so that nothing sends > email for it? Do I need to create a custom rule that matches all rule IDs > and the IP of the scanner host to disable email notifications? > Thanks > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/146105a0-bfb1-4623-935b-4ed7f77d8e21%40googlegroups.com.
Re: [ossec-list] Composite Rule Not Firing
Thanks Dan. I tried your suggestion but no joy. I was still able to trigger rule #100554 nine times in less than 1 minute, but the composite rule still never fired. Interestingly ossec-logtest did NOT trigger it either. When I put my original composite rule back as well though, ossec-logtest did trigger that just fine. So I left them both in place, still never fires accept for mine with ossec-logtest. Here are the rules as they are now, including your suggestion: 18101 ^131$ Server accepted initial RDP session request sysadmin, 100554 ALERT: Potential RDP brute force attack recon,attacks, 18101 ^131$ ALERT: Potential RDP brute force attack sysadmin,recon,attacks, And just so it's said, I am doing an "*ossec-control restart*" when I change the rules so they get applied. :-) Thanks for taking a look at this head-scratcher. On Thursday, January 9, 2020 at 9:07:48 AM UTC-5, dan (ddpbsd) wrote: > > On Fri, Dec 20, 2019 at 12:15 PM Bruce Westbrook > wrote: > > > > I'm having an issue getting a composite rule to trigger. What's really > throwing me is that it works just fine when testing with ossec-logtest, but > it doesn't work live. > > > > Here are the two rules in question: > > > > > > 18101 > > ^131$ > > Server accepted initial RDP session > request > > sysadmin, > > > > > > > > 100554 > > ALERT: Potential RDP brute force attack > > sysadmin,recon,attacks, > > > > > > This seems like a silly idea, but it's the only one I have at the moment: > > 18101 > ^131$ > Server accepted initial RDP session request > sysadmin, > > > > 18101 > ^131$ > ALERT: Potential RDP brute force attack > sysadmin,recon,attacks, > > > I'll try to look into it more when I find some time. > > > > > ...and here is a sample log entry: > > > > 2019 Dec 20 11:28:59 WinEvtLog: > Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational: > INFORMATION(131): Microsoft-Windows-RemoteDesktopServices-RdpCoreTS: > NETWORK SERVICE: NT AUTHORITY: server.domain: The server accepted a new TCP > connection from client 10.104.248.199:57714. > > > > > > Using ossec-logtest I can enter this log entry and on the fifth time it > fires off rule #100560 just as expected. But when I make those same five > logon attempts to a live server, it only ever fires rule #100554. I've > tried this up to 20 times in under 2 minutes, well within the rule > timeframe, and it still never fires the composite rule alert, only 100554. > > > > I have quite a few other composite rules that I've written over the past > few years and don't have this issue. I just don't see what the problem is > with this one or why ossec-logtest shows it working but it never actually > works in a live situation. > > > > I'm running OSSEC HIDS v2.9.3 on Linux, with the agents on Windows 2012+ > servers. > > > > Any thoughts? > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "ossec-list" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to ossec...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ossec-list/db6d29a9-ec7d-4577-9ce6-d7ed445d8862%40googlegroups.com. > > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/f19d2857-2da1-4799-8981-e4da400b61fc%40googlegroups.com.
[ossec-list] Re: Composite Rule Not Firing
*bump* Anyone? On Friday, December 20, 2019 at 12:15:41 PM UTC-5, Bruce Westbrook wrote: > > I'm having an issue getting a composite rule to trigger. What's really > throwing me is that it works just fine when testing with ossec-logtest, but > it doesn't work live. > > Here are the two rules in question: > > > 18101 > ^131$ > Server accepted initial RDP session request > sysadmin, > > > > 100554 > ALERT: Potential RDP brute force attack > sysadmin,recon,attacks, > > > > ...and here is a sample log entry: > > 2019 Dec 20 11:28:59 WinEvtLog: > Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational: > INFORMATION(131): Microsoft-Windows-RemoteDesktopServices-RdpCoreTS: > NETWORK SERVICE: NT AUTHORITY: server.domain: The server accepted a new TCP > connection from client 10.104.248.199:57714. > > > Using ossec-logtest I can enter this log entry and on the fifth time it > fires off rule #100560 just as expected. But when I make those same five > logon attempts to a live server, it only ever fires rule #100554. I've > tried this up to 20 times in under 2 minutes, well within the rule > timeframe, and it still never fires the composite rule alert, only 100554. > > I have quite a few other composite rules that I've written over the past > few years and don't have this issue. I just don't see what the problem is > with this one or why ossec-logtest shows it working but it never actually > works in a live situation. > > I'm running OSSEC HIDS v2.9.3 on Linux, with the agents on Windows 2012+ > servers. > > Any thoughts? > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/4ae2c18a-1f20-4958-bd89-53ea238e90a5%40googlegroups.com.
[ossec-list] Composite Rule Not Firing
I'm having an issue getting a composite rule to trigger. What's really throwing me is that it works just fine when testing with ossec-logtest, but it doesn't work live. Here are the two rules in question: 18101 ^131$ Server accepted initial RDP session request sysadmin, 100554 ALERT: Potential RDP brute force attack sysadmin,recon,attacks, ...and here is a sample log entry: 2019 Dec 20 11:28:59 WinEvtLog: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational: INFORMATION(131): Microsoft-Windows-RemoteDesktopServices-RdpCoreTS: NETWORK SERVICE: NT AUTHORITY: server.domain: The server accepted a new TCP connection from client 10.104.248.199:57714. Using ossec-logtest I can enter this log entry and on the fifth time it fires off rule #100560 just as expected. But when I make those same five logon attempts to a live server, it only ever fires rule #100554. I've tried this up to 20 times in under 2 minutes, well within the rule timeframe, and it still never fires the composite rule alert, only 100554. I have quite a few other composite rules that I've written over the past few years and don't have this issue. I just don't see what the problem is with this one or why ossec-logtest shows it working but it never actually works in a live situation. I'm running OSSEC HIDS v2.9.3 on Linux, with the agents on Windows 2012+ servers. Any thoughts? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/db6d29a9-ec7d-4577-9ce6-d7ed445d8862%40googlegroups.com.
Re: [ossec-list] Re: Password Spraying Detection
I'm actually looking for both instances -- instances where there are X number of failed logons to Y+ number of legitimate accounts (purpose of rule #100440) and X number of failed attempts to logon to non-existent accounts (rule #100445). The sub status in those rules are indicative of either a bad password or a non-existent account. Unfortunately keeping a white-list of accounts is not feasible with thousands of user accounts which are in a constant state of flux. A little more background -- this initially stemmed from a recent penetration test we had where we found we were unable to detect their password spray attack against legitimate accounts. I'm now trying to create an alert within OSSEC for this type of thing. Alternatively I may have to look at what I can do within Splunk (the backend of my OSSEC). On Fri, Jan 11, 2019 at 11:56 AM Brent Morris wrote: > Bruce - Do the password spraying attacks have correct user names? Or do > they have mostly incorrect user names and occasionally get lucky? > > One approach would be to create a list of correct user names and block > attackers when they type in an incorrect user name. I've done something > like this on URLs, so external connections to a blacklist of URLs will > cause an active response. > > On Wednesday, January 9, 2019 at 12:27:27 PM UTC-8, Bruce Westbrook wrote: >> >> I'm looking for a way to detect password spraying of accounts, but >> without triggering a bunch of false positives from normal user >> fat-fingering activity. Before I begin rebuilding the wheel, has anyone >> already built solid password spraying detection rules that they can share? >> At this point it's just for Active Directory but the same logic may be >> ported to other areas like web logs. >> >> Otherwise, I'm stuck with trying to get OSSEC to understand how to detect >> bad passwords against multiple/different accounts. There isn't a way that >> I know to do a "NOT same_user" for multiple matches, so my testing still >> ends up triggering for bad passwords on just one account. Here's my >> working example so far: >> >> >> 18130 >> >> Status:\t*\s*0xc06d\t*\s*Sub Status:\t*\s*0xc06a >> >> ALERT: Probable password spraying >> >> >> >> >> 18130 >> >> Status:\t*\s*0xc06d\t*\s*Sub Status:\t*\s*0xc064 >> >> ALERT: Probable account enumeration attempt >> >> >> >> >> While these do trigger for bad passwords against multiple accounts, they >> also trigger for just a single account with multiple bad passwords being >> keyed by a legitimate user. How can I tell OSSEC to match only when it >> sees a bad password against multiple different accounts? Basically, > same_user />? >> >> Thoughts / suggestions? >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Password Spraying Detection
I'm looking for a way to detect password spraying of accounts, but without triggering a bunch of false positives from normal user fat-fingering activity. Before I begin rebuilding the wheel, has anyone already built solid password spraying detection rules that they can share? At this point it's just for Active Directory but the same logic may be ported to other areas like web logs. Otherwise, I'm stuck with trying to get OSSEC to understand how to detect bad passwords against multiple/different accounts. There isn't a way that I know to do a "NOT same_user" for multiple matches, so my testing still ends up triggering for bad passwords on just one account. Here's my working example so far: 18130 Status:\t*\s*0xc06d\t*\s*Sub Status:\t*\s*0xc06a ALERT: Probable password spraying 18130 Status:\t*\s*0xc06d\t*\s*Sub Status:\t*\s*0xc064 ALERT: Probable account enumeration attempt While these do trigger for bad passwords against multiple accounts, they also trigger for just a single account with multiple bad passwords being keyed by a legitimate user. How can I tell OSSEC to match only when it sees a bad password against multiple different accounts? Basically, ? Thoughts / suggestions? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: promiscuous mode frequency
Good point, I've stumbled over that before but I don't have any triggers myself that are set that low. I believe you are correct, which raises the question on how to match on only 2? I don't have the answer to that, unless setting it to zero actually works. Maybe someone else understands that setting better than I and can speak up. On Monday, April 23, 2018 at 3:17:38 AM UTC-4, Chinmay Pandya wrote: > > Hi Bruce > > Thanks for the reply > > As per ossec documentations for the frequency option "Specifies the number > of times the rule must have matched before firing. The number that triggers > the rule is actually 2 more than this setting." > > So, in below overwrite, if i set frequency as 2 , will not it be 4th > instance which will trigger the alert ? Because I want that 2nd instance > must trigger the alert. > > >"yes"> > 5100 > Promiscuous mode enabled| > device \S+ entered promiscuous mode > > Interface entered in promiscuous(sniffing) 2x in 24 hrs. > > promisc, > > > > > On Thursday, April 19, 2018 at 6:31:46 PM UTC+5:30, Bruce Westbrook wrote: >> >> First a comment. You can't drop a rule to a 0 to accomplish this as >> you'll lose all tracking for it and won't be able to use it for any sort of >> count. You have to at least set it at level 1. You can, however, choose >> not to actually log it if you prefer. >> >> Presuming you want this universally, you can overwrite that rule as a >> composite rule (using your local_rules.xml) that checks for two occurrences >> from the same host within a 24-hour period. I've not tested this but >> something like this: >> >> > "yes"> >> 5100 >> Promiscuous mode enabled| >> device \S+ entered promiscuous mode >> >> Interface entered in promiscuous(sniffing) 2x in 24 hrs. >> >> promisc, >> >> >> >> If you still want to alert on single instances for other servers but two >> instances for this particular group of servers, then you'll instead want to >> create a set of custom rules. First match on the promisc rule and the >> servers you're focused on, log but don't send an email. I've found that I >> need to keep the level at the same or higher than the rule I'm matching on, >> else it won't trigger (I still don't have a great handle on how OSSEC >> determines the order it applies rules, as my real-world testing doesn't >> line up with what's documented, but I believe the levels are part of the >> logic). Then use a second rule that matches the first but only 2x in a >> 24-hour period. >> >> Again, untested but something like this: >> >> >> 5104 >> HOST01|HOST02|host03|host04 >> no_email_alert >> Interface entered in promiscuous(sniffing) mode. >> >> promisc, >> >> >> >> 100300 >> >> Interface entered in promiscuous(sniffing) 2x in 24 hrs. >> >> promisc, >> >> >> >> >> This is how I'd approach it. Others may have different / better ideas. >> >> - Bruce >> >> >> On Thursday, April 19, 2018 at 5:04:39 AM UTC-4, Chinmay Pandya wrote: >>> >>> Hi all >>> >>> I need to modify a rule "5104 - Interface entered in >>> promiscuous(sniffing) mode." >>> >>> Once a day , all of the boxes will go into promiscuous mode. Time when >>> they enter into this mode is random. >>> >>> I want to create a rule that in a day, if interface enters more then 1 >>> in promiscuous mode then create alert else reduce level to 0. >>> >>> Thanks in advance. >>> >>> _ >>> The information contained in this communication is intended solely for >>> the use of the individual or entity to whom it is addressed and others >>> authorized to receive it. It may contain confidential or legally privileged >>> information. If you are not the intended recipient you are hereby notified >>> that any disclosure, copying, distribution or taking any action in reliance >>> on the contents of this information is strictly prohibited and may be >>> unlawful. If you have received this communication in error, please notify >>> us immediately by responding to this email and then delete it from your >>> system. The firm is neither liable for the proper and complete transmission >>> of the information contained in this communication nor for any delay in its >>> receipt. >> >> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: promiscuous mode frequency
First a comment. You can't drop a rule to a 0 to accomplish this as you'll lose all tracking for it and won't be able to use it for any sort of count. You have to at least set it at level 1. You can, however, choose not to actually log it if you prefer. Presuming you want this universally, you can overwrite that rule as a composite rule (using your local_rules.xml) that checks for two occurrences from the same host within a 24-hour period. I've not tested this but something like this: 5100 Promiscuous mode enabled| device \S+ entered promiscuous mode Interface entered in promiscuous(sniffing) 2x in 24 hrs. promisc, If you still want to alert on single instances for other servers but two instances for this particular group of servers, then you'll instead want to create a set of custom rules. First match on the promisc rule and the servers you're focused on, log but don't send an email. I've found that I need to keep the level at the same or higher than the rule I'm matching on, else it won't trigger (I still don't have a great handle on how OSSEC determines the order it applies rules, as my real-world testing doesn't line up with what's documented, but I believe the levels are part of the logic). Then use a second rule that matches the first but only 2x in a 24-hour period. Again, untested but something like this: 5104 HOST01|HOST02|host03|host04 no_email_alert Interface entered in promiscuous(sniffing) mode. promisc, 100300 Interface entered in promiscuous(sniffing) 2x in 24 hrs. promisc, This is how I'd approach it. Others may have different / better ideas. - Bruce On Thursday, April 19, 2018 at 5:04:39 AM UTC-4, Chinmay Pandya wrote: > > Hi all > > I need to modify a rule "5104 - Interface entered in > promiscuous(sniffing) mode." > > Once a day , all of the boxes will go into promiscuous mode. Time when > they enter into this mode is random. > > I want to create a rule that in a day, if interface enters more then 1 in > promiscuous mode then create alert else reduce level to 0. > > Thanks in advance. > > _ > The information contained in this communication is intended solely for the > use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally privileged > information. If you are not the intended recipient you are hereby notified > that any disclosure, copying, distribution or taking any action in reliance > on the contents of this information is strictly prohibited and may be > unlawful. If you have received this communication in error, please notify > us immediately by responding to this email and then delete it from your > system. The firm is neither liable for the proper and complete transmission > of the information contained in this communication nor for any delay in its > receipt. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: how to get an alert. the user, whom modified a file
You're welcome. Glad to hear it works for someone else and not just me!
:-)
On Thu, Apr 12, 2018 at 9:46 AM, <dee...@information-secure.com> wrote:
> Thanks a lot Bruce,
>
> Its working great...
>
> -Deepak.
>
>
> On Wednesday, April 11, 2018 at 8:43:55 PM UTC+5:30, Bruce Westbrook wrote:
>>
>> Sure thing. There are three steps involved:
>>
>> 1. Enable Windows Audit Policy for File System Objects
>> 2. Configure the server's audit policy appropriately for the files and/or
>> directories that need to be watched
>> 3. Configure custom rules in OSSEC to trigger on file add/change/delete
>> events
>>
>> I attached a Word doc that contains the details that I copied/pasted from
>> my own OSSEC procedures. Once completed and assuming you have email
>> notifications enabled, you'll see real-time email alerts like this, which
>> will give you the user account name:
>>
>> OSSEC HIDS Notification.
>> 2018 Apr 11 09:57:22
>>
>>
>> Received From: ([SERVER]) any->WinEvtLog
>> Rule: 100221 fired (level 7) -> "FIM: Audited file has been DELETED."
>> User: [USER_ACCOUNT]
>> Portion of the log(s):
>>
>>
>> 2018 Apr 11 09:57:17 WinEvtLog: Security: AUDIT_SUCCESS(4659): Microsoft-
>> Windows-Security-Auditing: (no user): no domain: [SERVEDR]: A handle to
>> an object was requested with intent to delete. Subject: Security ID: [
>> SID] Account Name: [USER_ACCOUNT] Account Domain: [DOMAIN] Logon ID:
>> 0xa4dbac32 Object: Object Server: Security Object Type: File Object
>> Name: [FULL_PATH_AND_FILE_NAME] Handle ID: 0x0 Process Information:
>> Process ID: 0x4 Access Request Information: Transaction ID: {-
>> ---} Accesses: %%1537 %%4423Access
>> Mask: 0x10080 Privileges Used for Access Check: -
>>
>>
>> Hope that works for what you need!
>>
>> - Bruce
>>
>>
>> On Wednesday, April 11, 2018 at 10:27:17 AM UTC-4,
>> dee...@information-secure.com wrote:
>>>
>>>
>>> Yes Bruce,
>>> this is for windows agent. can u let me know about that.
>>>
>>> - Deepak.
>>>
>>> On Wednesday, April 11, 2018 at 7:52:35 PM UTC+5:30, Bruce Westbrook
>>> wrote:
>>>>
>>>> Is this for a Windows agent or Linux agent?
>>>>
>>>> If Windows I can let you know what I've done to accomplish this, which
>>>> doesn't use OSSEC sycheck but rather a combination of Windows File Auditing
>>>> and customized OSSEC rules.
>>>>
>>>> - Bruce
>>>>
>>>>
>>>> On Wednesday, April 11, 2018 at 10:18:10 AM UTC-4,
>>>> dee...@information-secure.com wrote:
>>>>>
>>>>> I'm using OSSEC HIDS
>>>>>
>>>>> from this i'm getting the alerts based on all events. but, i need to
>>>>> know a *user whom modified the specific file*.
>>>>> is this possible?
>>>>>
>>>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: how to get an alert. the user, whom modified a file
Sure thing. There are three steps involved:
1. Enable Windows Audit Policy for File System Objects
2. Configure the server's audit policy appropriately for the files and/or
directories that need to be watched
3. Configure custom rules in OSSEC to trigger on file add/change/delete
events
I attached a Word doc that contains the details that I copied/pasted from
my own OSSEC procedures. Once completed and assuming you have email
notifications enabled, you'll see real-time email alerts like this, which
will give you the user account name:
OSSEC HIDS Notification.
2018 Apr 11 09:57:22
Received From: ([SERVER]) any->WinEvtLog
Rule: 100221 fired (level 7) -> "FIM: Audited file has been DELETED."
User: [USER_ACCOUNT]
Portion of the log(s):
2018 Apr 11 09:57:17 WinEvtLog: Security: AUDIT_SUCCESS(4659): Microsoft-
Windows-Security-Auditing: (no user): no domain: [SERVEDR]: A handle to an
object was requested with intent to delete. Subject: Security ID: [SID]
Account Name: [USER_ACCOUNT] Account Domain: [DOMAIN] Logon ID:
0xa4dbac32 Object: Object Server: Security Object Type: File Object Name
: [FULL_PATH_AND_FILE_NAME] Handle ID: 0x0 Process Information: Process
ID: 0x4 Access Request Information: Transaction ID: {---
-} Accesses: %%1537 %%4423Access Mask: 0x10080
Privileges Used for Access Check: -
Hope that works for what you need!
- Bruce
On Wednesday, April 11, 2018 at 10:27:17 AM UTC-4,
dee...@information-secure.com wrote:
>
>
> Yes Bruce,
> this is for windows agent. can u let me know about that.
>
> - Deepak.
>
> On Wednesday, April 11, 2018 at 7:52:35 PM UTC+5:30, Bruce Westbrook wrote:
>>
>> Is this for a Windows agent or Linux agent?
>>
>> If Windows I can let you know what I've done to accomplish this, which
>> doesn't use OSSEC sycheck but rather a combination of Windows File Auditing
>> and customized OSSEC rules.
>>
>> - Bruce
>>
>>
>> On Wednesday, April 11, 2018 at 10:18:10 AM UTC-4,
>> dee...@information-secure.com wrote:
>>>
>>> I'm using OSSEC HIDS
>>>
>>> from this i'm getting the alerts based on all events. but, i need to
>>> know a *user whom modified the specific file*.
>>> is this possible?
>>>
>>
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
File Integrity Monitoring -- SANITIZED.docx
Description: MS-Word 2007 document
[ossec-list] Re: how to get an alert. the user, whom modified a file
Is this for a Windows agent or Linux agent? If Windows I can let you know what I've done to accomplish this, which doesn't use OSSEC sycheck but rather a combination of Windows File Auditing and customized OSSEC rules. - Bruce On Wednesday, April 11, 2018 at 10:18:10 AM UTC-4, dee...@information-secure.com wrote: > > I'm using OSSEC HIDS > > from this i'm getting the alerts based on all events. but, i need to know > a *user whom modified the specific file*. > is this possible? > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Exclude rule
Dmitriy, custom rules can only be numbered between 100,000 and 119,999. Change the rule number you used (400,001) to between the allowed range. You can then use the *ossec-**logtest* binary to test your config before deploying it. Other than the rule number your syntax appears to be fine. - Bruce On Thursday, March 1, 2018 at 5:11:20 AM UTC-5, Dmitriy Shvedchenko wrote: > > Hello there, > > could someone help me exclude this message from ossec: > > OSSEC HIDS Notification. > 2018 Mar 01 11:02:10 > > Received From: mail->/var/log/messages > Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." > Portion of the log(s): > > Mar 1 11:02:10 mail systemd-logind: Failed to remove runtime directory > /run/user/0: Device or resource busy > > > > --END OF NOTIFICATION > > > > i've created local rule for exlucde, but this rule doesn't work: > > > no_email_alert > > 1002 > systemd-logind > Failed to remove runtime directory /run/user/0: Device or > resource busy > ignore this message > > > > Could pls someone tell me, that i am doing wrong? Thank you in advance! > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Negative Match Criteria
Eric, short answer is unfortunately "no" (see my similar question recently under the subject "Rule Exception - How?"). The only portion of a rule that you can negate/exclude are for srcip and dstip (see http://ossec-docs.readthedocs.io/en/latest/syntax/head_rules.html). What I've found is that to exclude a subset of items you need to create a minimum of two rules. The first rule to catch only what you want to exclude, the second rule to capture all the rest. A simple example to simply ignore the ActiveSync log entries and do something with all the rest, using your log line examples and the rule you posted (not sure what rule #100210 is but assume it's to match the log lines for your rule): 100210 Microsoft-Server-ActiveSync NOISE: Ignore ActiveSync log entries. 100210 \.+\d+\s\w+.\w...@domain.com\.+ - 401 Email authentication failure. Hope that helps point you in the right direction. On Friday, February 9, 2018 at 10:38:47 AM UTC-5, Eric wrote: > > Hello, > > I'm working on a few custom rules and I was wondering if there is a "not > equal to" item within OSSEC custom rules that I can use. I have the > following logs and I want everything but the ActiveSync ones. > > Feb 9 00:00:00 X 2018-02-09 04:59:52 10.13.1.15 POST / > autodiscover/autodiscover.xml =;; 443 - > us...@domain.com X.X.X.X > SfBForMac/16.13.184.+(Mac+OSX+10.12.6) > - 401 1 2148074254 0 > > Feb 9 00:00:00 X 2018-02-09 04:59:52 10.13.1.15 POST > /EWS/Exchange.asmx =;; 443 - us...@domain.com > X.X.X.X SfBForMac/16.13.184.+(Mac+OSX+10.12.6) - 401 1 > 2148074254 0 > > Feb 9 00:00:01 X 2018-02-09 04:59:58 10.13.1.28 POST > /Microsoft-Server-ActiveSync/default.eas ; 443 us...@domain.com > X.X.X.X Android-Mail/7.10.22.174510681.release - 200 0 0 15 > > Right now I have the following logic and it works, but I'd prefer to just > do a not equal to Activesync so I don't have to add additional regexes if a > new log comes in. > > >100210 >autodiscovery.xml|Exchange.asmx >\.+\d+\s\w+.\w...@domain.com \.+ - 401 >Email authentication failure. > > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Multiple as an 'AND', not 'OR'
Yup, that's actually what I did to make it work. I was hoping I was just overlooking something to make a single rule using an 'AND' type statement. On Thursday, January 25, 2018 at 7:27:06 AM UTC-5, dan (ddpbsd) wrote: > > On Tue, Jan 23, 2018 at 3:16 PM, Bruce Westbrook <bwest...@gmail.com > > wrote: > > Running OSSEC v2.8.3 > > > > Can we create a custom rule that performs multiple as an 'AND' ? > I > > need to match multiple, non-contiguous patterns from the log portion. > > > > For instance, a Windows event log comes in with the following log data: > > > > 2018 Jan 22 23:59:54 WinEvtLog: Security: AUDIT_FAILURE(4776): > > Microsoft-Windows-Security-Auditing: (no user): no domain: > dc.domain.local: > > The domain controller attempted to validate the credentials for an > account. > > Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon > Account: > > USER-A Source Workstation: WORKSTATION-A Error Code: 0xc064 > > > > Taking this example, I need to match BOTH "USER-A" and the source > > workstation "WORKSTATION-A" for a custom rule. However, if "USER-A" is > on a > > different source workstation, I don't want the rule to fire, so I need > to > > match both items specifically. > > > > As far as I can tell the only has an 'OR' using the pipe '|'. > > > > How would I do multiple matches in the log content like this? > > > > Can you setup a parent and child rule for this? > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "ossec-list" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Multiple as an 'AND', not 'OR'
Running OSSEC v2.8.3 Can we create a custom rule that performs multiple as an 'AND' ? I need to match multiple, non-contiguous patterns from the log portion. For instance, a Windows event log comes in with the following log data: 2018 Jan 22 23:59:54 WinEvtLog: Security: AUDIT_FAILURE(4776): Microsoft- Windows-Security-Auditing: (no user): no domain: dc.domain.local: The domain controller attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: USER-A Source Workstation: WORKSTATION-A Error Code: 0xc064 Taking this example, I need to match BOTH "USER-A" and the source workstation "WORKSTATION-A" for a custom rule. However, if "USER-A" is on a different source workstation, I don't want the rule to fire, so I need to match both items specifically. As far as I can tell the only has an 'OR' using the pipe '|'. How would I do multiple matches in the log content like this? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: Rule Exception - How?
Thanks Dan, but unfortunately it didn't work for me. That's actually what I originally tried to do and it does look like it works with log-test, but when put into production it still somehow triggered rule 18152. Although 18180 was ignored it was like the counter for the composite rule 18152 still incremented from it. I might revisit this again at some point in the future but for now I'm good with the way it is. Thanks. On Thursday, December 21, 2017 at 8:21:27 AM UTC-5, dan (ddpbsd) wrote: > > I don't have a way to test this nicely, but this seems to be ok with > ossec-logtest: > > 18180 > Login failed for user 'USERNAME > Ignore this guy. > > > > On Tue, Dec 5, 2017 at 1:55 PM, Bruce Westbrook <bwest...@gmail.com > > wrote: > > Just to put some closure to this thread, I had to resort to simply > ignoring > > emails for rule #18152, the rule triggered by excessive > > win_authentication_failed group hits. I simply overwrote that rule and > > added the no_email_alert option to it. Although not > what > > I was hoping to achieve it has stemmed the large amount of alert emails > > until the underlying issue on the database is resolved. It does add > more > > overhead in that I have to check the console periodically since no > emails > > for this are being sent, but good enough as a temporary workaround. > > > > I didn't want to change the aggregate to a SID, as there are other > > win_authentication_failed hits from other sids that I didn't want to end > up > > missing. > > > > If anyone does have an answer to making this one-off exception > successfully > > work, I'm all ears - but for now it's good enough. Thanks for your > input > > Maarten. > > > > - Bruce > > > > > > On Wednesday, November 22, 2017 at 2:54:35 PM UTC-5, Maarten Broekman > wrote: > >> > >> That's bizarre. You can see in the group list in the alert that the > >> win_authentication_failed group isn't listed so I'm not sure why it > would > >> end up in the aggregate. Very odd. I know it's going even further > afield, > >> but changing the aggregate from if_matched_group to > >> 100150 might be needed. It might be > >> possible to just add if_matched_sid as another condition, but I'm not > sure. > >> > >> --Maarten > >> > >> On Wednesday, November 22, 2017 at 2:02:28 PM UTC-5, Bruce Westbrook > >> wrote: > >>> > >>> My apologies, you're right -- I pasted the wrong info, sorry about > that. > >>> I was also editing things like the description at the same time, > therefore > >>> the lack of consistency you identified. > >>> > >>> First answer -- alerts are sent at level 7 or above. The parent rule > >>> #18180 is not the one sending the alert as it's already a lower alert > level > >>> (level=5). It's the composite child rule #18152 that does that, which > is > >>> set to level=10. That rule is looking for > >>> win_authentication_failed, which > based > >>> on your suggestion I removed by overwriting rule #18180. Yet it's > still > >>> alerting. > >>> > >>> Second answer -- here's a recent alert directly from the alerts.log > file, > >>> showing rule #18152 still triggering. > >>> > >>> > >>> ** Alert 1511375499.1421236953: - > >>> > local,syslog,authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4, > > > >>> 2017 Nov 22 13:31:39 (SERVER) any->WinEvtLog > >>> Rule: 18152 (level 10) -> 'Multiple Windows Logon Failures.' > >>> User: (no user) > >>> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): > >>> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user > 'USERNAME'. > >>> Reason: Failed to open the explicitly specified database 'DATABASE'. > >>> [CLIENT: nnn.nnn.nnn.nnn] > >>> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): > >>> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user > 'USERNAME'. > >>> Reason: Failed to open the explicitly specified database 'DATABASE'. > >>> [CLIENT: nnn.nnn.nnn.nnn] > >>> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): > >>> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user > 'USERNAME'. > >>> Reason: Failed to open the explicitly
[ossec-list] Re: agentless ossec configuration
Assuming you have all of the other pieces for agentless monitoring already
in place (e.g. you've registered the host/password, enabled agentless
monitoring) and installed 'expect' on the system, changes will be tracked
in the /var/ossec/queue/diff/[user@agent->script] directory. The last-entry
file will contain the full configuration being checked against while the
diff.[epoch] files contain changes found at those times.
I've not monitored Cisco switches so I can't speak to whether they will
work as-is or require some additional modifications to work with those
devices. But looks like Dan is offering to help with that.
On Thursday, December 21, 2017 at 12:24:57 AM UTC-5, gon...@seagroup.com
wrote:
>
> Hi westbrook,
>
> When i followed your script, there is something new shows ssh_pix monitors
> myswitch@IP starting, which shows in attached pictures.
>
>
> <https://lh3.googleusercontent.com/-MuJotDdvZnA/WjtEvqImvQI/ArA/3oSVZZROQaoWtK7wbEX1BrgP-p9dsf6wQCLcBGAs/s1600/1513833647217.jpg>
>
>
>
> but i am checking log in alert.json and ossec.log, which one will show the
> monitoring result when i changed some configuration in my cicso switch.
>
>
> Thank u for helping me .
>
>
>
>
>
>
>
>
>
> On Tuesday, December 19, 2017 at 11:28:15 PM UTC+8, Bruce Westbrook wrote:
>>
>> I came across this issue myself when configuring Cisco ASA firewalls with
>> OSSEC v2.8.3. I found that both the ssh_pixconfig_diff (PIX) and
>> ssh_asa-fwsmconfig_diff (ASA) scripts have some issues with them,
>> including:
>>
>> • Expect statement has the wrong case used for some responses (e.g.
>> Password instead of password);
>> • SSH is set specifically to use DES only
>> • Output from the SSH session will include extra newlines and Connection
>> to [host] closed by remote host at times, triggering false positive change
>> alerts.
>>
>> To address these issues I created a customized script. I can provide you
>> the whole script, but specifically to address your issue you can simply try
>> making one change in your own script. In your ssh_pixconfig_diff
>> script, locate this line:
>>
>> spawn ssh -c des $hostname
>>
>> Remark that line out and use this one instead:
>>
>> spawn ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 $hostname
>>
>>
>> If you encounter some of the other issues, here's my entire revised
>> script that works for me - all the highlights are changes from the original
>> script (based on the ASA script, not the PIX script):
>>
>> #!/usr/bin/env expect
>>
>>
>>
>>
>> ###
>>
>> #
>>
>> # PROGRAM: ssh_asa-custom_diff
>>
>> # AUTHOR: Bruce A. Westbrook
>>
>> # DATE: 2017-04-27
>>
>> # PURPOSE: Check ASA for configuration changes
>>
>> #
>>
>> # DEPENDENCIES:
>>
>> # expect
>>
>> #
>>
>> # REVISIONS:
>>
>> #
>>
>> # 2017-04-27 - v1.0
>>
>> # - Initial release, forked from the OSSEC provided
>>
>> # "ssh_asa-fwsmconfig_diff" script
>>
>> #
>>
>>
>> ###
>>
>>
>>
>> # Agentless monitoring
>>
>> #
>>
>> # Copyright (C) 2009 Trend Micro Inc.
>>
>> # All rights reserved.
>>
>> #
>>
>> # This program is a free software; you can redistribute it
>>
>> # and/or modify it under the terms of the GNU General Public
>>
>> # License (version 2) as published by the FSF - Free Software
>>
>> # Foundation.
>>
>>
>>
>> # Send log entry that we're starting to run
>>
>> send_user "\nINFO: Starting\n"
>>
>>
>>
>> if {$argc < 1} {
>>
>> send_user "ERROR: ssh_asa-custom_diff \n";
>>
>> send_user "ERROR: Must be run from /var/ossec\n";
>>
>> exit 1;
>>
>> }
>>
>>
>>
>>
>>
>> # NOTE: this script must be called from within /var/ossec for it to work.
>>
>> set passlist "agentless/.passlist"
>>
>> set hostname [lindex $argv 0]
>>
>> set commands [lrange $argv 1 end]
>>
>> set pass "x"
>>
>> set addpass "x"
>>
>> set timeout 20
>>
>>
>>
>> set lastentry "queue/di
[ossec-list] Re: agentless ossec configuration
I came across this issue myself when configuring Cisco ASA firewalls with
OSSEC v2.8.3. I found that both the ssh_pixconfig_diff (PIX) and
ssh_asa-fwsmconfig_diff (ASA) scripts have some issues with them,
including:
• Expect statement has the wrong case used for some responses (e.g.
Password instead of password);
• SSH is set specifically to use DES only
• Output from the SSH session will include extra newlines and Connection to
[host] closed by remote host at times, triggering false positive change
alerts.
To address these issues I created a customized script. I can provide you
the whole script, but specifically to address your issue you can simply try
making one change in your own script. In your ssh_pixconfig_diff script,
locate this line:
spawn ssh -c des $hostname
Remark that line out and use this one instead:
spawn ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 $hostname
If you encounter some of the other issues, here's my entire revised script
that works for me - all the highlights are changes from the original script
(based on the ASA script, not the PIX script):
#!/usr/bin/env expect
###
#
# PROGRAM: ssh_asa-custom_diff
# AUTHOR: Bruce A. Westbrook
# DATE: 2017-04-27
# PURPOSE: Check ASA for configuration changes
#
# DEPENDENCIES:
# expect
#
# REVISIONS:
#
# 2017-04-27 - v1.0
# - Initial release, forked from the OSSEC provided
# "ssh_asa-fwsmconfig_diff" script
#
###
# Agentless monitoring
#
# Copyright (C) 2009 Trend Micro Inc.
# All rights reserved.
#
# This program is a free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.
# Send log entry that we're starting to run
send_user "\nINFO: Starting\n"
if {$argc < 1} {
send_user "ERROR: ssh_asa-custom_diff \n";
send_user "ERROR: Must be run from /var/ossec\n";
exit 1;
}
# NOTE: this script must be called from within /var/ossec for it to work.
set passlist "agentless/.passlist"
set hostname [lindex $argv 0]
set commands [lrange $argv 1 end]
set pass "x"
set addpass "x"
set timeout 20
set lastentry "queue/diff/$hostname-\>ssh_asa-custom_diff/last-entry"
if {[string compare $hostname "test"] == 0} {
if {[string compare $commands "test"] == 0} {
exit 0;
}
}
# Reading the password list.
if [catch {
set in [open "$passlist" r]
} loc_error] {
send_user "ERROR: Password list not present (use \"register_host\"
first).\n"
exit 1;
}
while {[gets $in line] != -1} {
set me [string first "|" $line]
set me2 [string last "|" $line]
set length [string length $line]
if {$me == -1} {
continue;
}
if {$me2 == -1} {
continue;
}
if {$me == $me2} {
continue;
}
set me [expr $me-1]
set me2 [expr $me2-1]
set host_list [string range $line 0 $me]
set me [expr $me+2]
set pass_list [string range $line $me $me2]
set me2 [expr $me2+2]
set addpass_list [string range $line $me2 $length]
if {[string compare $host_list $hostname] == 0} {
set pass "$pass_list"
set addpass "$addpass_list"
break
}
}
close $in
if {[string compare $pass "x"] == 0} {
send_user "ERROR: Password for '$hostname' not found.\n"
exit 1;
}
# SSHing to the box and passing the directories to check.
# Fix for SSH issue with poor DES cipher and inability to connect.
if [catch {
#spawn ssh -c des $hostname
spawn ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 $hostname
} loc_error] {
send_user "ERROR: Opening connection: $loc_error.\n"
exit 1;
}
expect {
"WARNING: REMOTE HOST" {
send_user "ERROR: RSA host key for '$hostname' has changed. Unable
to access.\n"
exit 1;
}
"*sure you want to continue connecting*" {
send "yes\r"
expect "* password:*" {
send "$pass\r"
expect {
"Permission denied" {
send_user "ERROR: Incorrect password to remote host:
$hostname .\n"
exit 1;
}
timeout {
send_user "ERROR: Timeout while running on host (too
long to finish): $hostname .\n"
exit 1;
}
"*>" {
send_user "\nINFO: Starting.\n"
}
}
}
}
"ssh: connect to host*" {
send_user "ERROR: Unable to connect to remote host: $hostname .\n"
Re: [ossec-list] Re: Rule Exception - How?
Just to put some closure to this thread, I had to resort to simply ignoring emails for rule #18152, the rule triggered by excessive win_authentication_failed group hits. I simply overwrote that rule and added the no_email_alert option to it. Although not what I was hoping to achieve it has stemmed the large amount of alert emails until the underlying issue on the database is resolved. It does add more overhead in that I have to check the console periodically since no emails for this are being sent, but good enough as a temporary workaround. I didn't want to change the aggregate to a SID, as there are other win_authentication_failed hits from other sids that I didn't want to end up missing. If anyone does have an answer to making this one-off exception successfully work, I'm all ears - but for now it's good enough. Thanks for your input Maarten. - Bruce On Wednesday, November 22, 2017 at 2:54:35 PM UTC-5, Maarten Broekman wrote: > > That's bizarre. You can see in the group list in the alert that the > win_authentication_failed group isn't listed so I'm not sure why it would > end up in the aggregate. Very odd. I know it's going even further afield, > but changing the aggregate from if_matched_group to > 100150 might be needed. It might be > possible to just add if_matched_sid as another condition, but I'm not sure. > > --Maarten > > On Wednesday, November 22, 2017 at 2:02:28 PM UTC-5, Bruce Westbrook wrote: >> >> My apologies, you're right -- I pasted the wrong info, sorry about that. >> I was also editing things like the description at the same time, therefore >> the lack of consistency you identified. >> >> First answer -- alerts are sent at level 7 or above. The parent rule >> #18180 is not the one sending the alert as it's already a lower alert level >> (level=5). It's the composite child rule #18152 that does that, which is >> set to level=10. That rule is looking for >> win_authentication_failed, which >> based on your suggestion I removed by overwriting rule #18180. Yet it's >> still alerting. >> >> Second answer -- here's a recent alert directly from the alerts.log file, >> showing rule #18152 still triggering. >> >> >> ** Alert 1511375499.1421236953: - local,syslog,authentication_failures, >> pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4, >> 2017 Nov 22 13:31:39 (SERVER) any->WinEvtLog >> Rule: 18152 (level 10) -> 'Multiple Windows Logon Failures.' >> User: (no user) >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER: Login failed for user >> 'USERNAME'. Reason: Failed to open the explicitly specified database >> 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> >> >> If the first line of the alert is an indication of the groups it >> triggered on, I'm even more confused as it doesn't list the group that the >> rule is configured to trigger from, win_authentication_failed. I'm >> obviously not understanding something here. >> >> Here are the rules I created, based on your suggestion to overwrite >> #18180 to match onl
Re: [ossec-list] Re: Rule Exception - How?
My apologies, you're right -- I pasted the wrong info, sorry about that. I was also editing things like the description at the same time, therefore the lack of consistency you identified. First answer -- alerts are sent at level 7 or above. The parent rule #18180 is not the one sending the alert as it's already a lower alert level (level=5). It's the composite child rule #18152 that does that, which is set to level=10. That rule is looking for win_authentication_failed, which based on your suggestion I removed by overwriting rule #18180. Yet it's still alerting. Second answer -- here's a recent alert directly from the alerts.log file, showing rule #18152 still triggering. ** Alert 1511375499.1421236953: - local,syslog,authentication_failures, pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4, 2017 Nov 22 13:31:39 (SERVER) any->WinEvtLog Rule: 18152 (level 10) -> 'Multiple Windows Logon Failures.' User: (no user) 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] 2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] If the first line of the alert is an indication of the groups it triggered on, I'm even more confused as it doesn't list the group that the rule is configured to trigger from, win_authentication_failed. I'm obviously not understanding something here. Here are the rules I created, based on your suggestion to overwrite #18180 to match only to the problematic log entry and NOT give it the group triggered by rule #18152, then add a custom rule that is a replacement for the original #18180 rule: 18105 ^18456$ Login failed for user 'USER' pci_dss_10.2.4,pci_dss_10.2.5, TEMP NOISE REDUCTION: MS SQL Server Logon Failure for 'USER' 18105 ^18456$ win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5, MS SQL Server Logon Failure - custom rule for #18180 >From what I can see, it looks like the problematic log entries are indeed hitting the revised rule #18180, which means they should not be getting tagged with the group win_authentication_failed -- yet rule #18152 still fires off based on these events still somehow being tagged with that group. I'm obviously not understanding something about how this is working since it's still triggering emails. I appreciate any further insight you or anyone can provide, thanks! *As a heads up, if you're not in the USA we have a 4-day weekend with Thanksgiving starting, so I don't plan to be looking at this again until Monday. :-)* On Wednesday, November 22, 2017 at 6:45:32 AM UTC-5, Maarten Broekman wrote: > > Two questions... > At what level do you get emails from the alerts? I noticed you didn't > change the level of the 18180 from a '5'. > > Do you have a sanitized version of the 'new' alert from the alert log (as > opposed to the ossec-logtest output)? That will show the groups on the > alert. > > I ask because the ossec-logtest output seems to show a different > description of 18180 than what should be there from the configured (and > displayed) rules you pasted. > > Maarten > > On Tuesday, November 21, 2017 at 10:42:23 AM UTC-5, Bruce Westbrook wrote: >> >> Unfortunately that didn't work Maarten. After following that logic I am >> still getting all the email alerts for that account again. And yes, I >> restarted the OSSEC da
Re: [ossec-list] Re: Rule Exception - How?
Unfortunately that didn't work Maarten. After following that logic I am still getting all the email alerts for that account again. And yes, I restarted the OSSEC daemons after adding the rules :-) However, when I run the log entry against ossec-logtest, it appears to do what I want by matching my overwritten #18180 rule -- yet in reality it still sends an email due to it matching the #18152 composite rule (I'm not sure how to use ossec-logtest to test a composite rule with multiple log entries). Here are the rules I added: 18105 ^18456$ Login failed for user 'USERNAME' pci_dss_10.2.4,pci_dss_10.2.5, MS SQL Server Logon Failure for 'dpa' only 18105 ^18456$ win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5, MS SQL Server Logon Failure for 'dpa' only Here's the output from ossec-logtest: 2017/11/21 10:31:13 ossec-testrule: INFO: Reading local decoder file. 2017/11/21 10:31:13 ossec-testrule: INFO: Started (pid: 27437). ossec-testrule: Type one log per line. 2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT : nnn.nnn.nnn.nnn] **Phase 1: Completed pre-decoding. full event: '2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]' hostname: 'SERVER' program_name: '(null)' log: '2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]' **Phase 2: Completed decoding. decoder: 'windows' status: 'AUDIT_FAILURE' id: '18456' extra_data: 'MSSQLSERVER' dstuser: '(no user)' system_name: 'SERVER' **Phase 3: Completed filtering (rules). Rule id: '18180' Level: '5' Description: 'TEMP NOISE REDUCTION: MS SQL Server Logon Failure for ' USERNAME'' **Alert to be generated. What am I still missing? Any ideas? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: Rule Exception - How?
Okay, thanks for the idea Maarten. It didn't occur to me to try reversing the logic like that and overwriting the original rule like that, then creating a new rule that essentially does the same thing as the original rule. Assuming there's not an order of operation issue with this, I expect that would do the trick. I'll report back one way or the other. It happens so frequently that I'm sure to know the result soon. Thanks! On Tue, Nov 21, 2017 at 9:20 AM, Maarten Broekman < maarten.broek...@gmail.com> wrote: > What you probably want to do is override 18180 by having it set the level > below the email threshold and NOT add the win_authentication_failed group > for that particular alert and then have a new rule that adds the > win_authentication_failed group for any alerts that still match 18105. > > > 18105 > ^18456$ > BAD_NOT_BAD_USERNAME > pci_dss_10.2.4,pci_dss_10.2.5, > MS SQL Server Logon Failure by known 'not bad' > > > > > > > 18105 > ^18456$ > win_authentication_failure, > > MS SQL Server Logon Failure. > > > > > On Monday, November 20, 2017 at 3:44:16 PM UTC-5, Bruce Westbrook wrote: >> >> Looking for help on making an exception for a specific username that's >> continually failing logons to a database. The DBAs are slammed and unable >> to get to this for a few days. In the meantime, I'm getting slammed with >> an excessive amount of email alerts (500+) from rule #18180 every day. >> >> My goal is to: >> >>1. Stop this one "USERNAME" on this one "SERVER" from triggering >>email alerts >>2. Still continue logging the alerts (just not emailing) >>3. Still allow all other failed logons to count up and email alerts >> >> As such, I can't just simply stop sending emails from rule #18180 since >> that would stop alerts on all other activity, not just this one. >> >> I cannot find a way to overwrite rule #18180 with a exception, >> as there doesn't appear to be a way to make exceptions for anything but >> source and destination IP addresses. Nor can I find a way to remove a >> from a matched rule so I could on the "USERNAME" and >> "SERVER" and remove it from the "win_authentication_failed" group, >> thereby keeping #18180 from seeing it. >> >> Here are some details: >> >> Rule #18180 is first triggered by failed logins and adds the group " >> win_authentication_failed": >> >> >> 18105 >> ^18456$ >> win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5, >> >> MS SQL Server Logon Failure. >> >> >> >> Here's a sample (sanitized) actual alert from rule #18180: >> >> ** Alert 1510854237.1318112395: - windows,win_authentication_failed, >> pci_dss_10.2.4,pci_dss_10.2.5, >> 2017 Nov 16 12:43:57 (SERVER) any->WinEvtLog >> Rule: 18180 (level 5) -> 'MS SQL Server Logon Failure.' >> User: (no user) >> 2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): >> MSSQLSERVER: (no user): no domain: SERVER.DOMAIN.LOCAL: Login failed for >> user 'USERNAME'. Reason: Failed to open the explicitly specified >> database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] >> >> >> >> Once OSSEC sees six of these "win_authentication_failed" alerts within >> four minutes, rule #18152 triggers: >> >> >> win_authentication_failed >> Multiple Windows Logon Failures. >> authentication_failures,pci_dss_10.2.4,pci_dss_10.2. >> 5,pci_dss_11.4, >> >> >> >> >> Can anyone point me in the right direction on excluding this particular >> alert (still logging though) from being seen by rule #18152, without >> impacting that rule's ability to email alerts for all other activity? >> >> - Bruce >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Rule Exception - How?
Looking for help on making an exception for a specific username that's continually failing logons to a database. The DBAs are slammed and unable to get to this for a few days. In the meantime, I'm getting slammed with an excessive amount of email alerts (500+) from rule #18180 every day. My goal is to: 1. Stop this one "USERNAME" on this one "SERVER" from triggering email alerts 2. Still continue logging the alerts (just not emailing) 3. Still allow all other failed logons to count up and email alerts As such, I can't just simply stop sending emails from rule #18180 since that would stop alerts on all other activity, not just this one. I cannot find a way to overwrite rule #18180 with a exception, as there doesn't appear to be a way to make exceptions for anything but source and destination IP addresses. Nor can I find a way to remove a from a matched rule so I could on the "USERNAME" and "SERVER" and remove it from the "win_authentication_failed" group, thereby keeping #18180 from seeing it. Here are some details: Rule #18180 is first triggered by failed logins and adds the group " win_authentication_failed": 18105 ^18456$ win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5, MS SQL Server Logon Failure. Here's a sample (sanitized) actual alert from rule #18180: ** Alert 1510854237.1318112395: - windows,win_authentication_failed, pci_dss_10.2.4,pci_dss_10.2.5, 2017 Nov 16 12:43:57 (SERVER) any->WinEvtLog Rule: 18180 (level 5) -> 'MS SQL Server Logon Failure.' User: (no user) 2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER.DOMAIN.LOCAL: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn] Once OSSEC sees six of these "win_authentication_failed" alerts within four minutes, rule #18152 triggers: win_authentication_failed Multiple Windows Logon Failures. authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4, Can anyone point me in the right direction on excluding this particular alert (still logging though) from being seen by rule #18152, without impacting that rule's ability to email alerts for all other activity? - Bruce -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
