In We explained how to launch a stable version of Suricata on Ubuntu 18.04 LTS. Setting up an IDS on a single node and connecting free rule sets is quite simple. Today, we will discuss how to protect a corporate network against the most common types of attacks using Suricata installed on a virtual server. We will need a Linux VDS with two CPU cores. The amount of RAM depends on the load: some may get by with 2 GB, while more serious tasks may require 4 or even 6. The advantage of a virtual machine is the possibility of experimentation: you can start with a minimal configuration and scale resources as needed.
Photo: Reuters
Merging Networks
Moving the IDS to a virtual machine is primarily necessary for testing. If you have never dealt with such solutions, it would not be wise to rush into ordering physical hardware and changing the network architecture. It is better to safely and economically test the system to identify computational resource needs. It is important to understand that all corporate traffic will need to pass through a single external node: to connect the local network (or several networks) to the VDS with the installed Suricata IDS, you can use — an easy-to-configure cross-platform VPN server that provides reliable encryption. The office internet connection may not have a real IP, so it's better to set it up on a VPS. There are no ready-made packages in the Ubuntu repository; you’ll need to download the software either from , or from an external repository on the service (if you trust it):
sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get updateYou can view the list of available packages with the following command:
apt-cache search softether 
We will need softether-vpnserver (the server in the test configuration is running on the VDS), as well as softether-vpncmd — command-line utilities for its configuration.
sudo apt-get install softether-vpnserver softether-vpncmdA special command-line utility is used to configure the server:
sudo vpncmd 
We won't go into detail about the setup: the procedure is quite simple and is well described in numerous publications, so it doesn't relate directly to the article topic. Briefly, after launching vpncmd, you need to select option 1 to enter the server management console. To do this, enter the name localhost and press enter instead of entering the hub name. In the console, set the administrator password with the command serverpasswordset, delete the virtual hub DEFAULT with the command hubdelete, and create a new hub named Suricata_VPN, also specifying its password (command hubcreate). Next, switch to the management console of the new hub using the command hub Suricata_VPN to create a group and user with the commands groupcreate and usercreate. Set the user password with userpasswordset.
SoftEther supports two traffic transmission modes: SecureNAT and Local Bridge. The first is a proprietary technology for building a virtual private network with its own NAT and DHCP. SecureNAT does not require TUN/TAP or configuring Netfilter or any other firewall. Routing does not affect the system's kernel, and all processes are virtualized and run on any VPS/VDS regardless of the hypervisor used. This leads to increased CPU load and reduced speed compared to Local Bridge mode, which connects the SoftEther virtual hub to a physical network adapter or TAP device.
In this case, the setup is more complicated because routing occurs at the kernel level using Netfilter. Our VDS is built on Hyper-V, so in the last step, we create a local bridge and activate the TAP device with the command bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. After exiting the hub management console, we will see a new network interface in the system that has not yet been assigned an IP:
ifconfig 
Next, you will need to enable packet forwarding between interfaces (ip forward) if it is not active:
sudo nano /etc/sysctl.confUncomment the following line:
net.ipv4.ip_forward = 1Save the changes to the file, exit the editor, and apply them with the following command:
sudo sysctl -pNext, we need to define a subnet for the virtual network with dummy IPs (for example, 10.0.10.0/24) and assign an address to the interface:
sudo ifconfig tap_suricata_vp 10.0.10.1/24Then you will need to specify Netfilter rules.
1. If necessary, allow incoming packets on the listening ports (the SoftEther proprietary protocol uses HTTPS and port 443)
sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT2. Configure NAT from the subnet 10.0.10.0/24 to the server's main IP
sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.1403. Allow passing packets from the subnet 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Allow passing packets for already established connections
sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPTWe will leave the automation of the process during system restart using initialization scripts as homework for the readers.
If you want to issue IPs to clients automatically, you will also need to install some DHCP service for the local bridge. With that, the server configuration is complete and you can move on to the clients. SoftEther supports multiple protocols, the use of which depends on the capabilities of the local network hardware.
netstat -ap |grep vpnserver 
Since our test router also runs on Ubuntu, we will install the packages softether-vpnclient and softether-vpncmd from an external repository to use the proprietary protocol. The client will need to be started:
sudo vpnclient startFor configuration, we will use the vpncmd utility, selecting localhost as the machine where vpnclient is running. All commands are executed in the console: it will be necessary to create a virtual interface (NicCreate) and an account (AccountCreate).
In some cases, it is necessary to specify the authentication method using the commands AccountAnonymousSet, AccountPasswordSet, AccountCertSet, and AccountSecureCertSet. Since we are not using DHCP, the address for the virtual adapter is assigned manually.
Additionally, we will need to enable IP forwarding (the parameter net.ipv4.ip_forward=1 in the /etc/sysctl.conf file) and configure static routes. If necessary, port forwarding can be configured on the VDS with Suricata to use the services installed in the local network. At this point, the network merging can be considered complete.
The proposed configuration will look something like this:
Configuring Suricata
In We discussed two modes of IDS operation: through the NFQUEUE (NFQ mode) and through zero copy (AF_PACKET mode). The latter requires two interfaces but offers better performance — we will use this one. The parameter is set by default in /etc/default/suricata. We will also need to edit the vars section in /etc/suricata/suricata.yaml, specifying the virtual subnet as the home network.
To restart the IDS, use the command:
systemctl restart suricataThe solution is ready; now you may need to test its resilience against malicious actions.
Modeling attacks
There can be several scenarios for the operational use of an external IDS service:
Protection against DDoS attacks (primary purpose)
Implementing such an option within a corporate network is challenging since packets for analysis must reach the interface facing the internet. Even if the IDS blocks them, parasitic traffic can overwhelm the data transmission channel. To avoid this, it is advisable to order a VPS with a sufficiently powerful internet connection capable of handling all local network traffic and all external traffic. This is often easier and cheaper than upgrading the office bandwidth. Alternatively, there are specialized services for DDoS protection. The cost of their services is comparable to that of a virtual server, and there is no need for labor-intensive setup, although there are downsides — for their fee, the client receives only DDoS protection, whereas their own IDS can be configured freely.
Protection against external attacks of other types
Suricata is capable of handling attempts to exploit various vulnerabilities in services accessible from the internet in the corporate network (mail server, web server, web applications, etc.). Typically, IDS is installed inside the local network after the perimeter devices, but external deployment is also valid.
Protection against internal threats
Despite all efforts by the system administrator, computers in the corporate network can be infected with malware. Moreover, local troublemakers sometimes attempt to carry out unauthorized operations. Suricata can help block such attempts, although for internal network protection, it is better to install it inside the perimeter and use it in conjunction with a managed switch capable of mirroring traffic to a single port. An external IDS is also not useless in this case — at least it can catch attempts by malicious software residing in the local network to contact an external server.
First, let's create another test attack VPS and set up Apache with the default configuration on the local network router, after which we will forward port 80 from the IDS server to it. Next, we will simulate a DDoS attack from the attacking node. For this, we will download, compile, and run a small program called xerxes from GitHub on the attacking node (you may need to install the gcc package):
git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.git
cd xerxes-DDos-zanyarjamal-C/
gcc xerxes.c -o xerxes
./xerxes 45.132.17.140 80The result of its execution was as follows:
Suricata intercepts the attacker, and the default Apache page opens despite our improvised attack and the rather poor bandwidth of the 'office' (actually home) network. For more serious tasks, it is worth using . It is intended for penetration testing and can simulate a variety of attacks. Installation instructions can be found on the project site. After installation, an update will be required:
sudo msfupdateTo test, we launch msfconsole.
Unfortunately, the latest versions of the framework lack the ability for automatic hacking, so exploits have to be selected manually and launched with the use command. First, it’s worth determining the open ports on the target machine, for example, using nmap (in our case, netstat on the target node will suffice), and then selecting and using the appropriate .
There are also other tools to test the resilience of IDS to attacks, including online services. Out of curiosity, one can conduct stress testing using a trial version of To check the reaction to actions by internal attackers, it's advisable to install specialized tools on one of the machines in the local network. There are many options, and they should periodically be applied not only to the experimental environment but also to operational systems, though that's a different story altogether.
Source: habr.com
