The IP Address had China written on it, but in data security bad actors in Europe, Asia and the USA can and do hijack IP’s to make you think it’s some other rat bastard. Either way we like to knock heads with them occasionally to keep on our toes… then drop em like flies. Here’s a great post to show you how to configure a firewall on your own server.
12Flat is proudly hosted on a secure Wordsrack.com hand crafted NGINX webserver.This is an updated firewall rules guide for hosts or developers with panels on ports such as 8080, 8000, 2082 etc. We work in terminals (ssh), sftp and Ajenti -v so this is a real world case “just in”.
When you have an exposed IP:port with a login widget this is when IPTables are your best friend. You can choose DROP or REJECT and open up an ISP/s range(s) of IP’s for yourself, company, co-workers in various regions. Everyone else hits the wall.
|ASN||AS134764 CT-FOSHAN-IDC CHINANET Guangdong province network, CN (registered Oct 27, 2015)|
In a recently spun up machine we were still setting up rules, we found quickly in the auth.log a semi brute force password/dictionary attack ongoing. We’d prefer to keep our bandwidth to ourselves and clients since we pay the electric bill. In the interest of the changing landscape with NGINX on Ubuntu 16.04.x moving forward with PHP7.0 setting up firewall rules.
Jan 26 22:45:01 NUKEserver2 ajenti: failed login attempt for root (“[email protected]”) through AjentiSyncProvider from 188.8.131.52
Jan 26 22:46:10 NUKEserver2 ajenti: failed login attempt for root (“[email protected]#”) through AjentiSyncProvider from 184.108.40.206
Jan 26 22:47:20 NUKEserver2 ajenti: failed login attempt for root (“[email protected]#$”) through AjentiSyncProvider from 220.127.116.11
Using honeypots and X-Force Exchange a lot of these IP’s will have no comments possibly part of a new series but the rate and number of attempts is not an attempt to take someone down but to penetrate using the dictionary (and those are actually quite lame) vectors- hopefully an example that says to those culpable there is really nothing wrong with a 50 character password. Get LastPass or a good notepad and keep a record for long difficult ones for crying out loud.
Ports on several new machines are being sniffed out quickly after deployment and we found rules that worked on PHP-5 are not on 7.0.
Let’s use 2083 as an example and get dirty.
Every time we deploy a rule it’s a simple set of command line statements on Ubuntu
- nano /etc/iptables.test.rules (where we insert)
- iptables-restore < /etc/iptables.test.rules
- iptables-save > /etc/iptables.up.rules (and deploy/refresh)
Basically we want to allow our computer in, but since our own IP may likely be dynamic we need to find a range from our ISP or network. If you have an ASN you can find the ranges for where you live and work. One service is ASN-Blocklist hosted on enjen.net here
Finding an ASN is easy on whois.domaintools.com – just do a whois on your ISP. If your ISP has a zillion ranges you can call them to see how they assign blocks and pick what will work for you.
If you fall out of your range you can just tunnel in ssh and update the values to reflect your new ip/range.
So whether calling your ISP or using whois and Enjen you come up with a list maybe close to something like this:
Before PHP7.0 we figured this out while experimenting with a single IP with a couple lines that looked like this:
-A INPUT -p tcp –dport 2083 -j DROP
-A INPUT -p tcp –dport 2083 -s 18.104.22.168 -j ACCEPT
Worked fine at the time but we had to fan out to include ranges (for convenience sake). Basically the statement above blocks ALL/ANY who are not on 22.214.171.124. DROP could be REJECT and its a totally different story, best told over here at Stack Exchange Security. I like DROP so the perps just wait (and if they’re not actually looking just hang until they notice their done). REJECT alerts them immediately so they might move on quicker to other prey.
WARNING. The statement above does NOT work on Ubuntu 16.04 / PHP7.0 and is the whole reason for this post. Our IP’s and ports have been changed here for demo purposes. It will work with your own values DO NOT use these.
This is what we ended up with:
-A INPUT -p tcp –dport 2083 -s 126.96.36.199/16 -j ACCEPT
-A INPUT -p tcp –dport 2083 -s 188.8.131.52/16 -j ACCEPT
-A INPUT -p tcp –dport 2083 -s 184.108.40.206/16 -j ACCEPT
-A INPUT -p tcp –dport 2083 -s 220.127.116.11/12 -j ACCEPT
-A INPUT -p tcp –dport 2083 -s 18.104.22.168/23 -j ACCEPT
-A INPUT -p tcp –dport 2083 -j DROP
What continued to NOT work at first was a mystery when using the first convention. Obviously our webserver and os and php didn’t like something about putting the DROP statement first. When we finally put it at the end.. BAM we had joy.
NB: your entire rules file obviously is going to have a lot more in it and look more like the image below and, always, have a secure 2017.