Re: [ossec-list] Manually unblock IP blackisted by active-reponse before timeout expiration

[dan (ddp)]

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/bin/host-deny.sh delete 1.1.1.1
> # /var/ossec/active-response/bin/firewall-drop.sh delete 1.1.1.1
>
> 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 ??
>

How would we know?

> I already try a reboot of agent, it doesn't help.
>
> I'm using ossec2.6.
>
> Thanks for any help.
>
> Zoe

If you remove the IP from the hosts.deny and the firewall block, it
should be allowed. Unless you've blocked the IP somewhere else.

[dan (ddp)]

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
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.

[dan (ddp)]

On Tue, Oct 16, 2012 at 10:49 AM, Zoe <raea...@gmail.com> wrote:
> 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</executable>
> <expect>srcip</expect>
> <timeout_allowed>yes</timeout_allowed>
> </command>
>
> <command>
> <name>firewall-drop</name>
> <executable>firewall-drop.sh</executable>
> <expect>srcip</expect>
> <timeout_allowed>yes</timeout_allowed>
> </command>
>
> <command>
> <name>disable-account</name>
> <executable>disable-account.sh</executable>
> <expect>user</expect>
> <timeout_allowed>yes</timeout_allowed>
> </command>
>
> <command>
> <name>restart-ossec</name>
> <executable>restart-ossec.sh</executable>
> <expect></expect>
> </command>
>
> <command>
> <name>route-null</name>
> <executable>route-null.sh</executable>
> <expect>srcip</expect>
> <timeout_allowed>yes</timeout_allowed>
> </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,120</repeated_offenders>
> </active-response>
>
> <active-response>-->
> <command>firewall-drop</command>
> <location>all</location>
> <level>10</level>
> <rules_id>11306</rules_id>
> <timeout>900</timeout>
> <repeated_offenders>15,30,60,120</repeated_offenders>
> </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,120</repeated_offenders>
> </active-response>
> </ossec_config>
>
> Is there any other information that can help ?
>

Operating system?

> 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...
>

That doesn't make any sense. Are you positive you haven't missed
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...

> Zoe

[dan (ddp)]

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.

> I "firewall-drop delete" on agent, have i to do it on server ? on server ad
> agents ? from server to agents ?

Only on the systems blocking the IP. And "firewall-drop delete" is not
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 ?
>

Whatever is blocking the IP should log something, right? Turn on
logging for anything that doesn't currently log stuff like that I
guess.

[Christian Beer]

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:

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 ?

[dan (ddp)]

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?

>
> 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.
>>
>> Zoe
>>
>> On Tuesday, October 16, 2012 6:10:21 PM UTC+2, Zoe wrote:
>>>
>>> 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 ?
>>>
>>> On Tuesday, October 16, 2012 5:56:59 PM UTC+2, Zoe wrote:
>>>>
>>>> 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/bin/firewall-drop.sh delete - 1.1.1.1"
>>>>
>>>> And nothing in logs.

[Jeremy Lee]

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). 

[Jeremy Lee]

I believe agent-control is the key here:

http://www.ossec.net/doc/manual/ar/ar-windows.html

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).

[dan (ddp)]

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/manual/ar/ar-windows.html
>
> 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
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).

[Jeremy Lee]

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?

[dan (ddp)]

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
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/bin/pf.sh delete ddpbsd 192.168.1.1), and
192.168.1.1 was again able to connect.

I did these individually, so the block was still in place on the other system.

[Jeremy Lee]

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. 

[dan (ddp)]

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
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.

So removing the IP wasn't the problem, the problem was that it didn't "work."

[dan (ddp)]

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/bin/host-deny.sh delete 1.1.1.1
> # /var/ossec/active-response/bin/firewall-drop.sh delete 1.1.1.1
>

Just a note for the archives, the above commands are incorrect. There
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.

> 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 ??
>

[Jeremy Lee]

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.

[dan (ddp)]

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
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.