Hi guys,
I set up ossec since few months now, but I have some problems with active-responses.
Active-responses work well, no problem with it.
When an alert is detected, a lot of failed authentication from the same IP for example, IP is blacklisted in the firewall, and all connections are dropped.
I use a timeout of 900s and repeated_offenders.
But, in some cases, it arrived that a legitimate IP was blacklisted : wrong password or other. It was blacklisted for 900s.
I want to manually unblock the IP, so I execute the command :
# /var/ossec/active-response/
# /var/ossec/active-response/
It's ok : 1.1.1.1 is deleted from firewall's IP blacklisted IP and is also deleted from hosts.deny.
But 1.1.1.1 is still not allowing to connect to agent, until timeout of 900s expired.
My question : is there a way to manually unblock 1.1.1.1 ? before timeout expiration ?
Did active-response modify anything else, apart of adding a drop rule in firewall and an IP in hosts.deny in my case ??
I already try a reboot of agent, it doesn't help.
I'm using ossec2.6.
Thanks for any help.
Zoe
I set up ossec since few months now, but I have some problems with active-responses.
Active-responses work well, no problem with it.
When an alert is detected, a lot of failed authentication from the same IP for example, IP is blacklisted in the firewall, and all connections are dropped.
I use a timeout of 900s and repeated_offenders.
But, in some cases, it arrived that a legitimate IP was blacklisted : wrong password or other. It was blacklisted for 900s.
I want to manually unblock the IP, so I execute the command :
# /var/ossec/active-response/
# /var/ossec/active-response/
It's ok : 1.1.1.1 is deleted from firewall's IP blacklisted IP and is also deleted from hosts.deny.
But 1.1.1.1 is still not allowing to connect to agent, until timeout of 900s expired.
My question : is there a way to manually unblock 1.1.1.1 ? before timeout expiration ?
Did active-response modify anything else, apart of adding a drop rule in firewall and an IP in hosts.deny in my case ??
I already try a reboot of agent, it doesn't help.
I'm using ossec2.6.
Thanks for any help.
Zoe
 | dan (ddpbsd) |
10/16/12
|
- show quoted text -
> I already try a reboot of agent, it doesn't help.
>
> I'm using ossec2.6.
>
> Thanks for any help.
>
> Zoe
should be allowed. Unless you've blocked the IP somewhere else.
| | Zoe |
10/16/12
|
Thanks for reply.
No, IP is not blocked anywhere else.
IP is not in firewall, neither in hosts.deny. But is still blocked until timeout expired.
After 900s (timeout), IP is allowed, but not before. Evend if deleted from firewall and hosts.deny.
The question : how is defined timeout ? Where or how can i remove it after active-response is applied ?
No, IP is not blocked anywhere else.
IP is not in firewall, neither in hosts.deny. But is still blocked until timeout expired.
After 900s (timeout), IP is allowed, but not before. Evend if deleted from firewall and hosts.deny.
The question : how is defined timeout ? Where or how can i remove it after active-response is applied ?
- show quoted text -
| | dan (ddpbsd) |
10/16/12
|
On Tue, Oct 16, 2012 at 9:40 AM, Zoe <raea...@gmail.com> wrote:
> Thanks for reply.
>
> No, IP is not blocked anywhere else.
> IP is not in firewall, neither in hosts.deny. But is still blocked until
> timeout expired.
> After 900s (timeout), IP is allowed, but not before. Evend if deleted from
> firewall and hosts.deny.
>
> The question : how is defined timeout ? Where or how can i remove it after
> active-response is applied ?
>
Remove it from where-ever you set it. The supplied AR scripts don't do
> Thanks for reply.
>
> No, IP is not blocked anywhere else.
> IP is not in firewall, neither in hosts.deny. But is still blocked until
> timeout expired.
> After 900s (timeout), IP is allowed, but not before. Evend if deleted from
> firewall and hosts.deny.
>
> The question : how is defined timeout ? Where or how can i remove it after
> active-response is applied ?
>
anything fancy. Generally if you remove the IP from the firewall block
and from the hosts.deny block it'll be allowed. If you remove the
block from every place you have OSSEC set the block, it won't be
blocked (by OSSEC) anymore. It's that simple.
Since you haven't provided any useful information, that's all I can
help with. My guess would be you aren't using your tools correctly,
but that's just a guess.
- show quoted text -
| | Zoe |
10/16/12
|
Thanks for explication.
IP is not set anywhere else.
Sorry for the lack of information :
Ossec 2.6 is installed on server and agents with Suse Linux.
# ossec.conf on Ossec Server
<ossec_config>
...
<command>
<name>host-deny</name>
<executable>host-deny.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>firewall-drop</name>
<executable>firewall-drop.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>disable-account</name>
<executable>disable-account.
<expect>user</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>restart-ossec</name>
<executable>restart-ossec.sh</
<expect></expect>
</command>
<command>
<name>route-null</name>
<executable>route-null.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<active-response>
<command>host-deny</command>
<location>all</location>
<level>10</level>
<rules_id>11306</rules_id>
<timeout>900</timeout>
<repeated_offenders>15,30,60,
</active-response>
<active-response>-->
<command>firewall-drop</
<location>all</location>
<level>10</level>
<rules_id>11306</rules_id>
<timeout>900</timeout>
<repeated_offenders>15,30,60,
</active-response>
</ossec_config>
...
# ossec.conf on Ossec agent
<ossec_config>
<client>
<server-ip>1.1.1.2</server-ip>
</client>
<active-response>
<repeated_offenders>15,30,60,
</active-response>
</ossec_config>
Is there any other information that can help ?
Thanks in advance for your help.
Note : when ossec execute "firewall-drop delete" and "host-deny delete" after timeout, it's ok : IP is now allowed.
But when I execute these commands manually, firewall and hosts.deny are modified, but IP remains blocked...
Zoe
IP is not set anywhere else.
Sorry for the lack of information :
Ossec 2.6 is installed on server and agents with Suse Linux.
# ossec.conf on Ossec Server
<ossec_config>
...
<command>
<name>host-deny</name>
<executable>host-deny.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>firewall-drop</name>
<executable>firewall-drop.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>disable-account</name>
<executable>disable-account.
<expect>user</expect>
<timeout_allowed>yes</timeout_
</command>
<command>
<name>restart-ossec</name>
<executable>restart-ossec.sh</
<expect></expect>
</command>
<command>
<name>route-null</name>
<executable>route-null.sh</
<expect>srcip</expect>
<timeout_allowed>yes</timeout_
</command>
<active-response>
<command>host-deny</command>
<location>all</location>
<level>10</level>
<rules_id>11306</rules_id>
<timeout>900</timeout>
<repeated_offenders>15,30,60,
</active-response>
<active-response>-->
<command>firewall-drop</
<location>all</location>
<level>10</level>
<rules_id>11306</rules_id>
<timeout>900</timeout>
<repeated_offenders>15,30,60,
</active-response>
</ossec_config>
...
# ossec.conf on Ossec agent
<ossec_config>
<client>
<server-ip>1.1.1.2</server-ip>
</client>
<active-response>
<repeated_offenders>15,30,60,
</active-response>
</ossec_config>
Is there any other information that can help ?
Thanks in advance for your help.
Note : when ossec execute "firewall-drop delete" and "host-deny delete" after timeout, it's ok : IP is now allowed.
But when I execute these commands manually, firewall and hosts.deny are modified, but IP remains blocked...
Zoe
- show quoted text -
| | dan (ddpbsd) |
10/16/12
|
- show quoted text -
> Thanks in advance for your help.
>
> Note : when ossec execute "firewall-drop delete" and "host-deny delete"
> after timeout, it's ok : IP is now allowed.
> But when I execute these commands manually, firewall and hosts.deny are
> modified, but IP remains blocked...
>
something? All the scripts do is remove the IP from the firewall or
hosts.deny. Perhaps the firewall rules have to be re-applied or
something?
Other than that, I have no clue. I've never seen this problem, and
don't know why your system would be blocking something without any
reason to block it (ossec doesn't directly do any blocking). You'd
think there'd be a log somewhere though...
- show quoted text -
| | Zoe |
10/16/12
|
Operating System : Linux openSuse
I agree with you : that doesn't make any sense :)
Re-apply firewall rules ? already done, no change.
A copy of my ossec.conf is above, have I missed something ?
I "firewall-drop delete" on agent, have i to do it on server ? on server ad agents ? from server to agents ?
I check ossec.log on server, active-response.log on agents, nothing strange there. Nothing in system logs.
Can others log files help ?
I agree with you : that doesn't make any sense :)
Re-apply firewall rules ? already done, no change.
A copy of my ossec.conf is above, have I missed something ?
I "firewall-drop delete" on agent, have i to do it on server ? on server ad agents ? from server to agents ?
I check ossec.log on server, active-response.log on agents, nothing strange there. Nothing in system logs.
Can others log files help ?
- show quoted text -
| | dan (ddpbsd) |
10/16/12
|
On Tue, Oct 16, 2012 at 11:16 AM, Zoe <raea...@gmail.com> wrote:
> Operating System : Linux openSuse
>
> I agree with you : that doesn't make any sense :)
> Re-apply firewall rules ? already done, no change.
> A copy of my ossec.conf is above, have I missed something ?
Not that I'm aware of.
> Operating System : Linux openSuse
>
> I agree with you : that doesn't make any sense :)
> Re-apply firewall rules ? already done, no change.
> A copy of my ossec.conf is above, have I missed something ?
> I "firewall-drop delete" on agent, have i to do it on server ? on server ad
> agents ? from server to agents ?
the complete command, so hopefully you aren't getting that wrong in
production.
> I check ossec.log on server, active-response.log on agents, nothing strange
> there. Nothing in system logs.
> Can others log files help ?
>
logging for anything that doesn't currently log stuff like that I
- show quoted text -
| | Christian Beer |
10/16/12
|
I also use active_response (OSSEC 2.6) on a Debian
server and whenever I want to unblock someone I
delete the firewall rule directly using iptables commands. That
always works instantaneously. But I have only one machine. In
your setup using server/agent you have to unblock the IP at
every agent and the server separately. Running host-deny and/or
firewall-drop just on one machine is not enough because it is
not propagated to the others.
Regards
Christian
Am 16.10.2012 17:16, schrieb Zoe:
Regards
Christian
Am 16.10.2012 17:16, schrieb Zoe:
- show quoted text -
| | Zoe |
10/16/12
|
Thanks for you reply Christian.
ah ?
"Running host-deny and/or firewall-drop just on one machine is not enough because it is not propagated to the others."
I agree it
doesn't unblock on all machines, but on the single machine where IP has
been unblocked, I think it has to be unblocked, no ?
Dan,
Entire command I use is : "/var/ossec/active-response/
And nothing in logs.
Zoe
ah ?
"Running host-deny and/or firewall-drop just on one machine is not enough because it is not propagated to the others."
Dan,
Entire command I use is : "/var/ossec/active-response/
And nothing in logs.
Zoe
- show quoted text -
| | Zoe |
10/16/12
|
Other thing : when I manually run "firewall-drop add", command "firewall-drop delete" is ok, before timeout.
But when it's ossec who run it, with AR, a manual "firewall-drop delete" doesn't work...
Can you confirm me rights on /var/ossec files and directories please ?
But when it's ossec who run it, with AR, a manual "firewall-drop delete" doesn't work...
Can you confirm me rights on /var/ossec files and directories please ?
- show quoted text -
| | Zoe |
10/16/12
|
I
have 52 agents, is there possible as Christian said, that I have to
unblock IP on all agents before it's unblocked on just one ?
Regards.
Zoe
Regards.
Zoe
- show quoted text -
| | Zoe |
10/16/12
|
And the winner is ......Christian !
Thanks !
Thanks !
- show quoted text -
| | Zoe |
10/17/12
|
And of course thanks Dan.
Regards.
On Tuesday, October 16, 2012 8:00:50 PM UTC+2, Zoe wrote:
Regards.
On Tuesday, October 16, 2012 8:00:50 PM UTC+2, Zoe wrote:
And the winner is ......Christian !
Thanks !
On Tuesday, October 16, 2012 7:12:55 PM UTC+2, Zoe wrote:I have 52 agents, is there possible as Christian said, that I have to unblock IP on all agents before it's unblocked on just one ?Regards.e thanks- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Tue, Oct 16, 2012 at 2:00 PM, Zoe <raea...@gmail.com> wrote:
> And the winner is ......Christian !
> Thanks !
>
What's the answer? You have to unblock it from every system before it works?
> And the winner is ......Christian !
> Thanks !
>
- show quoted text -
| | jplee3 |
10/17/12
|
I've
setup some complex rules for blocking/unblocking but used null routing.
It's been a while so I'd have to refresh my memory completely, but I
believe I utilized the OSSEC agent to issue a local 'route' command and
could do it remotely (as opposed to logging into or running a specific
script for each agent/machine). I'd imagine the same or similar could be
done for iptables (or any script for that matter).
- show quoted text -
| | jplee3 |
10/17/12
|
I believe agent-control is the key here:
I
created a script to remove null-routes and I may have had to copy the
scripts to all boxes where this was to be implemented (I don't recall if
there is a mechanism in OSSEC that will push scripts down to agents).
Then I used agent-control to fire off the specific scripts for removing
the null-routes (this was probably per specific IP though).
- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Wed, Oct 17, 2012 at 12:54 PM, Jeremy Lee <jpl...@gmail.com> wrote:
> I believe agent-control is the key here:
>
> http://www.ossec.net/doc/
>
> I created a script to remove null-routes and I may have had to copy the
> scripts to all boxes where this was to be implemented (I don't recall if
> there is a mechanism in OSSEC that will push scripts down to agents). Then I
> used agent-control to fire off the specific scripts for removing the
> null-routes (this was probably per specific IP though).
>
>
> On Wed, Oct 17, 2012 at 9:44 AM, Jeremy Lee <jpl...@gmail.com> wrote:
>>
>> I've setup some complex rules for blocking/unblocking but used null
>> routing. It's been a while so I'd have to refresh my memory completely, but
>> I believe I utilized the OSSEC agent to issue a local 'route' command and
>> could do it remotely (as opposed to logging into or running a specific
>> script for each agent/machine). I'd imagine the same or similar could be
>> done for iptables (or any script for that matter).
>>
These mails do not address the problem in any way. If the blocks have
> I believe agent-control is the key here:
>
> http://www.ossec.net/doc/
>
> I created a script to remove null-routes and I may have had to copy the
> scripts to all boxes where this was to be implemented (I don't recall if
> there is a mechanism in OSSEC that will push scripts down to agents). Then I
> used agent-control to fire off the specific scripts for removing the
> null-routes (this was probably per specific IP though).
>
>
> On Wed, Oct 17, 2012 at 9:44 AM, Jeremy Lee <jpl...@gmail.com> wrote:
>>
>> I've setup some complex rules for blocking/unblocking but used null
>> routing. It's been a while so I'd have to refresh my memory completely, but
>> I believe I utilized the OSSEC agent to issue a local 'route' command and
>> could do it remotely (as opposed to logging into or running a specific
>> script for each agent/machine). I'd imagine the same or similar could be
>> done for iptables (or any script for that matter).
>>
to be removed from EVERY agent that implemented them before it will
work, then OSSEC has someone gained a level of clustering I never
imagined. How you remove the blocks shouldn't matter (although I still
don't know if Zoe ever tried to remove them manually).
- show quoted text -
| | jplee3 |
10/17/12
|
I
guess I'm not understanding the original problem but was going off of
what Christian was saying more so. Is the problem that an IP is being
blocked on the agent? Or on the server? My understanding was that the IP
was also blocked on the agent machine itself, requiring one to get onto
the agent machine run iptables directly there to unblock the legit
IP...? Is this *not* the case?
- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Wed, Oct 17, 2012 at 1:32 PM, Jeremy Lee <jpl...@gmail.com> wrote:
> I guess I'm not understanding the original problem but was going off of what
> Christian was saying more so. Is the problem that an IP is being blocked on
> the agent? Or on the server? My understanding was that the IP was also
> blocked on the agent machine itself, requiring one to get onto the agent
> machine run iptables directly there to unblock the legit IP...? Is this
> *not* the case?
>
From my understanding of the problem Zoe wants an IP unblocked before
> I guess I'm not understanding the original problem but was going off of what
> Christian was saying more so. Is the problem that an IP is being blocked on
> the agent? Or on the server? My understanding was that the IP was also
> blocked on the agent machine itself, requiring one to get onto the agent
> machine run iptables directly there to unblock the legit IP...? Is this
> *not* the case?
>
the timeout on agent001. The IP is removed from hosts.deny and
iptables (through the firewall_drop.sh script, still unsure whether a
manual removal was attempted or if the results were checked for
accuracy) on agent001. The block removal was supposedly successful,
but the IP was still blocked.
Still looking for confirmation on whether it was attempted to remove
the IP blocks manually (not with firewall_drop.sh), and whether the
final solution was to remove the blocks from all agents (not just
agent001).
I just setup a test environment and everything works properly for me.
Both agents blocked the IP. I remove the IP from agent001 manually
(pfctl -t ossec_fwtable -T delete 192.168.1.1) and 192.168.1.1 can
connect again. On the second agent I used the pf.sh script
(/var/ossec/active-response/
192.168.1.1 was again able to connect.
I did these individually, so the block was still in place on the other system.
- show quoted text -
| | jplee3 |
10/17/12
|
And
I thought Zoe's original intention was to "manually unblock" the IP
that was unable to access the agent machine that it was blocked at.
- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Wed, Oct 17, 2012 at 1:38 PM, Jeremy Lee <jpl...@gmail.com> wrote:
> And I thought Zoe's original intention was to "manually unblock" the IP that
> was unable to access the agent machine that it was blocked at.
>
Yep, and Zoe pasted (incorrect) commands to do so. Also, re-reading
> And I thought Zoe's original intention was to "manually unblock" the IP that
> was unable to access the agent machine that it was blocked at.
>
the original email you can see:
"It's ok : 1.1.1.1 is deleted from firewall's IP blacklisted IP and is also
deleted from hosts.deny."
which assumes Zoe double checked the removal.
deleted from hosts.deny."
So removing the IP wasn't the problem, the problem was that it didn't "work."
- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Tue, Oct 16, 2012 at 9:12 AM, Zoe <raea...@gmail.com> wrote:
> Hi guys,
>
> I set up ossec since few months now, but I have some problems with
> active-responses.
>
> Active-responses work well, no problem with it.
> When an alert is detected, a lot of failed authentication from the same IP
> for example, IP is blacklisted in the firewall, and all connections are
> dropped.
> I use a timeout of 900s and repeated_offenders.
>
> But, in some cases, it arrived that a legitimate IP was blacklisted : wrong
> password or other. It was blacklisted for 900s.
>
> I want to manually unblock the IP, so I execute the command :
> # /var/ossec/active-response/
> # /var/ossec/active-response/
>
Just a note for the archives, the above commands are incorrect. There
>
> I set up ossec since few months now, but I have some problems with
> active-responses.
>
> Active-responses work well, no problem with it.
> When an alert is detected, a lot of failed authentication from the same IP
> for example, IP is blacklisted in the firewall, and all connections are
> dropped.
> I use a timeout of 900s and repeated_offenders.
>
> But, in some cases, it arrived that a legitimate IP was blacklisted : wrong
> password or other. It was blacklisted for 900s.
>
> I want to manually unblock the IP, so I execute the command :
> # /var/ossec/active-response/
> # /var/ossec/active-response/
>
should be 3 arguments, not just 2. They give errors if you run them
like this.
I'm assuming Zoe used the correct commands, and not the ones posted.
- show quoted text -
| | jplee3 |
10/17/12
|
Ah
I think I jumped the gun on Zoe's initial comment that it worked,
assuming that Christian's suggestion was taken and was successful. But I
guess we have to hear more from Zoe.
In any case,
the information I gave was just more extraneous info in case anyone was
interested. Now that I think about it, I think I wrote a script that
called agent-control to have it iterate through either a list or params
(aka agent IDs) to force certain scripts (namely those that would
unblock IPs) to run.
- show quoted text -
| | dan (ddpbsd) |
10/17/12
|
On Tue, Oct 16, 2012 at 11:43 AM, Christian Beer
<cb.mai...@googlemail.com> wrote:
> I also use active_response (OSSEC 2.6) on a Debian server and whenever I
> want to unblock someone I delete the firewall rule directly using iptables
> commands. That always works instantaneously. But I have only one machine. In
> your setup using server/agent you have to unblock the IP at every agent and
> the server separately. Running host-deny and/or firewall-drop just on one
> machine is not enough because it is not propagated to the others.
>
> Regards
> Christian
>
No you don't. If those other agents aren't responsible for the traffic
<cb.mai...@googlemail.com> wrote:
> I also use active_response (OSSEC 2.6) on a Debian server and whenever I
> want to unblock someone I delete the firewall rule directly using iptables
> commands. That always works instantaneously. But I have only one machine. In
> your setup using server/agent you have to unblock the IP at every agent and
> the server separately. Running host-deny and/or firewall-drop just on one
> machine is not enough because it is not propagated to the others.
>
> Regards
> Christian
>
you don't have to delete it on them. Of course if you delete the block
on the firewall system, but not the webserver behind it you're not
going to have a good time.
- show quoted text -
No comments:
Post a Comment