Port knocking for firewall control, anyone use it?

[kenneth558]

Does anyone here use port knocking for controlling their firewall? I did "apt-get install knockd" and it warns me that zoneminder would get removed if I continued the install. So I'm perplexed. A good port knocking setup would be a fabulous firewall alternative to maintaining a whitelist like I'm doing, wouldn't it be?

CORRECTION - My server took knockd without uninstalling zoneminder. That warning about zoneminder going to be removed was received on my laptop (I got mixed up due to working via ssh windows on my laptop all day long). I can afford to remove zoneminder from my laptop, so my frustrations in that regard are over. But as long as I posted this, I'd like to leave it going because I still am curious AND because I couldn't find any mention of port knocking in anyone else's posts on the forum.

Here's where I am: without firewalling, I could log in to zoneminder from anywhere but I had computers from all over the world hitting on the server heavily (to crack its security, I'm sure). I take offense to the bandwidth stolen from me in that scenario. So I set up a firewall whitelist with ufw. But there are times I want to check out my surveillance system or show it off from an IP location not in my whitelist; obviously, I can't. So my first thought how to unblock that new IP and get it into my whitelist was to set up a "check-my-email-for-whitelist-changes-I-emailed-in" script on the server. The downside to that is it would either take an unsatisfactorily long response time with efficient polling or use high resources if the polling is accelerated for faster response. But what I really want is a port-knocking setup instead because the whitelist addition would be practically instantaneous and at the same time lightweight.

Has anyone here tried port knocking with zoneminder and know of a method that works well? Thank you!

[knight-of-ni]

Ever open up port 22 and then see how long it takes for a bot to come along and start a brute force attack on the root login?
About 1-2 minutes. It's scary how fast that happens..

I've never used knockd. Sounds like it would work fine.

I've found that using Snort and fail2ban is sufficient for my own needs.
Snort is a rule-based intrusion detection system and fail2ban monitors your linux log files via rules that look for specific error messages such as mod_security denials, http 403, etc... whatever you want.

It's pretty effective. Snort will shutdown port scans, and fail2ban will block bots that generate http 404 errors using url's that are obviously fake.

We just added log entries for failed zoneminder logins. Was just a few lines of php. You could create a fail2ban rule that looks for multiple brute force attempts.

[Nerre]

I think using fail2ban is better than setting up port knocking.

Port knocking makes it harder to use the service for intended users, and since ZoneMinder uses a http protocol it opens and closes the port several times during a session. This means you can not use the simple automatic closing but must make sure to close the "door" after each session (or you will leave it open for an intruder).

I also think port knocking gives you a lot of problems if there are several users using the machine (how would anyone ending their session know that another user is logged in and the port should be left open?).

[kenneth558]

Valid points, but can fail2ban blacklist an IP based on only a single probe? From what I saw, it needed the offending IP to establish a pattern of probing before it was helpful. Since my system is for home surveillance (pretty much single user), I can keep the user side under control. I want port knocking so I can blacklist a perp with a single probe from it to my server. Or did I miss something in fail2ban?

[knight-of-ni]

kenneth558,
fail2ban can ban an ip address on any criteria you set, including a single probe. As mentioned in my last post, I've got fail2ban set up to ban the offending ip if it requests specific, invalid urls, which are obviously generated by a bot. I've got it set to ban on just a single probe.

To be more specific, any ip that generates an http 403/404 error on my site with a url that uses the word "admin" in it, will be immediately banned for 1 hour. If that same ip comes back later and trips any rule, I've got a repeat offender rule that will ban that ip for 1 month.

Everything I just mentioned from the number of probes, the ban time, the rule, and the keywords in the rule are 100% configurable by you. There are no restrictions.

Refer to the fail2ban documentation for further details.

For long term maintenance, install logwatch. It will send you nightly email reports that include any Apache related errors. If you see new http requests generating errors on your site, modify your fail2ban rules accordingly.

[Nerre]

Yes, fail2ban parses log files, so it can ban on anything that can be logged.

But banning on a single probe does not seem reasonable, there are hundreds of valid reasons for a machine to accidentally try to connect to your server. Someone might have typed the wrong address. Of course, if they have no valid reason to connect to your server a ban doesn't hurt more than that it fills your ban lists. So performance wise it does make sens to avoid unnecessary bans.

I think logcheck could be a better tool than logwatch (I haven't used logwatch so this is only based on what I have read). Logcheck needs a bit of tuning though to avoid being spammed by log files.

[knight-of-ni]

If you follow the fail2ban documentation and/or read fail2ban forum content, you will see comments that suggest it is not reasonable to ban on a single attempt.

However, I have to disagree with that.
I've found there are cases where it is quite reasonable to ban on a single attempt.

Let's walk through an example.

Checking last night's logwatch report, I see the following:

--------------------- httpd Begin ------------------------

Requests with error response codes
403 Forbidden
/drupal7/cron.php: 24 Time(s)
404 Not Found
/images/img10.jpg: 12 Time(s)
/administrator/index.php: 1 Time(s)
/robots.txt: 1 Time(s)
/sitemap.xml: 1 Time(s)
/wp-login.php: 1 Time(s)

---------------------- httpd End -------------------------

Note that one just does "yum install logwatch" and it just starts working. Use apt-get if you are running debian. No configuration of logwatch is necessary. It just runs.

This reveals a few maintenance issues I have not taken the time to fix (the cron.php, robots, and sitemap urls). We'll ignore those.

Look at the http 404 with the url "/administrator/index.php".

Aside from the name of the url, I know this is a bot because this url frequently shows up in my reports and the offending ip's come from strange places.
Consequently, I've configured my ruleset to block a single attempt that generates an http 404 with the keyword "admin" in it, and I'm pretty sure I don't want anyone on my site that might mistakenly fat finger this url in.

Maybe the keyword "admin" is too generic for your own site. I'd encourage you to use logwatch, logcheck, or any other reporting tool to run daily reports on your web server activity. Over a period of several days, you will begin to see patterns of common url's that generate http error codes. Investigate the offending ip's. If for example the source ip turns out to be a legitimate google bot, then you might not want to create a fail2ban rule for it, but if you keep getting the same hit from a far away place then I'd create a rule for that.

A few other keywords I use in my ruelset are: sql, soapcaller, setup, w00t, and i42.photobucket.
These keywords came from urls that repeatedly showed up in past logwatch reports. Recall that it takes both an http error code and a keyword match to trip the rule.

Some of these might be part of valid urls on your site, but on mine these urls are all unused. If they are used, it won't generate an http error code and consequently won't trip the rule.

Ask yourself, what are the chances that something legitimate is using one of those keywords on my site? I am confident that nothing with good intent is going to generate an http error using the word "w00t" in the url, at least on my site. If you happen to be managing one of Woot's servers then naturally your requirements will be different.

[Nerre]

As long as the "attempts" are trying to access backdoors that my system doesn't have, my personal opinion is that it is better to let them probe than blacklisting. Uses more of their resources, and wasting their resources is the best way to keep them from finding backdoors:)

With botnets they are in any case unlikely to return with the same IP address, so blacklisting the IP won't help.

[knight-of-ni]

Well, I guess so if you are confident you won't ever have any security holes in your system. While I'd like to think that my own site is reasonably secure, I also understand how easy it is to overlook something. fail2ban is one of multiple layers of security to keep my mind at ease.

If I wasn't running fail2ban, the logwatch report would have shown all the other attempts made by that same bot.
Bots don't typically make a single probe and leave... they'll make 6, 8, 10 different kinds of backdoor checks all within a couple seconds ....and then leave. Fail2ban caught the first one and then the system blocked all the rest.

I agree with you in taking pleasure with a passive-agressive approach to bots. Make them exert maximum resources probing your site. That is actually a reason to block them. Instead of quickly receiving a connection refused or http error response from your site, a bot now has to wait for the timeout to expire for each request it makes, because your site is no longer responding to that ip address.

[Nerre]

For Apache I think mod_security is a better way to handle those attacks, if I don't recall wrong it throttles "attacking requests" so they have to wait longer for a response, wasting their resources.

Different tools are good for different tasks.

[kenneth558]

Got port knocking to work, but it (knockd) is not capable of triggering on a single port knock. How disappointing. I may just try fail2ban again.

I have knockd configured to tweak on the iptables using ufw. Looking through the ufw view of the iptables, there are three sections shown by a ufw status. The first is 'deny's - the perps who [twice within a certain time period] hit one of the ports they like to hit. I blacklist them with a ufw insert 1 because that command will fail like I would want it to if their IP is listed in the second section - 'allows' which port knocked correctly before. The entries in the 'allow' section also have to be inserted, which required a bash script because knockd will not do command substitution to produce the line number of the beginning of the 'allow' section. The third section is simply two entries that together deny everything. I know it seems redundant to have both deny sections, but it allows me to document for my own information. I am certainly not ready to consider the setup as being long term stable, but I sure do feel better right now. My first perp stuck in my blacklist like a bug on a sticky trap is from India, assuming they are not spoofing their IP address.

[knight-of-ni]

@nerre, I am using mod_security to handle attacks. If a mod_security event is generated, rather than http 404, then fail2ban will pick that up as well and the result will be the same. No single tool is perfect, however, including mod_security. With fail2ban enabled, the attacker only needs to trigger one mod_security event, and then the rest of the attacks from the same bot will get blocked, thanks to fail2ban.

That's the cool thing about many of the tools available to us. They layer on top of one another, rather than are mutually exclusive from one another. It's no different than physical security. You always want multiple layers.

@kenneth558, it was interesting reading your results for knockd, which caused me to have the same opinion as nerre. It looks like knockd is going to give you trouble.

[kenneth558]

I might have port knocking working as well as I can get it with the standard knockd. It is accumulating a bunch of DENYs like I hoped, but not enough since many of the perps only hit me once so they don't get caught. I'm closer to concluding that knockd and its associated support scripts along with random ufw disables may be too heavy and too limited an approach for what I want to do. I mainly wanted to avoid having to characterize to fail2ban or whatever other blacklist maker that the malicious probings are specific traffic types or patterns that I thought fail2ban was making me do. I'll keep reading what the rest of you are doing.

I appreciate the ideas from you others. I do think these ideas on this topic are very helpful to zoneminder admins, given our specific needs and skills levels.

[kenneth558]

Port knocking turns out not to fulfill my expectations. My ideal fire-walling, and what I think is perfectly attainable, would allow a fixed time window for an iptables-type "NEW" packet's sender, if not already whitelisted or blacklisted, to authenticate in one or more of several ways. If no authentication happens by that IP within that time period, it gets blacklisted persistently. During the time period allowed, any NEW packets from unknown IPs have to port knock correctly to get entered on the whitelist to even have a chance at authenticating. No ports are open to NEW packets not on the whitelist until after they port knock correctly. If authentication does not occur in time, the whitelist entry is removed and blacklist entry continues. The whitelist is persistent. I'm not worried about getting myself or any other good guy accidentally blacklisted.

Simple as that.

Right now my server was being probed at port numbers in the 55xxx region. Four probes with UDP at each port number. How in the world would I have predicted that pattern well enough to get fail2ban to blacklist that IP? I found it by making my last two ufw rules log their DENYed packets, then manually reading that log. I am so close to getting this setup working exactly the way I want that I'll go ahead and make it work with a script that will tail -f and grep --line-buffered and whatever else to the log file of the last two ufw DENYs to blacklist ALL probing IPs.

According to my understanding, fail2ban requires predicting beyond as I've described. IMO no admin overhead should be necessary trying to identify a type of packet or pattern or timing or anything else. Can fail2ban make things that simple? When I tried it out, I was unable to see how it could.