Use the links to help you answer the 3 questions please: http://ossec-docs.readt

Question

Use the links to help you answer the 3 questions please:

http://ossec-docs.readthedocs.org/en/latest/manual/index.html

http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.active-response.html

1.       How would you configure active response to send the block to all agents?

2.       When would you block a user vs block an IP (host-deny.sh vs firewall-drop.sh)? When would you want to use both in conjunction?

3.       Looking in the rules directory for sshd, how would you add a threshold so that the server does not block on 1 failed login attempt? What do you believe would be the proper amount of attempts before blocking a user at the host firewall? And what timeframe?

Explanation / Answer

Active Response-The Active Response feature within OSSEC can run applications on an agent or server in response to certain triggers.The active response framework is also what allows an OSSEC administrator to start a syscheck scan or restart OSSEC on a remote agent.

The Active Response feature within OSSEC can run applications on an agent or server in response to certain triggers. These triggers can be specific alerts, alert levels, or rule groups.We need to configure ossec to run the active response. In my case, If you want to run it on the ossec server (so I choose location server) and every time the rule 1002 is fired (see rules_id 1002). You can also specify the level or different locations.

Create active response script -  We can create the active response script. The mail-test.sh must be inside the /var/ossec/active-response/bin/ with the execution permissions set. The arguments are passed to the script are -

After the configuration is done, you can restart OSSEC and test the configuration. For thee above example, I can run the logger command to similar a segmentation fault message.

The Active response configuration is divided into two parts. In the first one you configure the commands you want to execute. In the second one, you bind the commands to rules or events.In the commands configuration you create new “commands” to be used as responses. You can have as many commands as you want. Each one should be inside their own “command” element. For further information please see the examples.

name: Used to link the command to the response.

executable: It must be a file (with exec permissions) inside “/var/ossec/active-response/bin”.

You don’t need to provide the whole path.

expect: The arguments this command is expecting (options are srcip and username).

timeout_allowed: Specifies if this command supports timeout.

Responses Configuration - In the active-response configuration, you bind the commands (created) to events. You can have as many responses as you want. Each one should be inside their own “active-response” element. For further information please see the <../../syntax/head_ossec_config.active-response.html#example-active-response-con figurations>

disabled: Disables active response if set to yes.

command: Used to link the response to the command

location: Where the command should be executed. You have four options:

agent_id: The ID of the agent to execute the response (when defined-agent is set).

level: The response will be executed on any event with this level or higher.

timeout: How long until the reverse command is executed (IP unblocked, for example).

To start, you need to enable active response on Windows (disabled by default). To do that, just add the following to the agent’s ossec.conf:

After that, you need to go to the manager and specify when to run the response. Adding the following to ossec.conf will enable the responses for alerts above level 6

In the active response configuration section, you bind an existing command to one or more rules or rule types and specify additional criteria for when to actually execute the command. It is possible to have as many responses as needed, but each must be in their own separate <active-response> section.

Disabled - This is a special-case option, in that it occurs alone in its own active-response section for the sole purpose of enabling or disabling the active response facility in Wazuh. In the absence of a section like this, active response is by default enabled on Unix-like systems, and disabled on Windows systems.

Setting it to yes on an agent will disable active-response for that agent only, while setting it in the manager’s ossec.conffile will disable active-response on the manager and all agents.

command-This is used to link the response to the command.

location-This indicates on which system(s) the command should be executed.

agent_id-The ID of the agent to execute the active response command (used when defined-agent is set).

level-This defines a minimum severity level required for the command to be executed.

rules_group-This requires that a rule must belong to one or more rule groups for the command to be executed.

rules_id-This limits command execution to only when one or more listed rules fire.

timeout-This specifies how long in seconds until the reverse command is executed. When repeated_offenders is used, timeout only applies to the first offense.

repeated_offenders-This is a comma-separated list of increasing timeouts in minutes for repeat offenders. There can be a maximum of 5 entries. This must be configured directly in the ossec.conf file of the agent, even when using a manager/agent setup with centralized configuration of other settings via agent.conf.

Local configuration - The ossec.conf file is the main configuration file on the Wazuh manager, and it also plays a role on the agents. It is located at /var/ossec/etc/ossec.conf both in the manager and agent. It is recommended you back up this file before making changes to it, as an error in the configuration can completely prevent Wazuh services from starting up,The ossec.conf file is in XML format, and all configuration options are nested in their appropriate section of the file. In this file, the outermost XML tag is <ossec_config>. For example, here is an example of the proper location of the alertsconfiguration section:

The agent.conf file is very similar to ossec.conf except that it is used to centrally distribute configuration information to agents.

Configuration-

Related Questions

Navigate

• Browse (All)
• Browse U
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.