Π we have covered how to run the stable version of Suricata on Ubuntu 18.04 LTS. Setting up an IDS on a single node and enabling free rule sets is pretty straightforward. Today we will figure out how to protect a corporate network using the most common types of attacks using Suricata installed on a virtual server. To do this, we need a VDS on Linux with two computing cores. The amount of RAM depends on the load: 2 GB is enough for someone, and 4 or even 6 may be required for more serious tasks. The advantage of a virtual machine is the ability to experiment: you can start with a minimal configuration and increase resources as needed.
photo: Reuters
Connecting networks
Removing IDS to a virtual machine in the first place may be needed for tests. If you have never dealt with such solutions, you should not rush to order physical hardware and change the network architecture. It's best to run the system safely and cost-effectively to determine your compute needs. It is important to understand that all corporate traffic will have to be passed through a single external node: to connect a local network (or several networks) to a VDS with IDS Suricata installed, you can use - An easy-to-configure, cross-platform VPN server that provides strong encryption. An 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 will have to download the software either from , or from an external repository on the service (if you trust him):
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 VDS), as well as softether-vpncmd - command line utilities for configuring it.
sudo apt-get install softether-vpnserver softether-vpncmdA special command line utility is used to configure the server:
sudo vpncmd
We will not talk in detail about the setting: the procedure is quite simple, it is well described in numerous publications and does not directly relate to the topic of the article. In short, after starting vpncmd, you need to select item 1 to go to the server management console. To do this, you need to enter the name localhost and press enter instead of entering the name of the hub. The administrator password is set in the console with the serverpasswordset command, the DEFAULT virtual hub is deleted (hubdelete command) and a new one is created with the name Suricata_VPN, and its password is also set (hubcreate command). Next, you need to go to the management console of the new hub using the hub Suricata_VPN command to create a group and user using the groupcreate and usercreate commands. The user password is set using userpasswordset.
SoftEther supports two traffic transfer 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 Netfilter or other firewall settings. Routing does not affect the core of the system, and all processes are virtualized and work on any VPS / VDS, regardless of the hypervisor used. This results in increased CPU load and slower speed compared to Local Bridge mode, which connects the SoftEther virtual hub to a physical network adapter or TAP device.
Configuration in this case becomes more complicated, since routing occurs at the kernel level using Netfilter. Our VDS are built on Hyper-V, so in the last step we create a local bridge and activate the TAP device with the bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes command. 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 have to enable packet routing between interfaces (ip forward), if it is inactive:
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 fictitious 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 need to write Netfilter rules.
1. If necessary, allow incoming packets on listening ports (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. Set up NAT from the 10.0.10.0/24 subnet to the main server 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 when the system is restarted using initialization scripts to the readers as homework.
If you want to give IP to clients automatically, you will also need to install some kind of DHCP service for the local bridge. This completes the server setup and you can go to the clients. SoftEther supports many protocols, the use of which depends on the capabilities of the LAN equipment.
netstat -ap |grep vpnserver
Since our test router also runs under Ubuntu, let's install the softether-vpnclient and softether-vpncmd packages from an external repository on it to use the proprietary protocol. You will need to run the client:
sudo vpnclient startTo configure, use the vpncmd utility, selecting localhost as the machine on which the vpnclient is running. All commands are made in the console: you will need to create a virtual interface (NicCreate) and an account (AccountCreate).
In some cases, you must specify the authentication method using the AccountAnonymousSet, AccountPasswordSet, AccountCertSet, and AccountSecureCertSet commands. Since we are not using DHCP, the address for the virtual adapter is set manually.
In addition, we need to enable ip forward (option net.ipv4.ip_forward=1 in the /etc/sysctl.conf file) and configure static routes. If necessary, on VDS with Suricata, you can configure port forwarding to use the services installed on the local network. On this, the network merging can be considered complete.
Our proposed configuration will look something like this:
Setting up Suricata
Π we talked about two modes of operation of IDS: through the NFQUEUE queue (NFQ mode) and through zero copy (AF_PACKET mode). The second requires two interfaces, but is faster - we will use it. The parameter is set by default in /etc/default/suricata. We also need to edit the vars section in /etc/suricata/suricata.yaml, setting the virtual subnet there as home.
To restart IDS, use the command:
systemctl restart suricataThe solution is ready, now you may need to test it for resistance to malicious actions.
Simulating attacks
There can be several scenarios for the combat use of an external IDS service:
Protection against DDoS attacks (primary purpose)
It is difficult to implement such an option inside the corporate network, since the packets for analysis must get to the system interface that looks at the Internet. Even if the IDS blocks them, spurious traffic can bring down the data link. To avoid this, you need to order a VPS with a sufficiently productive Internet connection that can pass all local network traffic and all external traffic. It is often easier and cheaper to do this than to expand the office channel. As an alternative, it is worth mentioning specialized services for protection against DDoS. The cost of their services is comparable to the cost of a virtual server, and it does not require time-consuming configuration, but there are also disadvantages - the client receives only DDoS protection for his money, while his own IDS can be configured as you like.
Protection against external attacks of other types
Suricata is able to cope with attempts to exploit various vulnerabilities in corporate network services accessible from the Internet (mail server, web server and web applications, etc.). Usually, for this, IDS is installed inside the LAN after the border devices, but taking it outside has the right to exist.
Protection from insiders
Despite the best efforts of the system administrator, computers on the corporate network can be infected with malware. In addition, hooligans sometimes appear in the local area, who try to perform some illegal operations. Suricata can help block such attempts, although to protect the internal network it is better to install it inside the perimeter and use it in tandem with a managed switch that can mirror traffic to one port. An external IDS is also not useless in this case - at least it will be able to catch attempts by malware living on the LAN to contact an external server.
To begin with, we will create another test attacking VPS, and on the local network router we will raise Apache with the default configuration, after which we will forward the 80th port to it from the IDS server. Next, we will simulate a DDoS attack from an attacking host. To do this, download from GitHub, compile and run a small xerxes program 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 her work was as follows:
Suricata cuts off the villain, and the Apache page opens by default, despite our impromptu attack and the rather dead channel of the "office" (actually home) network. For more serious tasks, you should use . It is designed for penetration testing and allows you to simulate a variety of attacks. Installation instructions on the project website. After installation, an update is required:
sudo msfupdateFor testing, run msfconsole.
Unfortunately, the latest versions of the framework lack the ability to automatically crack, so exploits will have to be sorted manually and run using the use command. To begin with, it is worth determining the ports open on the attacked machine, for example, using nmap (in our case, it will be completely replaced by netstat on the attacked host), and then select and use the appropriate .
There are other means to test the resilience of an IDS against attacks, including online services. For the sake of curiosity, you can arrange stress testing using the trial version . To check the reaction to the actions of internal intruders, it is worth installing special tools on one of the machines on the local network. There are a lot of options and from time to time they should be applied not only to the experimental site, but also to working systems, only this is a completely different story.
Source: habr.com