diff --git a/exercises/ansible_security/1.1-explore/README.md b/exercises/ansible_security/1.1-explore/README.md index 00e39eb87..71e287b83 100644 --- a/exercises/ansible_security/1.1-explore/README.md +++ b/exercises/ansible_security/1.1-explore/README.md @@ -6,7 +6,7 @@ The objective of this lab is to provide you a deeper understanding and hands on We have set up a common set of security related tools: -- a Firewall, in this case [CheckPoint Next Generation Firewall](https://www.checkpoint.com/products/next-generation-firewall/) +- a Firewall, in this case [Check Point Next Generation Firewall](https://www.checkpoint.com/products/next-generation-firewall/) - a Security Information and Event Management (SIEM), here [QRadar](https://www.ibm.com/security/security-intelligence/qradar) - a Intrusion Detection & Prevention System, here [Snort](https://www.snort.org) @@ -76,9 +76,9 @@ For a start, log into your Ansible control host via SSH. Open a terminal and typ > **Warning** > -> In the following examples, replace **11.22.33.44** by your **IP** provided to you by the instructor, and the **X** in student**X** by the student number provided to you in the following example and in all other cases were examples contain IP addresses. +> In the next examples, replace **11.22.33.44** by the **IP** of your control host, provided to you by the instructor. Also, replace the **X** in student**X** by the student number provided to you. In all following examples and in all other cases were examples contain IP addresses, always replace them with the **IP** addresses from your individual setup -Open a terminal and type the following command: +Open a terminal and type the following command to connect to your control host via SSH: ```bash ssh studentX@11.22.33.44 @@ -86,12 +86,6 @@ ssh studentX@11.22.33.44 The password is **ansible** if not otherwise noted. -Then become root: - -```bash -[student@ansible ~]$ sudo -i -``` - Most prerequisite tasks have already been done for you: - Ansible software is installed @@ -100,13 +94,6 @@ Most prerequisite tasks have already been done for you: - `sudo` has been configured on the managed hosts to run commands that require root privileges. -Log out of the root account again: - -```bash - [root@ansible ~]# exit - logout -``` - Check Ansible has been installed correctly ```bash @@ -131,7 +118,6 @@ ansible_user=student1 ansible_ssh_pass=ansible ansible_port=22 - [attack] attacker ansible_host=99.88.77.66 ansible_user=ec2-user private_ip=172.16.99.66 private_ip2=172.17.44.66 @@ -151,6 +137,8 @@ checkpoint ansible_host=44.55.66.77 ansible_user=admin private_ip=192.168.4.5 an windows-ws ansible_host=55.66.77.88 ansible_user=Administrator ansible_pass=RedHat19! ansible_port=5986 ansible_connection=winrm ansible_winrm_server_cert_validation=ignore private_ip=192.168.5.6 ``` +On your control host, have a look at the inventory by executing the command `cat ~/lab_inventory/hosts`. All the IP addresses are specific to your environment. Whenever the exercises ask you to access a certain machine, you can always look up the IP in the inventory on the control host. + Ansible is already configured to use the inventory specific to your environment. As shown in the example above, the inventory carries more than just the host names and IP addresses. Especially in the case of the Windows workstation, several more parameters are set. > **Note** @@ -159,7 +147,7 @@ Ansible is already configured to use the inventory specific to your environment. ## Step 1.6 - Victim machine -For the exercises of section 2 we need to have security incidents. Those should happen on a **victim** machine. For the ease of deployment, we just use the Snort server for this: besides the installed Snort daemon it is a basic RHEL server and can be used to run all kinds of attacks against. +For the exercises of section 2 we need to have security incidents. Those should happen on a **victim** machine - that is Snort server. It is basically a RHEL installation with Snort installed and running a simplified web server to run attacks against. ## Step 1.7 - Working the Labs @@ -169,10 +157,6 @@ You might have guessed by now this lab is pretty commandline-centric…​ :-) - All labs were prepared using **Vim**, but we understand not everybody loves it. Feel free to use alternative editors. In the lab environment we provide **Midnight Commander** (just run **mc**, function keys can be reached via Esc-\ or simply clicked with the mouse) or **Nano** (run **nano**). Here is a short [editor intro](../0.0-support-docs/editor_intro.md). -> **Tip** -> -> In the lab guide commands you are supposed to run are shown with or without the expected output, whatever makes more sense in the context. - ---- [Click Here to return to the Ansible Security Automation Workshop](../README.md#section-1---introduction-to-ansible-security-automation-basics) diff --git a/exercises/ansible_security/1.2-checkpoint/README.md b/exercises/ansible_security/1.2-checkpoint/README.md index 08628ab6e..9126d635a 100644 --- a/exercises/ansible_security/1.2-checkpoint/README.md +++ b/exercises/ansible_security/1.2-checkpoint/README.md @@ -21,9 +21,7 @@ The Windows workstation can be reached via Remote Desktop Protocol (RDP). We rec Test the access to the MGMT server now by pointing your RDP client to the `windows-ws` IP in your inventory. -If you do not have a RDP client available or want to test the HTML RDP client, please open the following URL in your browser: `http:///myrtille`. Be sure to replace `` with the IP for the Windows workstation from your inventory. In the login field, only provide the user name and the password: The user name is **Administrator**, the password is **Ansible+Red*Hat19!20** if not provided otherwise. - -Upon first login there might be a message about a network interface in a blue bar on the right side. This message can be safely ignored and will disappear as soon as you click anywhere. +If you do not have a RDP client available or want to test the HTML RDP client, please open the following URL in your browser: `http:///myrtille`. Be sure to replace `` with the IP for the Windows workstation from your inventory. In the login field, only provide the user name and the password: The user name is **Administrator**, the password is **Ansible+Red*Hat19!20** if not provided otherwise. Leave the other fields empty, and click on **Connect**. You now are accessing a default windows workstation with a Google Chrome browser installed. @@ -71,7 +69,9 @@ In Ansible, automation is described in playbooks. Playbooks are files which desc A playbook is a repeatable set of *plays* and *tasks*. -A playbook can have multiple plays and a play can have one or multiple tasks. In a task a *module* is called, like the modules in the previous chapter. The goal of a *play* is to map a group of hosts. The goal of a *task* is to implement modules against those hosts. +A playbook can have multiple plays and a play can have one or multiple tasks. In a task a *module* is called, which does the actual work. + +The goal of a *play* is to map a group of hosts. The goal of a *task* is to implement modules against those hosts. If you are not very familiar with Ansible, see the following example of a playbook: @@ -104,9 +104,9 @@ If you are not very familiar with Ansible, see the following example of a playbo > > Here is a nice analogy: When Ansible modules are the tools in your workshop, the inventory is the materials and the playbooks are the instructions. -We will now write a playbook to change the configuration of the Check Point setup. We will start with a simple example where we will add a whilte entry in the firewall configuration to allow traffic from a certain machine to another. In our example we will allow the machine called **attacker** to send traffic to our machine **snort**. +We will now write a playbook to change the configuration of the Check Point setup. We will start with a simple example where we will add a whiltelist entry in the firewall configuration to allow traffic from a certain machine to another. In our example we will allow the machine called **attacker** to send traffic to our machine **snort**. -The playbook will be written and run on the Ansible control host. Use SSH to access your control host. On there, open an editor of your choice and create a file with the name `whitelist_attacker.yml`. +The playbook will be written and run on the Ansible control host. The languae the playbook is written in is [YAML](https://en.wikipedia.org/wiki/YAML). Use SSH to access your control host. On there, open an editor of your choice and create a file with the name: `whitelist_attacker.yml` First, a playbook needs a name and the hosts it should be executed on. So let's add those: @@ -116,13 +116,15 @@ First, a playbook needs a name and the hosts it should be executed on. So let's hosts: checkpoint ``` +In case you wonder: the three dashes at the top, `---`, indicate the start of a YAML file. + > **Note** > > It is a good practice to make playbooks more reusable by pointing them at `hosts: all` and limit the execution later on the command line or via Tower. But for now we simplify the process by naming hosts in the playbook directly. -As mentioned, in this a simple example we will add a whitelist entry. A simple whitelist entry consists of a source IP address, a destination IP address and the rule to prevent access between those. +As mentioned, in this a simple example we will add a whitelist entry. A simple whitelist entry consists of a source IP address, a destination IP address and the rule to allow access between those. -For this, we add the source and destination IP as variables to the playbook. Since Ansible knows all the machines from the inventory and since the IPs are listed in the inventory, we can just reference those information as variables: +For this, we add the source and destination IPs as variables to the playbook. Since Ansible knows all the machines from the inventory and since the IPs are listed in the inventory, we can just reference those information as [variables](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html) of the corresponding hosts: ```yaml @@ -136,7 +138,11 @@ For this, we add the source and destination IP as variables to the playbook. Sin ``` -Note that we use the second private IP - those belong to a network whihc is specifically routed via the FW for application traffic. The first private IP belongs to the management network. +As you see, variables are marked by curly brackets. Note that we use the second private IP - those belong to a network which is specifically routed via the FW for application traffic. The first private IP belongs to the management network. The variables are used to define yet another (shorter) variable each, which will be used throughout the playbook. This is a common way to decouple the data from the execution. + +> **Note** +> +> Make sure that the white spaces and indentation is exactly as shown: YAML is very picky about this, and many errors in running playbooks are due to wrong indentation. Next, we need to add the tasks where the actual changes on the target machines are done. This happens in three steps: first we create a source object, than a destination object, and finally the access rule between those two. @@ -160,7 +166,7 @@ Let's start with a task to define the source object: ``` -As you can see, the task itself has a name - just like the play itself - and references a module, here `checkpoint_hosts`. The module has parameters, here `name` and `ip_address`. Each module has individual parameters, often some of them are required while others are optional. To get more information about a module, you can call the help: +As you can see, the task itself has a name - just like the play itself - and references a module, here `checkpoint_hosts`. The module is the part of Ansible which "makes it so" - the module in this case creates of modifies host object entries in Check Point. The module has parameters, here `name` and `ip_address`. Each module has individual parameters, often some of them are required while others are optional. To get more information about a module, you can call the help: ```bash [student@ansible ~]$ ansible-doc checkpoint_host @@ -195,7 +201,7 @@ In the same way we defined the source IP host object, we will now add the destin ``` -Last, we are defining the actual access rule between those two host objects: +Last, we are defining the actual access rule between those two host objects and add a task to ensure that the policy is installed in any case. Sometimes this task fails if another installations is already running, so we add a special flag to ignore possible errors, `failed_when: false`: ```yaml @@ -237,8 +243,6 @@ Last, we are defining the actual access rule between those two host objects: ``` -The last task ensures that the policy is installed in any case. Since sometimes this task fails if another installations is already running we ignore possible errors here. - ## Step 2.6 - Run the playbook Playbooks are executed using the `ansible-playbook` command on the control node. Before you run a new playbook it’s a good idea to check for syntax errors: @@ -294,7 +298,8 @@ Afterwards, click on the **Install Policy** button at the top of the list of pol As a result, in the left corner a small window pops up informing you of the progress of the deployment of the change. -As you see, even doing a rather small change the configuraiton required multiple clicks and interactions with the user - the more of these steps can be automated, the better. +As you see, even doing a rather small change the configuration required multiple clicks and interactions with the user - the more of these steps can be automated, the better. + ---- [Click Here to return to the Ansible Security Automation Workshop](../README.md#section-1---introduction-to-ansible-security-automation-basics) diff --git a/exercises/ansible_security/1.3-snort/README.md b/exercises/ansible_security/1.3-snort/README.md index 43c08fb2f..afcf00da3 100644 --- a/exercises/ansible_security/1.3-snort/README.md +++ b/exercises/ansible_security/1.3-snort/README.md @@ -11,7 +11,7 @@ In this lab, Snort is installed on a Red Hat Enterprise Linux machine. Ansible i The Snort software is installed on a typical Red Hat Enterprise Linux system. Thus access to the server is performed via SSH. On you control host `ansible`, open your inventory again and find the IP address of you Snort server. This can also be done in one go with a single command: ```bash -[student@ansible ~]$ grep snort lab_inventory/hosts +[student@ansible ~]$ grep snort ~/lab_inventory/hosts snort ansible_host=22.333.44.5 ansible_user=ec2-user private_ip=172.16.1.2 ``` @@ -19,7 +19,7 @@ snort ansible_host=22.333.44.5 ansible_user=ec2-user private_ip=172.16.1.2 > > The IP addresses here are just an example and will be different in your case since you have a dedicated Snort setup in your individual lab environment. -Knowing this IP address, you can now access the Snort server: +Knowing this IP address, you can now access the Snort server. Note that the user for the Snort server is `ec2-user`! ```bash [student@ansible ~]$ ssh ec2-user@22.333.44.5 @@ -60,7 +60,7 @@ Exit the Snort server now by pressing `CTRL` and `D`, or by typing `exit` on the ## Step 3.3 - Simple Snort rules -On the most simple level, Snort works by reading rules and acting according to them. We will work with very simple examples of Snort in this lab to highlight how to automate Snort configuration with Ansible. This lab is not meant to dive into the specifics of Snort rules and what can be done with them in complex setups. But it helps to understand the basic structure of a simple Snort rule to better follow how to automate those. +On the most simple level, Snort works by reading rules and acting according to them. We will work with very simple examples of Snort in this lab to highlight how to automate Snort configuration with Ansible. This lab is not meant to dive into the specifics of Snort rules and what can be done with them in complex setups. But it helps if you understand the basic structure of a simple Snort rule to better follow how to automate those. Basically, a rule consists of a rule header and rule options and is saved in files. @@ -94,21 +94,21 @@ If you want to learn more about Snort rules, check out the [Snort Rule Infograph ## Step 3.4 - Example playbook -With this knowledge, now let's automate the Snort rule configuration! As described earlier, in Ansible automation is described in Playbooks, which consist of multiple tasks. Each task uses a module and corresponding parameters to describe the change that needs to be done or the state that is desired. +With this knowledge, now let's automate the Snort rule configuration! As described earlier, in Ansible automation is described in playbooks, which consist of multiple tasks. Each task uses a module and corresponding parameters to describe the change that needs to be done or the state that is desired. -In case of Snort, in Ansible 2.8 there are no modules to interact with Snort. So we wrote a set of modules to interact with Snort properly. That way, we can provide value already without the need to wait for a new Ansible release. Also we are able to update our modules faster which is especially important in the early times of a rather newer module. Those modules are shipped as part of a "role". But what are roles? +In case of Snort, in Ansible 2.9 there are no modules to interact with Snort. So we wrote a set of modules to interact with Snort properly. That way, we can provide value already without the need to wait for a new Ansible release. Also we are able to update our modules faster which is especially important in the early times of a rather newer module. Those modules are shipped as part of a "role". But what are roles? -Think about how you wrote your playbook in the last seciont: while it is possible to write a playbook in one file as we did, eventually you’ll want to reuse files and start to organize things. +Think about how you wrote your playbook in the last section: while it is possible to write a playbook in one file as we did, eventually you’ll want to reuse files and start to organize things when the playbook gets longer and multiple playbooks come together. Ansible Roles are the way we do this. When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure. -There are multiple advantages in using roles to write your automation code. The most notable are that the complexity and intelligence behind a set of playbooks is hidden away. Also the roles are usually easy to re-use by others. +There are multiple advantages in using roles to write your automation code. The most notable are that the complexity and intelligence behind a set of playbooks is hidden away. Also the roles are usually easy to be re-used by others. -Back to the Snort use case: as mentioned, the Snort modules are shipped as part of a role to manage Snort modules, [ids_rule](https://github.com/ansible-security/ids_rule). Open the link in the web browser and click on the [library](https://github.com/ansible-security/ids_rule/tree/master/library) link: you will find the module `snort_rule.py` there. +Back to the Snort use case: as mentioned, the Snort modules are shipped as part of a role to manage Snort modules. The role is called [ids_rule](https://github.com/ansible-security/ids_rule). Open the link in the web browser and in the shown Github repository, click on the [library](https://github.com/ansible-security/ids_rule/tree/master/library) path. You will find the module `snort_rule.py` there, which can create and change snort rules and is as thus part of the role. If you take an even closer look at the role you will realize that it also comes along with a re-usable playbook at [tasks/snort.yml](https://github.com/ansible-security/ids_rule/blob/master/tasks/snort.yml). -Let's have a look at how our playbook can be rewritten to use the roles directly. For this first we have to get the role onto our control machine. There are different ways how this can be achieved, but a very convenient way is to use the command line tool `ansible-galaxy`. It can install roles directly from archives, Git URLs - and it can also install roles from [Ansible Galaxy](https://galaxy.ansible.com). Ansible Galaxy is a community hub for finding and sharing Ansible content. It provides features like rating, quality testing, proper searching and so on. For example, the role mentioned above can be found in Ansible Galaxy at [ansible_security/ids_rule](https://galaxy.ansible.com/ansible_security/ids_rule). +Let's have a look at how our playbook can be rewritten to use the roles directly. For this first we have to get the role onto our control host. There are different ways how this can be achieved, but a very convenient way is to use the command line tool `ansible-galaxy`. It can install roles directly from archives, Git URLs - and it can also install roles from [Ansible Galaxy](https://galaxy.ansible.com). Ansible Galaxy is a community hub for finding and sharing Ansible content. It provides features like rating, quality testing, proper searching and so on. For example, the role mentioned above can be found in Ansible Galaxy at [ansible_security/ids_rule](https://galaxy.ansible.com/ansible_security/ids_rule). On your control host, use the `ansible-galaxy` tool to download and install the above mentioned role with a single command: @@ -168,13 +168,13 @@ Next, we need to add the tasks where the actual changes on the target machines a ids_rule_state: present ``` -Let's quickly look at what is actually happening here: the rule header is `alert tcp and any -> any any`, so we create an alert for tcp traffic from any source to any destination. The rule options define the human readable Snort message when the rule matches, and `uricontent` which is a specialized version of `content` making it easier to analyze URIs. The `classtype` is set to `attempted-user` which is the default class for "attempted user privilege gain" and the SID is set to a value high enough for user defined rules. The priority is `1`. Finally since this is the first version of this rule we set the revision to `1`. +Let's quickly look at what is actually happening here: the rule header is `alert tcp any any -> any any`, so we create an alert for tcp traffic from any source to any destination. The rule options define the human readable Snort message when the rule matches, and `uricontent` which is a specialized version of `content` making it easier to analyze URIs. The `classtype` is set to `attempted-user` which is the default class for "attempted user privilege gain" and the SID is set to a value high enough for user defined rules. The priority is `1`. Finally since this is the first version of this rule we set the revision to `1`. The other variables set the rules file a the user defined location and set that the rule should be created if not there (`present`). ## Step 3.5 - Run the playbook -It is now time to execute the playbook. Call `ansible-playbook` with the appropriate arguments! +It is now time to execute the playbook. Call `ansible-playbook` with the playbook name: ```bash [student1@ansible ~]$ ansible-playbook add_snort_rule.yml @@ -212,13 +212,13 @@ PLAY RECAP ********************************************************************* snort : ok=4 changed=2 unreachable=0 failed=0 skipped=4 rescued=0 ignored=0 ``` -As you see there are many more tasks executed than just the mere adding of the rules. The role takes care of reloading the Snort service after the rule was added. Other tasks verify that the entered variables are in fact correct. +As you see there are many more tasks executed than just the mere adding of the rules. For example the role takes care of reloading the Snort service after the rule was added. Other tasks verify that the entered variables are in fact correct. -This shows again how valuable re-usable roles can be: it is possible to not only make your content re-usable, you can also add verification tasks and other important steps which are neatly hidden inside the role. +This shows again how valuable re-usable roles can be: it is possible to not only make your content re-usable, you can also add verification tasks and other important steps which are neatly hidden inside the role. Users of the role do not need to know the specifics of how Snort works to use the role and embed it into their automation. ## Step 3.6 - Verfiy changes -The quick way to see if the rules were properly written is to check the content of the `/etc/snort/rules/local.rules` file on the Snort server. +A quick way to see if the rules were properly written is to check the content of the `/etc/snort/rules/local.rules` file on the Snort server. Another way is to use Ansible for this: we created an Ansible role to find existing rules in Snort: [ids_rule_facts](https://github.com/ansible-security/ids_rule_facts). Let's use it to verify that the rule is indeed installed on the Snort server. @@ -309,7 +309,7 @@ PLAY RECAP ********************************************************************* snort : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -The last task outputs the actual rule which was found by the role. +The last task outputs the actual rule which was found by the role. And in fact it is the rule we previously added. You are done with the first steps of automating Snort with Ansible. Head back to the exercise overview and continue with the next step. diff --git a/exercises/ansible_security/1.4-qradar/README.md b/exercises/ansible_security/1.4-qradar/README.md index b8a057688..61201a222 100644 --- a/exercises/ansible_security/1.4-qradar/README.md +++ b/exercises/ansible_security/1.4-qradar/README.md @@ -2,7 +2,7 @@ ## Step 4.1 - IBM QRadar -To showcase how to automate the SIEM in a security environment, this lab contains a [IBM QRadar SIEM, community edition](https://developer.ibm.com/qradar/ce/). +To showcase how to automate a SIEM in a security environment, this lab contains a [IBM QRadar SIEM, community edition](https://developer.ibm.com/qradar/ce/). The SIEM can be accessed via web UI and via REST API. In this lab the playbooks we write will be interacting with the API in the background. All actions will be verified in the web UI. @@ -23,7 +23,7 @@ You are now viewing the IBM QRadar main web interface. To get an idea of QRadar and the basic concepts, let's have a short look at the interface: in the upper part there is a navigation bar with multiple entry points into the main parts of QRadar. - **Dashboard**, providing a central overview -- **Offenses**, messages or events generated through a monitored condition +- **Offenses**, messages or events generated by a monitored condition - **Log Activity**, showing collected events from log sources - **Network Activity**, network traffic communication between certain hosts - **Assets**, automatically created profiles of network devices and hosts in your environment @@ -37,12 +37,11 @@ For the purpose of the demo, we will have a closer look at the **Offenses**: cli > > Since this is a demo environment, it is likely that the list of offenses is currently empty. -Offenses are messages or events generated based upon findings for example in log files or network traffic: for example a malicious log line appears somewhere. QRadar triggers offenses based on rules: the rules describe conditions, and when a condition is met, the offense is the result. +Offenses are messages or events generated based upon findings in log messages or network traffic, like a malicious log line. QRadar triggers offenses based on rules: the rules describe conditions, and when a condition is met, the offense is the result. To say it with the words of the official documentation: -> *Rules, sometimes called correlation rules are applied to events, flows, or offenses to search for or detect anomalies. If all the conditions of a test are met, the rule generates response.* -> *Source: [QRadar documentation](https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_rul_mgt.html)* +> *Rules, sometimes called correlation rules are applied to events, flows, or offenses to search for or detect anomalies. If all the conditions of a test are met, the rule generates response. ([QRadar documentation](https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_rul_mgt.html))* In a productive environment it is common to create more and more custom rules over time. But for now, let's have a look at the rules which are already installed on the system: in the **Offenses** window, on the left side in the navigation bar, click on **Rules**. A long list of rules is displayed. In the search bar on top of this list, enter the following search term: `DDoS` Hit enter afterwards to filter the list. @@ -116,7 +115,7 @@ With the collection in place, we can now start to write our playbook. ## Step 4.3 - First example playbook -To write a first example to interface with QRadar we are going to enable/disable a rule. It is a rather small but common change and shows how Ansible and QRadar interact. +In our first example to interface with QRadar we are going to enable/disable a rule. It is a rather small but common change and shows how Ansible and QRadar interact. On your control host, open an editor to create a new file, `change_qradar_rule.yml`. Add the name and target hosts, here `qradar`. @@ -136,7 +135,7 @@ We also want to use the collections we just added. Collections can be referenced - ibm.qradar ``` -Next we bring in the actual tasks. The REST API of QRadar is worked in a way that we first have to search for a proper rule to find out its ID, and then deactive a rule with the given ID. For the sake of this lab, let's say the rule which creates messages based on a suspected DDoS attack. In the last section we already had a look at the QRadar rules via **Offenses** > **Rules**, and filitered them for the term **DDoS**. In the filtered list, note the first rule shown there, **"Potential DDoS Against Single Host (TCP)"**. We will use this string to search for the role using the module `qradar_rule_info`: +Next we bring in the actual tasks. The REST API of QRadar is desgined in a way that we first have to search for a proper rule to find out its ID, and then deactive the rule by referencing the given ID. For the sake of this lab, let's say the rule which creates messages based on a suspected DDoS attack. In the last section we already had a look at the QRadar rules via **Offenses** > **Rules**, and filitered them for the term **DDoS**. In the filtered list, note the first rule shown there, **"Potential DDoS Against Single Host (TCP)"**. We will use this string to search for the role using the module `qradar_rule_info`: ```yaml --- @@ -151,7 +150,7 @@ Next we bring in the actual tasks. The REST API of QRadar is worked in a way tha name: "DDoS Attack Detected" ``` -This module returns a lot of information, among those the ID we need to actually disable to role. Let's register the returned information into a variable that we can reuse those with the help of the `register` keyword which is directly used with the actual module. +This module returns a lot of information, among those the ID we need to actually disable the role. Let's register the returned information into a variable with the help of the `register` keyword. It is directly used with the module itself. This enables us to use the content of the variable in the next task. ```yaml --- @@ -240,7 +239,7 @@ As you see, the debug task `output returned rule_info` shows the content of the > > The key id might be different in your case. -How do we get the key when it is in this structure? First, it is in the segment `rules` of the variable, which we can access via `rule_info.rules`. Inside of `rules` there is actually a list (note the curly brackets), but with only one entry - so we access it with `rule_info.rules[0]`. And from within the list entry we can access each key individually via its name: `rule_info.rules[0].id`. +How do we get the key when it is in this structure? First, it is in the segment `rules` of the variable, which we can access via `rule_info.rules`. Inside of `rules` there is actually a list (note the curly brackets), but with only one entry - so we access it with `rule_info.rules[0]`. And from within the list entry we can access each key individually via its name: `rule_info.rules[0]['id']`. So, let's provide this as a value to the module which can disable the rule, `qradar_rule`. At the same time we can remove the debug entry since it is not needed for the actual execution. @@ -261,7 +260,7 @@ So, let's provide this as a value to the module which can disable the rule, `qra - name: disable rule by id qradar_rule: state: disabled - id: "{{ rule_info.rules[0].id }}" + id: "{{ rule_info.rules[0]['id'] }}" ``` diff --git a/exercises/ansible_security/2.1-suspicious/README.md b/exercises/ansible_security/2.1-suspicious/README.md index 20fbf74c7..efc7c6407 100644 --- a/exercises/ansible_security/2.1-suspicious/README.md +++ b/exercises/ansible_security/2.1-suspicious/README.md @@ -2,9 +2,7 @@ ## Step 1.1 - The Background -In the last section the focus was on single tools and how they can be automated with Ansible. In the daily operation of security practitioners the need is one step higher: when something suspicious happens and needs further attention, security operations need to deploy many tools to secure an enterprise it. In many enterprise environments, security solutions are not integrated with each other and, in large organizations, different teams are in charge of different aspects of IT security, with no processes in common. - -That often leads to manual work and interaction between people of different teams which is error prone and above all, slow. +In the last section the focus was on single tools and how they can be automated with Ansible. In the daily operation of security practitioners the need is one step higher: when something suspicious happens and needs further attention, security operations need to deploy many tools to secure an enterprise IT. In many enterprise environments, security solutions are not integrated with each other and, in large organizations, different teams are in charge of different aspects of IT security, with no processes in common. That often leads to manual work and interaction between people of different teams which is error prone and above all, slow. In comes Ansible: we use Ansible to elevate the interactions learned in the last section to combine the security tools into automated workflows. @@ -40,13 +38,15 @@ Execute the playbook: > **Note** > -> Basically in this playbook we register a small daemon running watch, which will execute a command all 5 seconds. This is a rather harsh way to start a repeating task, but serves the purpose of the demo. +> Basically in this playbook we register a small daemon running watch, which will execute a command every 5 seconds. This is a rather harsh way to start a repeating task, but serves the purpose of the demo. The stage is set now. Read on to learn what this use case is about. ## Step 1.3 - See the anomaly -Imagine you are a security analyst in an enterprise. You were just informed of an anomaly in an application. On your control host, ssh to the snort machine, and grep for the anomaly log entry: +Imagine you are a security analyst in an enterprise. You were just informed of an anomaly in an application. On your control host, ssh to the snort machine. Remember that you can get the IP of the Snort server by executing this command on the control host: `grep snort ~/lab_inventory/hosts` . As the login user for the Snort server, you need to use `ec2-uesr`! + +On the Snort server, grep for the anomaly log entry: ```bash [student1@ansible ~]$ ssh ec2-user@11.22.33.44 @@ -56,11 +56,13 @@ Last login: Sun Sep 22 15:38:36 2019 from 35.175.178.231 ... ``` +You can log off from the Snort server by executing the command `exit` or pressing `CTRL` and `D`. + > **Note** > > You might have guessed already: this log entry is triggered every five seconds by the daemon we started at the beginning of this exercise. -As a security analyst you know that anomalies can be the sign of a breach or other serious causes. You decide to investigate. Right now, you do not have enough information about the anomaly to dismiss it as a false positive. So you need to collect more data points - like from the firewall and the IDS. Going through the logs of the firewall and IDS manually takes a lot of time. In large organizations, the security analyst might not even have the necessary access rights and needs is to contact the teams responsible for both the enterprise firewall and the IDS, asking them to manually go through the respective logs and directly check for anomalies on their own and then reply with the results. This operation could take hours or even days. +As a security analyst you know that anomalies can be the sign of a breach or other serious causes. You decide to investigate. Right now, you do not have enough information about the anomaly to dismiss it as a false positive. So you need to collect more data points - like from the firewall and the IDS. Going through the logs of the firewall and IDS manually takes a lot of time. In large organizations, the security analyst might not even have the necessary access rights and needs to contact the teams that each are responsible for both the enterprise firewall and the IDS, asking them to manually go through the respective logs and directly check for anomalies on their own and then reply with the results. This operation could take hours or even days. ## Step 1.4 - Write playbook to create new log sources @@ -70,13 +72,13 @@ Doing this manually requires a lot of work on multiple machines, which again tak > **Note** > -> Why don't we add those logs to QRadar permanently? The reason is that many log systems are licensed/paid by the amount of logs they consume, making it expansive pushing non-necessary logs in there. Also, if too many logs are in there it becomes harder to analyse the data properly and in an timely manner. +> Why don't we add those logs to QRadar permanently? The reason is that many log systems are licensed/paid by the amount of logs they consume, making it expansive pushing non-necessary logs in there. Also, if too many logs are in there it becomes harder to analyse the data properly and in a timely manner. So let's write such a playbook which first configures the log sources - Snort and Check Point - to send the logs to QRadar, and afterwards add those log sources to QRadar so that it is aware of them. As usual, the playbook needs a name and the hosts it should be executed on. Since we are working on different machines in this workflow, we will separate the playbook into different "[plays](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#playbook-language-example)": -> *The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks. At a basic level, a task is nothing more than a call to an ansible module (see Working With Modules).* +> *The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks. At a basic level, a task is nothing more than a call to an ansible module.* This means that the "host" section will appear multiple times in one playbook, and each section has a dedicated task list. @@ -115,7 +117,7 @@ So let's create our playbook where we use the role. On your control host, create ``` -As you see, just like with the last time we configured Snort rules, we are re-using the role and let it do the work. We only change the behaviour of the role via the parameters - which provides the QRadar IP via variable. +As you see, just like with the last time we configured Snort rules, we are re-using the role and let it do the work. We only change the behaviour of the role via the parameters: we provide the QRadar IP via variable, set the IDS provider to `snort` and define the protocol in which packages are sent as `UDP` Now we have to tell QRadar that there is this new Snort log source. Add the following play to the playbook `triage_log_sources.yml`: @@ -137,7 +139,7 @@ Now we have to tell QRadar that there is this new Snort log source. Add the foll ``` -You might ask what the regex is doing in there: it changes the IP address to match the actual syslog header entry produced by snort. Otherwise, the logs would not be properly identified as QRadar. +As you can see the collections are used here, and the only task we execute uses a module to manage log sources in QRadar. You might ask what the regex is doing in there: it changes the IP address to match the actual syslog header entry produced by Snort. Otherwise, the logs would not be properly identified as QRadar. Now we have to do the same for Check Point: we need to configure Check Point that it should forward its logs to QRadar. This can be configured with an already existing role, [log_manager](https://github.com/ansible-security/log_manager), so all we have to do is to import the role and use it with the right parameters. First, let's import the role: @@ -171,9 +173,7 @@ Note that in this snippet you have to replace `YOURSERVERNAME` with the actual s ```bash [student@ansible ~]$ ssh admin@11.33.44.55 -[Expert@gw-77f3f6:0]# ls -l /opt/CPrt-R80/log_exporter/targets -total 0 -drwxr-xr-x 6 admin root 168 Sep 16 11:23 syslog-22.33.44.55 +[Expert@gw-77f3f6:0]# ``` Another way to find the correct name of the management instance is to connect to the Check Point management IP directly via https in your web browser. That way, the operating system management web interface is shown, with the machine name in the top right corner: @@ -287,11 +287,13 @@ Run the full playbook to add both log sources to QRadar: [student@ansible ~]$ ansible-playbook triage_log_sources.yml ``` +In Check Point SmartConsole you might even see a little window pop up in the bottom left corner informing you about the progress. If that gets stuck at 10% you can usually safely ignore it, the log exporter works anyway. + ## Step 1.6 - Verify the log source configuration Before that Ansible playbook was invoked, QRadar wasn’t receiving any data from Snort or Check Point. Immediately after, without any further intervention by us as security analyst, Check Point logs start to appear in the QRadar log overview. -Log onto the QRadar web UI. Click on Log Activity. As you will see, there are a lot of logs coming in all the time: +Log onto the QRadar web UI. Click on **Log Activity**. As you will see, there are a lot of logs coming in all the time: ![QRadar Log Activity showing logs from Snort and Check Point](images/qradar_log_activity.png) @@ -299,11 +301,11 @@ Many of those logs are in fact internal QRadar logs. To get a better overview, c ![QRadar Log Activity showing logs from Snort and Check Point](images/qradar_filter_logs.png) -Now the list of logs is better to analyze. Verify that events are making it to QRadar from Check Point. If that is not the case straight away, check if logs are coming in for the log source **SIM GENERIC LOG DSM-7**. In that case, wait a minute or two. Sometimes it takes a little bit of time until QRadar identifies a new log source and sorts logs acoordingly instead. until then the logs are identified as coming from an unknown source and are sorted into the generic log source. +Now the list of logs is better to analyze. Verify that events are making it to QRadar from Check Point. If that is not the case straight away, check if logs are coming in for the log source **SIM GENERIC LOG DSM-7**. In that case, wait a minute or two. Sometimes it takes a little bit of time until QRadar identifies a new log source and sorts logs acoordingly. Until then the logs are identified as coming from an unknown source and are sorted into the generic log source. Also, if you change the **View** from **Real Time** to for example **Last 5 Minutes** you can even click on individual events to see more details of the data the firewall sends you. -Let's verify that QRadar also properly shows the log source. In the QRadar UI, click on the burger menu in the left upper corner, and click on **Admin**. In there, click on **Log Sources**. A new window opens and shows the new log sources. +Let's verify that QRadar also properly shows the log source. In the QRadar UI, click on the "hamburger button" (three horizontal bars) in the left upper corner, and click on **Admin** down at the bottom. In there, click on **Log Sources**. A new window opens and shows the new log sources. ![QRadar Log Sources](images/qradar_log_sources.png) @@ -316,9 +318,9 @@ total 0 drwxr-xr-x 6 admin root 168 Sep 16 11:23 syslog-22.33.44.55 ``` -As you can see the central log server was configured via Check Point's internal log expoerter tool. +As you can see the central log server was configured via Check Point's internal log exporter tool. Leave the Check Point server and go back to your control host. -Let's also verify that the Snort configuration in the background was successful. Via SSH, log onto your Snort instance, become root and verify the rsyslog forwarding configuration: +Let's also verify that the Snort configuration in the background was successful. From your control host, log onto your Snort instance via SSH as the user `ec2-user`. Become root and verify the rsyslog forwarding configuration: ```bash [student@ansible ~]$ ssh ec2-user@22.33.44.55 @@ -335,6 +337,8 @@ $InputRunFileMonitor local3.* @44.55.66.77:514 ``` +Leave the Snort server again and come back to your control host. + Note that so far no logs are sent from Snort to QRadar: Snort does not know yet that this traffic is noteworthy! But as a security analyst, with more data at our disposal, we finally have a better idea of what could be the cause of the anomaly in the application behaviour. We see the logs from the firewall, see who is send traffic to whom, but still not enough data to dismiss the event as a false positive. @@ -373,7 +377,7 @@ In the previous Snort exercise we already added a Snort rule with a signature to ``` -As you can see the `ids_rule` containes the `web_attack_simulation` string as content, making it possible to identify future occurences of this behaviour. +In this play we provide some variables for Snort stating that we want to control any traffic on tcp. Afterwards, with the help of the `ids_rule` role we set a new rule containing the `web_attack_simulation` string as content, making it possible to identify future occurences of this behaviour. Now execute the playbook: @@ -381,7 +385,7 @@ Now execute the playbook: [student@ansible ~]$ ansible-playbook triage_snort_rule.yml ``` -Let's quickly verify that the new rule was indeed added. From your Ansible control host ssh to the Snort server and have a look into the directory of custom rules: +Let's quickly verify that the new rule was indeed added. From your Ansible control host ssh to the Snort server as `ec2-user` and have a look into the directory of custom rules: ```bash [student@ansible ~]$ ssh ec2-user@11.22.33.44 @@ -392,7 +396,7 @@ alert tcp any any -> any any (msg:"Attempted Web Attack"; uricontent:"/web_atta ## Step 1.8 - Identify and close the Offense -Moments after the playbook have been executed, we can check in QRadar if we see Offenses. And indeed, that is the case. Log into your QRadar UI, click on **Offenses**, and there on the right side on **All Offenses**: +Moments after the playbook has been executed, we can check in QRadar if we see Offenses. And indeed, that is the case. Log into your QRadar UI, click on **Offenses**, and there on the left side on **All Offenses**: ![QRadar Offenses](images/qradar_offenses.png) @@ -406,6 +410,8 @@ In the final step, we will rollback all the configuraiton changes to their pre-i We create a new playbook, `rollback.yml`, based on the `triage_log_sources.yml`. The major differnces are that for QRadar we set the state of the log sources to `absent`, for Snort we set `ids_config_remote_log` to `false`, and for Check Point we initiate the tasks for `unforward_logs_to_syslog`. +The playbook `rollback.yml` should have this content: + ```yaml --- @@ -476,6 +482,8 @@ We create a new playbook, `rollback.yml`, based on the `triage_log_sources.yml`. > > Again, remember to replace the value of `YOURSERVERNAME` with the actual server name of your Check Point instance. +While this playbook is maybe the longest you see in these entire exercises, the structure and content should already be familiar to you. Take a second to go through each task to understand what is happening. + Run the playbook to remove the log sources: ```bash diff --git a/exercises/ansible_security/2.2-threat/README.md b/exercises/ansible_security/2.2-threat/README.md index 98dc7a0d9..98762fe81 100644 --- a/exercises/ansible_security/2.2-threat/README.md +++ b/exercises/ansible_security/2.2-threat/README.md @@ -2,15 +2,15 @@ ## Step 2.1 - The Background -Like in our last exercise, threat detection and response capabilities require from a security operator typically to deploy many tools to secure an enterprise IT. +Threat detection and response capabilities require from a security operator typically to deploy many tools to secure an enterprise IT. Due to missing processes and a lot of manual work this is a serious challenge to proper IT security operations! -In this exercise, we imagine that we are a security operator in charge of an enterprise firewall in a larger organization. The firewall product used here is Check Point. +In this exercise, we imagine that we are a security operator in charge of an enterprise firewall in a larger organization. The firewall product used here is Check Point Next Generation Firewall. ## Step 2.2 - Preparations -For this exercise to work properly, the playbook `whitelist_attacker.yml` must have been run at least once. Also the logging for the attacker whitelist policy must have been activated. Both was done in the Check Point exercise. If you missed the steps, go back there, execute the playbook, follow the steps to activate the logging and come back here. +For this exercise to work properly, the playbook `whitelist_attacker.yml` must have been run at least once. Also the logging for the attacker whitelist policy must have been activated. Both was done in the Check Point exercise in section 1. If you missed the steps, go back there, execute the playbook, follow the steps to activate the logging and come back here. -Also, in the Check Point web interface, go to **SECURITY POLICIES**. You will see two entries there. On the upper one, in the column action, click on **Accept**. This open a menu: click on **Drop** there, changing the policy to drop such packets. In the menu above, click on **Install Policy**, that opens a window, click the **Publish & Install** there. Another window opens, please click on **Install** there. This way we have effectively changed the whitelist to a blacklist entry. +Also, in the Check Point SmartConsole interface, go to **SECURITY POLICIES**. You will see two entries there. On the upper one, in the column action, click on **Accept**. This open a menu: click on **Drop** there, changing the policy to drop such packets. In the menu above, click on **Install Policy**, that opens a window, click the **Publish & Install** button there. Another window opens, click on the **Install** button there. This way we have effectively changed the whitelist to a blacklist entry. > **Note** > @@ -48,7 +48,7 @@ You are a security operator in charge of an enterprise firewall in a larger coop ![Check Point logs view, violation logs](images/smartconsole_violation_logs.png) -As you can see, a series of "deny" messages repeated over time. +As you can see, a series of messages with the description **http Traffic Dropped** there, repeating again and again over time. > **Note** > @@ -56,7 +56,7 @@ As you can see, a series of "deny" messages repeated over time. ![Check Point logs view, auto refresh button](images/smartconsole_auto_refresh.png) -Seeing these violations we should start an investigation to assess if they are the outcome of an attack. The best way to investigate is to correlate the firewall logs with logs generated by other security solutions deployed in our network - like QRadar. +Seeing these violations we should start an investigation to assess if they are the outcome of an attack. The best way to investigate is to correlate the firewall logs with logs generated by other security solutions deployed in our network - like Snort - in a log management tool like QRadar. ## Step 2.4 - Create and run a playbook to forward logs to QRadar @@ -64,7 +64,7 @@ However, as mentioned in many enterprise environments security solutions are not But, as shown with the last exercise, we can automate this process with Ansible! The can be pre-approved automation workflows in form of playbooks, provided to us by the security analysis team. With such an Ansible playbook, every time we are in a threat hunting situation, we can automatically configure the enterprise firewall to send its events/logs to the QRadar instance that security analysts use to correlate the data and decide how to proceed with the potential threat. -Let's write a playbook to enable log forwarding from Check Point to QRadar, create a log source in QRadar and enable an offense rule. We can partially re-use the main playbook from the last exercise where we already connected Check Point with QRadar. +Let's write a playbook to enable log forwarding from Check Point to QRadar and create a log source in QRadar. We can partially re-use the main playbook from the last exercise where we already connected Check Point with QRadar. On your control host, create the file `threat_cp_log.yml` with the following content: @@ -114,9 +114,11 @@ Execute the playbook: [student@ansible ~]$ ansible-playbook threat_cp_log.yml ``` +In Check Point SmartConsole you might even see a little window pop up in the bottom left corner informing you about the progress. If that gets stuck at 10% you can usually safely ignore it, the log exporter works anyway. + ## Step 2.5 - Verify new configuration -Let's quickly verify the new configuration, like we did in the last exercise. We start with Check Point: In Check Point the easiest way to verify that the log source is set is indeed via command line. From your control host `ansible`, use SSH to log into the Check Point management server IP with the user admin and issue the following `ls` comand: +Let's quickly verify the new configuration, like we did in the last exercise. We start with Check Point: In Check Point the easiest way to verify that the log source is set is indeed via command line. From your control host `ansible`, use SSH as the user `admin` to log into the Check Point management server and issue the following `ls` comand. If you do not remember your Check Point server IP address, check it out with `grep checkpoint ~/lab_inventory/hosts` ```bash [student@ansible ~]$ ssh admin@11.33.44.55 @@ -125,13 +127,15 @@ total 0 drwxr-xr-x 6 admin root 168 Sep 16 11:23 syslog-22.33.44.55 ``` +Leave the Check Point management server again with `exit` + Imagine we are now the security analysts in charge of QRadar. As such, without any further doing, we suddenly get additional logs in QRadar. Verfify this by logging into the QRadar web UI. Click on **Log Activity** and verify that events are making it to QRadar from Check Point: ![QRadar Log Activity showing logs from Check Point](images/qradar_checkpoint_logs.png) If the logs get drowned in QRadar's own logs, create a filter. Or click on unwanted log lines in the column **Log Source**, and pick **Filter on Log Source is not ...** to create filters on the fly to filter out unwanted traffic. -Let's verify that QRadar also properly shows the log source. In the QRadar UI, click on the burger menu in the left upper corner, and click on **Admin**. In there, click on **Log Souces**. A new window opens and shows the new log source. +Let's verify that QRadar also properly shows the log source. In the QRadar UI, click on the hamburger button in the left upper corner, and click on **Admin**. In there, click on **Log Souces**. A new window opens and shows the new log source. ![QRadar Log Sources](images/qradar_log_sources.png) @@ -141,15 +145,13 @@ Next we want to manage Offenses shown in QRadar. Currently non are generated - b ![QRadar Preconfigured Rules](images/qradar_preconfigured_rules.png) -Click on the rule called **Ansible Workshop DDOS Rule**. The rule wizard window opens, allowing us changes to the offense rule if needed: +Double-click on the rule called **Ansible Workshop DDOS Rule**. The rule wizard window opens, allowing us changes to the offense rule if needed: ![QRadar Rules Wizard](images/qradar_rule_wizard.png) -From the wizard you can see that we only use very checks (second box in the window). Rules can be much more complex, cna even depend on other rules and as a result do not have to create offenses, but for example can create additional log entries. We will not do any changes here, so leave the wizard with a click on **Cancel** in the bottom right corner and confirm the close-warning of your browser. +From the wizard you can see that we only use very checks (second box in the window). Rules can be much more complex, can even depend on other rules and as a result do not have to create offenses, but for example can create additional log entries. We will not do any changes here, so leave the wizard with a click on **Cancel** in the bottom right corner and confirm the close-warning of your browser. -With all these information we, as a security analyst, are now able to verify that the source IP is part of the company pool, and that it should be allowed to access the application. - -However, to decide if this violation is a false positive, we need to make sure that other sources are not performing an attack which we might not see in the firewall. To do that we need to access the logs generated by the IDS and decide to check for a specific attack pattern that could be compatible with the violation on the firewall. +To decide if this violation is a false positive, we need to make sure that other sources are not performing an attack which we might not see in the firewall. To do that we need to access the logs generated by the IDS and decide to check for a specific attack pattern that could be compatible with the violation on the firewall. ## Step 2.7 - Add Snort rule @@ -162,7 +164,7 @@ On your control host, create the file `threat_snort_rule.yml` to add a new rule ```yaml --- -- name: Add ids signaturesa for ddos +- name: Add ids signature for ddos hosts: ids become: yes @@ -193,7 +195,7 @@ Run the playbook: [student@ansible ~]$ ansible-playbook threat_snort_rule.yml ``` -Quickly verify the new rule on the Snort instance: +Quickly verify the new rule on the Snort instance. From your control host log in to Snort via SSH with the user `ec2user`: ```bash [student@ansible ~]$ ssh ec2-user@11.22.33.44 @@ -202,6 +204,8 @@ Last login: Fri Sep 20 15:09:40 2019 from 54.85.79.232 alert tcp any any -> any any (msg:"Attempted DDoS Attack"; uricontent:"/ddos_simulation"; classtype:successful-dos; sid:99000010; priority:1; rev:1;) ``` +Leave the Snort server via the command `exit` + Also we have to make sure that logs from Snort make it to QRadar, so let's reuse parts of the playbook from the last exercise. Create a file called `threat_snort_log.yml`: @@ -260,7 +264,7 @@ Instead of starting even another manual interaction with the firewall team to ha For this we can re-use the playbook we wrote earlier in the first Check Point exercise, `whitelist_attacker.yml`. Run the playbook, to effectively white list the IP: ```bash -[student@ansible ~]$ ansible-playbook whitelist-attacker.yml +[student@ansible ~]$ ansible-playbook whitelist_attacker.yml ``` Verify that the IP is now whitelisted and does not generate deny messages in Check Point anymore. Open the SmartConsole on your Windows workstation, access the Check Point management server and go to the logs tab. diff --git a/exercises/ansible_security/2.3-incident/README.md b/exercises/ansible_security/2.3-incident/README.md index c613a7ec7..8af8b8263 100644 --- a/exercises/ansible_security/2.3-incident/README.md +++ b/exercises/ansible_security/2.3-incident/README.md @@ -13,7 +13,7 @@ We will start this exercise with an operator looking at logs in Snort. So first ```yml --- -- name: Add ids signaturesa for sql injection simulation +- name: Add ids signature for sql injection simulation hosts: ids become: yes @@ -99,7 +99,7 @@ User-Agent: curl/7.29.0 Host: 172.17.30.140 Accept: */* ``` -Besides some weird characters you will see the actual malformed "attack" of the user in the form of the string `sql_injection_simulation`. +Besides some weird characters you will see the actual malformed "attack" of the user in the form of the string `sql_injection_simulation`. Leave the Snort server with the command `exit` . ## Step 3.4 - Create and run a playbook to forward logs to QRadar @@ -141,6 +141,11 @@ On your Ansible control host, create a playbook called `incident_snort_log.yml` state: present description: "Snort rsyslog source" identifier: "{{ hostvars['snort']['private_ip']|regex_replace('\\.','-')|regex_replace('^(.*)$', 'ip-\\1') }}" + + - name: deploy the new log sources + qradar_deploy: + type: INCREMENTAL + failed_when: false ``` @@ -158,6 +163,10 @@ Let's change our perspective briefly to the one of a security analyst: we mainly Remember that it helps to add filters to the QRadar log view to get a better overview. Note that those logs already show the offense marker on the left side! +> **Note** +> +> If no logs are shown, wait a bit. It might take more than a minute to show the first entries. Also, the first logs might be identified with the right log source (showing **SIM Generic Log DSM-7** instead of **Snort rsyslog source**) so give it some time. + In the offenses tab filter the list of offenses for **Error Based SQL Injection**. Open the Offense summary to check the details of the attacker IP address previously seen in Snort logs. ## Step 3.6 - Blacklist IP diff --git a/exercises/ansible_security/README.md b/exercises/ansible_security/README.md index 121faf1b8..ea7ba7773 100644 --- a/exercises/ansible_security/README.md +++ b/exercises/ansible_security/README.md @@ -1,8 +1,8 @@ # Ansible Workshop - Ansible Security Automation -Ansible is a simple yet powerful IT automation engine for application deployment, configuration management, and orchestration that you can learn quickly. This workshop shows, step by step, how you can reach this goal using Ansible to orchestrate 3 investigation and response activities involving multiple security tools - an enterprise firewall (CheckPoint Next Generation Firewall), an intrusion detection system (Snort) and a SIEM (IBM QRadar). +Ansible is a simple yet powerful IT automation engine for application deployment, configuration management, and orchestration that you can learn quickly. Ansible Security Automation is our expansion deeper into the security use case. The goal is to provide a more efficient, streamlined way for security teams to automate their various processes for the identification, search, and response to security events. -Learn and practice how Ansible can be used to automate different security platforms. Understand how Ansible Automation can support security teams to create more efficient and streamlined investigation and remediation processes. +In this workshop shows you will learn - step by step - how you can use Ansible to orchestrate 3 security investigation and response activities involving multiple security tools: an enterprise firewall (CheckPoint Next Generation Firewall), an intrusion detection system (Snort) and a SIEM (IBM QRadar). **Read this in other languages**: [![uk](../../images/uk.png) English](README.md). diff --git a/provisioner/roles/manage_ec2_instances/templates/security_instances.txt.j2 b/provisioner/roles/manage_ec2_instances/templates/security_instances.txt.j2 index 703577325..36fb93cb3 100644 --- a/provisioner/roles/manage_ec2_instances/templates/security_instances.txt.j2 +++ b/provisioner/roles/manage_ec2_instances/templates/security_instances.txt.j2 @@ -12,7 +12,6 @@ attacker ansible_host={{ vm.public_ip_address }} ansible_user={{ vm.tags.usernam {% endif %} {% endfor %} - [control] {% for vm in ansible_node_facts.instances %} {% if 'student' + item == vm.tags.Student %}