ert.
>
> 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 wr
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.
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
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
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, Novembe
rther 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:
>
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...@
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
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
>
c-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
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:
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.
-
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,
7 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 ag
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 U
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,
gt;"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, Bruc
e 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 bun
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
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,
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
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 o
*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
ing 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
.
>
> --
>
>
> 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 Tu
canner 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è
26 matches
Mail list logo
