Using CrowdSec to Block Unwanted Outbound Behavior

Let me tell you a story of how I ended up testing a theory of running CrowdSec on outbound connections to block unwanted behavior and accidentally succeeding! 

​I am volunteering as a SysAdmin at a ladies-only student home. I have known the owner since the 90s, and I have been responsible for all their IT needs since then, even after I moved across the country.

Back then, it all started out as every small project — a router provided by the Internet Service Provider (ISP) and behind it, a server machine having two Network Interface Cards (NIC) doing Network Address Translation (NAT) as we only had a limited number of IPs. Connectivity was done by wire and, at some point, we introduced WiFi, of course!

As IT isn't their core business, it's cut down to the minimum needs — but a firewall was still a must even back in those days. The firewall’s core functionality was to do some traffic shaping to ensure at least some fairness among the students. Kind reminder: Bittorrent was big back then and we had to ask the big question.

How to control peer-to-peer (P2P) sharing?

​​That is a huge task ahead and it was kinda obvious that the sheer number of services was more than a problem. So, we had to go with a rather stealthy approach. I did this by shaping the used P2P downloaders’ traffic and limiting it to a very bad connection. 

The psychology behind it is simple: If I block the application, they will search for alternatives and this will get out of hand sooner than later. By making it just unattractive, most students just stopped using it and we had the problem under control — at least for a short while.

As a matter of fact, most of the students were coming from art, music, and many IT-unrelated fields, so this trick did work better than we hoped for — except for the fact that we now had to deal with huge downloads left running while they were gone. Honestly, I don't blame them for that. But bandwidth hogs were still problematic for the whole network, especially with download managers coming into play, opening a ton of connections, and making traffic shaping a much more complicated game that I wasn't willing to play due to the limited time I could dedicate to the project.

Limiting time and traffic using a captive portal

So, to deal with all those cases, we opted for a captive portal limiting time and traffic. After some hours and/or traffic generated, they had to log in again. That way the system acted like a dead man's handle, ensuring their presence on using the network according to fair use while really simplifying and reducing traffic shaping rules. 

DNS blocking

Time passed and things were running smoothly until something big took the internet by storm. A disease spreading all over the web. Haunting the network, eating bandwidth like crazy. You guessed it: video ads.

As our network was busy due to the number of students and bandwidth in that area still being suboptimal, meaningful remote work was nearly impossible and anything bigger than just SSH was close to impossible. So, as a last-ditch effort, we added piHole to see if it would improve the situation. And oh boy it did. 

Things like typing commands into an SSH client suddenly worked like a charm. Even remote desktop management was suddenly possible and the students really loved it (we sent out a note on changing DNS servers to opt out of the ad blocking — to my surprise nobody did).

​CrowdSec and a happy little accident

​All was dandy until Integrated Services Digital Network (ISDN) started to die — literally. Telecom started migrating everyone to Session Initiation Protocol (SIP) and that's the end of the story…or is it?

SIP is one of the protocols being pretty much hammered every day and despite having just installed the server and limited its connections to be just the trunk to the provider, I was curious about how many people would try funny things.

​So, it was time to bring in the big guns — CrowdSec! I loaded my blocklist mirror onto the firewall, and I wasn't disappointed. But at this point, CrowdSec was only set up mostly as a monitor for me to see blocks. 

But what if?

Crowdsec does make sense on incoming connections, but what about putting it to work on outgoing connections? I have to say, the question was asked in Discord a couple of times, and I just had to put it to the test.

I didn't really think that I would block anything with those rules — boy was I wrong. A couple of blocks popped up and reports on my desk about sites like “amazon” or some weird bank not working. Upon investigating, it turned out that the sites the users believed to be legitimate Amazon websites were actually phishing sites. I stood there and looked at the data, asking "WHY??" multiple times while checking the CTI.

​Summing up

​Let's get one thing straight first. For an IP to be blocked by Crowdsec it needs to actively hit CrowdSec Security Engines or honeypots. But passively sitting on scam sites?

​Judging from how unskilled most scammers are, I wouldn't exclude the possibility of their server joining a botnet or being compromised landing them on our lists, as I suspect they wouldn't make the mistake of actively trying to compromise new targets on their sites. 

So, is it worth it to run CrowdSec on outbound connections?

​I wouldn’t advise relying on it as your only outbound protection. But I have to admit, keeping it active doesn't hurt you either as it might catch some packets. I mean, why would you want to communicate with compromised systems anyway?

What’s your take on this? Feel free to hit me up on the Crowdsec Discord (@ToeiRei) server and share your feedback.