On Thursday, August 28, 2014 11:32:47 AM UTC-4, dan (ddpbsd) wrote:
>
> On Thu, Aug 28, 2014 at 11:08 AM, dan (ddp) > wrote:
> > On Thu, Aug 28, 2014 at 10:19 AM, Tim Boyer > wrote:
> >> We've got an instance that we're finally ready to go with Active
&g
We've got an instance that we're finally ready to go with Active Response
on. 2.8, running on a RHEL6 server.
Vanilla OSSEC works great; emails us alerts:
yes
t...@timboyer.org
localhost
timboyer-os...@saratoga.timboyer.org
10.127.70.130
ti...@timboyer.org
On Monday, August 11, 2014 12:35:11 PM UTC-4, dan (ddpbsd) wrote:
>
> On Fri, Aug 8, 2014 at 9:53 AM, Tim Boyer >
> wrote:
> > ossec 2.8-45 and RHEL10
> >
> > Upgraded to 2.8 from 2.6. I've got a large number of servers with
> 'Waiting
> >
On Friday, August 8, 2014 8:38:05 AM UTC-4, dan (ddpbsd) wrote:
>
> On Fri, Aug 8, 2014 at 8:04 AM, Tim Boyer >
> wrote:
> >
> >
> > On Friday, August 8, 2014 7:53:32 AM UTC-4, dan (ddpbsd) wrote:
> >>
> >> On Thu, Aug 7, 2014 at 6:43 PM, Tim
ossec 2.8-45 and RHEL10
Upgraded to 2.8 from 2.6. I've got a large number of servers with 'Waiting
for server reply', which is strange, because it worked previously.
So server at 10.0.130.137, and client at 10.0.130.133. Client says
2014/08/08 08:59:49 ossec-agentd: INFO: Using IPv4 for: 10
On Friday, August 8, 2014 7:53:32 AM UTC-4, dan (ddpbsd) wrote:
>
> On Thu, Aug 7, 2014 at 6:43 PM, Tim Boyer >
> wrote:
> > Fixed by making ossec.log 777, which I don't like much - but it at least
> > lets me see where the problem is. Continued in another to
Fixed by making ossec.log 777, which I don't like much - but it at least
lets me see where the problem is. Continued in another topic...
On Thursday, August 7, 2014 6:30:39 PM UTC-4, Tim Boyer wrote:
>
> 2.8.45 on RHEL5
>
> Server at 10.0.130.70; agent at 10.0.130.74. Agent l
2.8.45 on RHEL5
Server at 10.0.130.70; agent at 10.0.130.74. Agent log says
[root@yamaguchi logs]# tail ossec.log
2014/08/07 18:00:22 ossec-agentd(4101): WARN: Waiting for server reply (not
started). Tried: '10.0.130.70'.
2014/08/07 18:01:36 ossec-agentd: INFO: Trying to connect to server
(1
tart. I
> think the issue is that you register your rules to every rule with level 2,
> so you generate a lot of children. That's why analysisd starts slow and the
> queue is not ready when the other processes expected it to be.
>
> Best regards
> On 5 Aug 2014 16:45, "Tim
On Tuesday, August 5, 2014 9:20:10 AM UTC-4, dan (ddpbsd) wrote:
>
> On Tue, Aug 5, 2014 at 8:54 AM, Tim Boyer >
> wrote:
> >
> >
> > On Tuesday, August 5, 2014 7:40:10 AM UTC-4, dan (ddpbsd) wrote:
> >>
> >> On Mon, Aug 4, 2014 at 8:05
On Tuesday, August 5, 2014 7:40:10 AM UTC-4, dan (ddpbsd) wrote:
>
> On Mon, Aug 4, 2014 at 8:05 PM, Tim Boyer >
> wrote:
> >
> >
> > On Monday, August 4, 2014 11:18:26 AM UTC-4, dan (ddpbsd) wrote:
> >>
> >> On Mon, Aug 4, 2014 at 10:56
On Monday, August 4, 2014 11:18:26 AM UTC-4, dan (ddpbsd) wrote:
>
> On Mon, Aug 4, 2014 at 10:56 AM, Tim Boyer >
> wrote:
> >
> > On Monday, August 4, 2014 9:30:26 AM UTC-4, dan (ddpbsd) wrote:
> >>
> >> Is there anything useful in ossec.log relate
On Monday, August 4, 2014 11:18:26 AM UTC-4, dan (ddpbsd) wrote:
>
> On Mon, Aug 4, 2014 at 10:56 AM, Tim Boyer >
> wrote:
> >
> > On Monday, August 4, 2014 9:30:26 AM UTC-4, dan (ddpbsd) wrote:
> >>
> >> Is there anything useful in ossec.log relate
On Monday, August 4, 2014 9:30:26 AM UTC-4, dan (ddpbsd) wrote:
>
> Is there anything useful in ossec.log related to this? Can you
> reproduce this on a recent version of OSSEC?
>
>
>
Nothing helpful. Only difference between this startup and a normal startup
is
2014/08/04 10:51:48 ossec-sysch
ossec 2.6-15 on RHEL5.10.
I've got a separate xml in rules called local_nessus_rules.xml where I'm
trying to exclude all of the security scan IPs. Separate only for
readability, and it looks like so:
2
10.100.131.26
Another nessus scan
2
10.100.131.28
Another ne
2.6 running on a RHEL6 server. I’m trying to filter out darn near anything
I can see from certain IPs, because of our lovely Security department
scans. So:
5712
10.0.120.55|10.1.150.23|10.5.11.87|10.3.45.88|10.3.56.129|10.177.8.34|10.22.55.220|10.22.55.221|10.22.55.222
Ano
So does the 'time' rule do what I think it does, or am I completely off
base here? We're doing a reboot at 5AM every morning, and have in
local_rules
5:00 am - 5:30 am
TABSRV3
Ignore SRV3 reboot
and yet are still getting this:
OSSEC HIDS Notification.
2013 Sep 13 05:20:09
Recei
Aha! That makes sense; I'll bump it up. Thanks much!
On Saturday, August 31, 2013 10:33:43 PM UTC-4, dan (ddpbsd) wrote:
>
>
> On Aug 31, 2013 10:32 PM, "Tim Boyer" >
> wrote:
> >
> > ... and a few minutes searching through email gave me this from a
IE+8.0;+Windows+NT+5.2;+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727)
/EDACookie4.0=TAB;+ASP.NET_SessionId=4j2qcw45wjf4ehqfcymzlb45
/http://TABtestlb.timboyer.org/web372/TAB
On Saturday, August 31, 2013 12:47:34 PM UTC-4, Tim Boyer wrote:
>
> Running 2.6.15 on a RHEL5 server, and the d
?
Thanks,
Tim
On Saturday, August 31, 2013 1:06:10 PM UTC-4, dan (ddpbsd) wrote:
>
>
> On Aug 31, 2013 1:01 PM, "Tim Boyer" >
> wrote:
> >
> > Running 2.6.15 on a RHEL5 server, and the do_not_group is not working
> the way I expect. I assume that that
2.6.15 on RHEL5
Trying to get security's much beloved nessus scans out of our alerts, I'm
doing this:
4
192.168.31.25
Another stupid nessus scan
which is straight out of the book (I've even RTFM) and should eliminate any
alert above level 4 from that IP. It works for a 'norma
Running 2.6.15 on a RHEL5 server, and the do_not_group is not working the
way I expect. I assume that that is a problem with my expectations, but
just in case...
ossec.conf looks like so:
WINDOWS
5
192.168.42|192.168.43|192.168.44|192.168.45|192.168.46|192.168.52|192.168.53|192
ril 15, 2013 8:29:32 AM UTC-4, dan (ddpbsd) wrote:
>
> On Sun, Apr 14, 2013 at 6:38 PM, Tim Boyer >
> wrote:
> > We've got a few hundred servers running OSSEC, with multiple groups
> reading
> > the output. One of the things that annoys them is when one group
b. Lots of servers in the body, but not a single one
that references the subject server. Do I have something misconfigured, or
is this an artifact of bunches of status results coming in at the same time
- or something else? RHEL6.3 everywhere, OSEC 2.7.
Thanks,
Tim Boyer
--
---
t; 2009/03/18 13:49:11 ossec-agentd(4102): INFO: Connected to the server
> (192.168.2.xx:1514).
>
>
> Also, if you look at the manager's log, do you see anything? And using
> tcpdump (on both sides)?
>
> Thanks,
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.n
g in the manager's log about agentd, either.
I'll play around with the tcpdump in the morning.
Thanks,
-- tim --
> Thanks,
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.net
>
>
>
> On Mon, Mar 16, 2009 at 4:22 PM, Tim Boyer wrote:
> >
> > Daniel
please share you config, version of ossec
> and full log dumps (generally a
> cat /var/ossec/logs/ossec.log | grep -e "ERROR|WARN" should
> be enough).
>
> Thanks,
>
> Thanks,
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.net
>
> On Sun, Mar 15,
issive/disabled on the other servers not these ones?
>
> Ben
>
> On Sat, 2009-03-14 at 20:17 -0400, Tim Boyer wrote:
> > I've got a half-dozen RHEL5.3 systems running OSSEC just
> fine. And two
> > RHEL5.3 systems that never will start up at all.
> >
>
d. Waiting for
permissio
n...
Two hours later, it's still sitting there waiting for permission.
Pointers in the right direction greatly appreciated...
--
Tim Boyer
Chief Technology Officer
Denman Tire Corporation
t...@denmantire.com
RDS.
2009/03/13 13:46:14 ossec-analysisd(1220): ERROR: Error loading the rules:
'local_rules.xml'.
[FAILED]
What would be the correct method of doing this? I obviously don't want to
duplicate the variable in local_rules.
--
T
>
> What I was referring to is that the message has an alert
> level of 3, but the default as I understand it is to only
> send an alert if the even is of a level of 7 or greater? I'm
> just trying to understand why I was emailed this alert, not
> why it happened.
>
> Thanks,
> Rob Skoog
L
> hi,
>
> answer inline...
>
> On Apr 3, 8:56 pm, "Tim Boyer" <[EMAIL PROTECTED]> wrote:
> > [...]
> > But I'm still getting these emails every few minutes:
> >
> > OSSEC HIDS Notification.
> > 2008 Apr 03 14:30:11
> >
&g
OK, I'm obviously missing something perfectly simple here. I just can't see
what it is.
I'm trying to notify on levels 4 and above only. So the server says
roosevelt.denmantire.com.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
4
1
But I'm still getting these em
:51 ossec-agentd(4101): Waiting for server reply (not
started).
2007/07/03 20:57:37 ossec-agentd(4101): Waiting for server reply (not
started).
2007/07/03 20:58:38 ossec-agentd(4101): Waiting for server reply (not
started).
I'll email you the logs after I try this one more time.
--
Tim Bo
,
Did you restart the server after adding the new agents? And after that start
the new agents?
E.
2007/6/29, Tim Boyer <[EMAIL PROTECTED]>:
You know you're getting old when you google for an answer - and find one of
your own posts. But this is _slightly_ different.
I&#x
68.1.90 is available.
saratoga-192.168.1.250 is available.
challenger-192.168.1.79 is available.
tolstoy-192.168.1.75 is available.
I've deleted the agent keys and re-created them, and then re-imported them -
so it's not that. Anyone have any suggestions?
Thanks,
--
Tim Boyer
Director
Info
;
> These two links (one is my presentation at AusCERT) can
> explain a little more
> how the rules work:
>
> http://www.ossec.net/wiki/index.php/Know_How:CorrelateSnort
> http://www.ossec.net/ossec-docs/auscert-2007-dcid.pdf
>
> hope it helps.
>
_Big_ help. That de-mystifies everything. Thanks much!
--
Tim Boyer
Director
Information Systems and Engineering Projects
Denman Tire Corporation
[EMAIL PROTECTED]
"ignore_scanners" option in your snort.conf and
tune out known source IP's that are legitimately scanning your network.
Tom, that sure makes sense - why have snort report it and then OSSEC ignore
it if I don't want to see it in the first place? Thanks much...
--
Tim Boyer
Director
20151
snort\.*(portscan)\.*{PROTO255} 192.168.0.150 ->
Portsweep from whatsup. It's OK.
but it's obviously not doing what I wanted it to. What am I not seeing
here?
Thanks,
--
Tim Boyer
Director
Information Systems and Engineering Projects
Denman Tire Corporation
[EMAIL PROTECTED]
imple I'm
missing. A nudge in the right direction would be greatly appreciated.
--
Tim Boyer
Director IT and Engineering Projects
Denman Tire Corporation
40 matches
Mail list logo
