ll 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.
>
> --
, 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
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 way
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 matc
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 i
*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.
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,
ething
> 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
>> with
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
t.
>
>
>"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
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, y
You're welcome. Glad to hear it works for someone else and not just me!
:-)
On Thu, Apr 12, 2018 at 9:46 AM, 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:
>
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 o
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...@infor
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.
- B
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
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
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)
e ok with
> ossec-logtest:
>
> 18180
> Login failed for user 'USERNAME
> Ignore this guy.
>
>
>
> On Tue, Dec 5, 2017 at 1:55 PM, Bruce Westbrook > wrote:
> > Just to put some closure to this thread, I had to resort to simply
>
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 Cisc
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.
Passwor
. 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
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 oss
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 matchi
6$
> 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.
>
>
>
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 g
26 matches
Mail list logo