Building a Network for Small Businesses Part 3: Attack Scenarios

Welcome back to this thesis series on how to build, test, and secure networks for small businesses using the CrowdSec Security Engine.

In the first two parts, I showed you the hardware requirements and setup, as well as the running configurations. In case you missed those articles, you can find them here:

• Building a Network for Small Businesses Part 1: Hardware
• Building a Network for Small Businesses Part 2: Running Configurations

In this installment of the series, I will walk you through implementing and testing attack scenarios. I’ll also share a couple of closing thoughts on future improvements.

Let’s dig in!

Attack scenarios

A good way to test the firewall’s features was to do basic penetration testing on the lab network. This way, I could verify that every aspect was working correctly. I hand-picked a few simple attacks to perform and analyzed the decisions. 

Uninstalling a specific log parser (crowdsecurity/whitelists) from the CrowdSec Security Engine was required as this would have prevented private IPv4 addresses from being banned. I am using a lab environment where everything is in a private IP network space. Furthermore, I have disabled port knocking to make the attacks more basic and viable. 

SSH brute-force 

SSH is one of the most common protocols used in modern IT infrastructures, it replaced Telnet, another popular but insecure protocol. Thus, it can be a valuable attack vector for malicious actors. One simple way to gain access is by brute-forcing the login credentials. There are many ways to perform such an attack, In this example, I will demonstrate Hydra. 

Using Nmap, I could verify that port 22 (TCP) is indeed open. 

nmap 192.168.1.115 -p 22

‍

After that, I used Hydra to try common passwords for the root user. I used rockyou wordlist, which contains a huge number of common passwords. I could have used a wordlist for the username using the -L flag.

hydra -l root -P /usr/share/wordlists/rockyou.txt 192.168.1.115 ssh

As you can see in the figure above, after just a few attempts, the Security Engine banned the IP. This made the automated attacker basically useless. Trying different credentials by hand also triggers the Security Engine. As a result, the attacker must wait four hours before trying anything else. Hence it makes it impossibly long to brute force. In addition, port knocking closes port 22 by default, so automated Nmap scans would not work in this situation. 

NextCloud user enumeration 

NextCloud is a great alternative for self-hosting a private cloud solution. It can be an easy way to share files and documents with co-workers without having to worry about subscription fees. NextCloud is functionally similar to Dropbox, Office 365, or Google Drive. The limit is only the hard drive space locally. However, this could pose a threat to the local network. 

Setup 

I have configured a basic reverse proxy setup in front of the firewall to make this solution more flexible and secure. It eliminates the issue of opening several ports on the firewall for all the different services.

server { 
 listen 80; 
 location / { 
 proxy_pass http://192.168.100.3; 
set_real_ip_from 192.168.1.0/24; ## Internal ip address of upstream real_ip_header X-Forwarded-For; ## Upstream header that is being  passed 
 }
 

It is a very simple configuration — it listens only on port 80 (HTTP) and forwards the / path to the NextCloud instance. Something I had to configure separately was the Real IP header — by default the cloud instance only receives the reverse proxy’s IP. 

Attack 

I could have performed many different attacks against this NextCloud instance. Yet, I completed only an enumeration attack, which could also be fatal if appropriate company policies and security measures were not in place. It is important to mention that NextCloud has built-in protections, which I purposefully disabled. Furthermore, I have installed the NextCloud collection for the CrowdSec Security Engine, so it can read the logs and perform bans if necessary. 

After trying several different combinations of credentials, the Security Engine bans the IP address for 4 hours. This prevents attackers from enumerating valid users or brute force passwords for specific users. This attack could also be automated using something like Burp Suite, an Application Security Testing Software. 

Running and testing testmynids.org 

3CORESec, the author and creator of the testmynids.org project, writes: “A simple project that aims to centralize testing for detection of malicious events by Network Intrusion Detection Systems (NIDS). The tests in this project are built against rulesets, not software. Therefore, if you're using ET Open, coverage for these tests will work. There are two parts to it: 

• A website is used to hold some tests/files. It will also hold subdomains and DNS records for when testing via DNS is required. 
• A script that runs/simulates interaction with the website or with third-party websites is meant to be executed on the client for which you want to test coverage of your NIDS sensor.” 

You can download and execute testmynids.org in interactive mode using this one-liner:

curl -sSL  https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS -o  /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS

After running the one-liner, it is possible to select and run the included tests.

Running the tests 

To test Suricata, I have installed another Ubuntu VM on the Proxmox server. Using this server, I can run specific tests internally. As I have stated before, I am running Suricata as an IDS. However, I have installed the Suricata collection to the Security Engine, which makes it possible for the agent to read the Suricata logs and even ban infected machines. 

Despite running only the first two tests, we can observe different behaviors. When I ran the first test, the Security Engine did not ban the IP because of the severity of the event. Running the second test immediately triggered the Security Engine. 

I believe this mechanism is effective as not-so-dangerous events will not get the machine’s IP banned, which makes maintenance easier. On the other hand, it does get logged which means accounting is in place. 

Here are the logs generated by Suricata (/var/log/suricata/fast.log):

11/22/2022-19:03:40.792430 [**] [1:2013504:6] ET POLICY GNU/Linux APT User Agent Outbound likely related to package management [**] [Classification:  Not Suspicious Traffic] [Priority: 3] {TCP} 192.168.100.7:33456 ->  45.67.159.244:80 
11/22/2022-19:03:40.792430 [**] [1:2013504:6] ET POLICY GNU/Linux APT User Agent Outbound likely related to package management [**] [Classification:  Not Suspicious Traffic] [Priority: 3] {TCP} 192.168.100.7:33456 ->  45.67.159.244:80 
11/22/2022-19:04:13.282494 [**] [1:2221034:1] SURICATA HTTP Request  unrecognized authorization method [**] [Classification: Generic Protocol  Command Decode] [Priority: 3] {TCP} 192.168.100.3:51654 ->  192.168.100.1:8080 
11/22/2022-19:04:59.759345 [**] [1:2013504:6] ET POLICY GNU/Linux APT User Agent Outbound likely related to package management [**] [Classification:  Not Suspicious Traffic] [Priority: 3] {TCP} 192.168.100.7:40578 ->  45.67.159.244:80 
11/22/2022-19:05:13.275791 [**] [1:2221034:1] SURICATA HTTP Request  unrecognized authorization method [**] [Classification: Generic Protocol  Command Decode] [Priority: 3] {TCP} 192.168.100.3:51654 ->  192.168.100.1:8080 
11/22/2022-19:05:19.648773 [**] [1:2013028:7] ET POLICY curl User-Agent  Outbound [**] [Classification: Attempted Information Leak] [Priority: 2]  {TCP} 192.168.100.7:34124 -> 99.86.240.25:80 
11/22/2022-19:05:19.667282 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check  returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2]  {TCP} 99.86.240.25:80 -> 192.168.100.7:34124 
11/22/2022-19:05:30.599309 [**] [1:2006380:15] ET POLICY Outgoing Basic  Auth Base64 HTTP Password detected unencrypted [**] [Classification:  Potential Corporate Privacy Violation] [Priority: 1] {TCP}  192.168.100.7:38378 -> 99.86.240.52:80 
11/22/2022-19:05:30.599309 [**] [1:2013028:7] ET POLICY curl User-Agent  Outbound [**] [Classification: Attempted Information Leak] [Priority: 2]  {TCP} 192.168.100.7:38378 -> 99.86.240.52:80 
11/22/2022-19:06:13.274612 [**] [1:2221034:1] SURICATA HTTP Request  unrecognized authorization method [**] [Classification: Generic Protocol  Command Decode] [Priority: 3] {TCP} 192.168.100.3:51654 ->  192.168.100.1:8080 
11/22/2022-19:07:13.273303 [**] [1:2221034:1] SURICATA HTTP Request  unrecognized authorization method [**] [Classification: Generic Protocol  Command Decode] [Priority: 3] {TCP} 192.168.100.3:51654 ->  192.168.100.1:8080

Future improvements 

The future of this appliance consists of some hardware improvements alongside some modifications to the software stack. The project’s main purpose was to build and test a very affordable firewall solution to protect SMBs. However, as an organization grows, so do its needs. The project could be easily improved to support growing businesses. 

To support growing businesses, I would modify the following in the software stack: 

• Ease of installation 
• Add TLS for internal communication using CrowdSec
• Add VLAN support 

To improve the appliance further, I would: 

• Reduce power consumption 
• Add IPMI 

Installation is not a straightforward process in my project, it required the complete reconfiguration of a fresh Ubuntu 22.04 install. This could be a huge issue as hardware failure can occur. The solution for this problem is easy: Ansible. Ansible is an open source, command-line IT automation software application written in Python. It can configure systems, deploy software, and orchestrate advanced workflows to support application deployment, system updates, and more.

Currently, the agents are using clear-text-communication in the internal network to communicate to the main agent. In a bigger company or in a company with strict policies, this is a no-go. I could have created all certificates for myself, however, in a real production environment, this should done by a PKI. 

VLANs can be a powerful tool to separate a physical network into smaller logical networks while keeping their physical locations. This could improve network throughput when more devices are connected and help security and manageability. On the other hand, it adds network complexity, which is not beneficial when configuring a small(er) network. 

Current solutions on the market with similar capabilities consume significantly less power due to their less powerful hardware and form-factor. An average mid-tower office PC consumes around 30-40 W every hour, measurably higher than a purpose-built router, whose power consumption tops at around 5-10 W. 

To solve this issue, I could have used more recent hardware to improve efficiency or a smaller form-factor. In addition, I could replace the 4-port expansion card with a single-port card and replace the 3.5’ spinning HDD with an SSD. Lastly, I could undervolt the CPU and disable unwanted BIOS features if performance is not a concern. 

The Intelligent Platform Management Interface comprises computer interface specifications designed for an independent computer subsystem. It offers management and monitoring functions autonomously, separate from the host system's CPU, firmware (BIOS or UEFI), and operating system. In enterprise hardware, this is usually part of the motherboard; however, it is possible to add a PCIe card. Using this expansion card, it would be possible to remotely configure or start/start/reboot the firewall, which could dramatically improve usability and serviceability.

Conclusion

Targeted attacks against smaller businesses with little to no IT knowledge are becoming increasingly frequent, and the absence of affordable but capable firewalls makes this issue more critical. Without these appliances, SMBs are easy targets for attackers and automated tools, which could be fatal in some situations.

My work’s goal was to use an off-the-shelf computer and build a usable firewall using free and open source tools. By reading the logs of these tools, the CrowdSec Security Engine can provide a complete package with the help of the community while contributing.

Thank you for reading and following the journey of my thesis, I hope you learned something along the way! If you are interested in producing a project around CrowdSec, do not hesitate to contact the CrowdSec team at contact@crowdsec.net or join the CrowdSec Discord server.