Creëer een moderne cloudomgeving
In this blog post, we will show the capabilities of Azure sentinel for the use of third-party connectors that can be used in real-life scenarios. The example in this post will highlight some of the features that can be used for Cisco appliances like CiscoASA firewalls and other Cisco networking devices. There will also be a section highlighting some of the features that can be used by connecting a Linux server to Sentinel using the network monitoring tool Snort.
Section 1: Setting up a Sentinel Workspace
To make use of the functionalities of Sentinel, a Log Analytics Workspace is required. This can be done by going to the Azure Sentinel Workspaces page and clicking on the “Add.”
When creating a workspace, choose the right subscription and resource group settings to ensure the right devices can be connected to the workspace in a later stage of the process. Choose a fitting name and select the correct region.
For the pricing tier, the pay-as-you-go model can be used to bill the used data per Gigabyte.
Section 2: Connecting datasets with Azure
Connecting CiscoASA logs
To set up a connection through Sentinel, the connectors page can be used to feed the Commonsecuritylogs of the Cisco devices into the Azure Log Analytics Workspace. For the parsing of these logs, a Microsoft monitoring agent (OMSAgent) is required. The OMSAgent is installed on an intermediary Linux device to parse and send the required log files to the Analytics Workspace.
This can be done by navigating to the connectors page and following the instructions given by Microsoft.
To download and install the OMSAgent, the following command can be used with the corresponding primary key and workspace ID (These can be found in the Security Events Data Connector page).
| wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w
|
| logging host dmz1
|
| Logging trap 6 |
After executing these commands, the logs will be sent to the Sentinel Log workspace.
Connecting Linux Syslog
If you want to connect a Linux machine to Azure Sentinel and to read the Syslog file, you need to connect the “Syslog” Data connector. This allows Sentinel to view all the Syslog data to Sentinel.
To forward the logs to Sentinel, an OMSagent needs to be installed on the Linux machine. When opening the Syslog connector page, Azure provides you with commands and a personal key to install the Linux agent. For verification purposes, you need to enter your workspace ID and your primary key. To get this information, you can navigate to the advanced settings on the Data connector page and select the agent you want to configure.
For more detailed information, I would suggest reading the Microsoft Documentation.
Section 3: Real-life use cases
Linux
Snort configuration
Installing Snort is an easy thing to do since there is a guide on the website for the commands that you are going to need. The hard part is configuring Snort so that it will work properly for your purposes. Snort offers a wide variety of configuration values that you need to configure to make it work. If options are left open, Snort might end up giving you an error and stop running. In the configuration that I used, there were only a few options needed, so I ended up filtering/disabling the configurations that were not necessary.
Log files
Snort uses its own log file for triggered alerts, even if the command is used that the output should be logged in Syslog. To solve this issue, I made sure that the output is set to Syslog in the configuration file.
Eventually, I had to use folder redirection to get the output in Syslog. From here on out, Sentinel is able to read the triggered alerts from Syslog.
Snort alerts
Snort has its own feature of setting up alert rules whether Snort is configured as an IDS or IPS. In my example, I made an alert that will monitor TCP traffic and will trigger an alert if a Telnet or FTP connection is made.
| alert tcp any 23 -> any any (msg:”WARNING! Telnet connection detected.”; flow:to_server; priority: 2; sid:10200; rev:10;) |
| alert tcp any any -> any 21 (msg:“WARNING! FTP connection detected.”; flow:to_server; priority: 3; sid:10300; rev:30;) |
When any of these connections are made, it will be logged in a specific log file that will look similar to this:
To start snort in IDS mode and to make sure Snort monitors on the custom alert rule, I wrote the path the local.rules file where the alert is written.
| sudo snort -s -M -A console -k none -I eth0 -c /etc/snort/rules/local.rules |
Sentinel query
In the custom alert rule, a custom number is set for each alert. This makes it easy for Sentinel to filter on this certain number. In the Snort alert, the number ‘10200’ is the given value for when a Telnet connection is made. The query in Sentinel only needs to search for when this number is triggered in Syslog.
| let threshold = 5; Syslog | where SyslogMessage contains “10200” | where TimeGenerated >= ago(20m) | summarize count() by tostring(SyslogMessage) | where count_ > threshold |
When a telnet connection is made, and a username + password combination is used for logging in, there are about 5 to 6 entries in Syslog. In order to not get spammed with alerts for just one connection, the threshold is set to 5. When the alert is triggered, the information we got back, we can see the alert message that was made in Snort, the given priority, and the IP-addresses with the port numbers that were used.
Cisco
Real-life Use case: Potentially successful brute force attack
After setting up the workspace, queries can be executed from the logs page.
It is also possible to create your own custom scheduled alert queries to monitor the activities on the CiscoASA devices. These can be created in the Analytics page > Create scheduled query rule. This makes it possible to set up an alert that will notify you when certain thresholds in the query are met. These alerts can be very useful for monitoring the Azure environment. To give a practical example, I have prepared a real-life use case that can be implemented to detect potentially successful brute force attacks.
When a Cisco device is connected to the internet with inbound port 22 (SSH) enabled, malicious users might try to guess the username and password (via brute force) to get access to the machine. If these activities are detected by Sentinel, an alert will be created.
To show the capabilities of the KQL language used in Sentinel there is also a possibility to detect if a user is logged in successfully after a brute-force attack is performed. This can be done with the following Alert rule:
| CommonsecurityLog | where TimeGenerated >=ago(5m) | where Message contains “authentication failed” | extend IpAdr = tostring(split(Message, “ “)[7]) | extend User = tostring(split(Message, “ “)[9]) | summarize count() by tostring(IpAdr), Message, User | where count_ > 5 | join ( CommonSecurityLog | where TimeGenerated >=(5m) | where Message contains “authentication succeeded” | extend IpAdr = tostring(split(Message, “ “)[7]) | extend User = tostring(split(Message, “ “)[9]) ) on IpAdr | where User == User1 |
The query above uses two conditions. If both conditions are met, the alert will be triggered.
KQL is used to detect authentication failure messages in the Cisco Commonsecuritylogs. The split function is used to filter out the originating IP address out of these failure messages. If these messages exceed a certain number, the condition is true. The second condition checks if there is a successful login attempt from the originating IP in the first statement. The two conditions are compared, and if both are true in the given timeframe, the alert will inform about a potential successful brute force attack.
Summary
In conclusion to our real world-examples, we can determine that the possibility of third-party applications in Sentinel gives the platform a lot of scalability and variety. With the support and constant development cycle of Microsoft, this product and the supported applications will keep on improving. We are excited to see what can be improved in the future and how Sentinel can be implemented in cloud environments around the world. We hope these practical examples give a form of inspiration to consider implementing these services in your personal or corporate cloud environment. For more information on supported third-party apps, check out the Microsoft documentation.
