The example is as on CentOS 7. Similar should be achievable on other systems too.<\/em><\/p>\n\n\n\nSetup process<\/h2>\n\n\n\n
First, the needed tools should be installed:<\/p>\n\n\n\n
yum install iptables iptables-services ipset ipset-service<\/pre>\n\n\n\nAll offending IPv4 addresses are going to be saved, open the following file for edit:<\/p>\n\n\n\n
vi \/etc\/sysconfig\/ipset-config<\/pre>\n\n\n\nAnd set IPSET_SAVE_ON_STOP=\"yes\"<\/tt>.<\/p>\n\n\n\n
The ipset<\/tt> in this example is created with the timeout<\/em> parameter which makes the set\u2019s entries expire. Without the timeout, the entries will last until removed by hand.<\/p>\n\n\n\nipset create sshin_bans hash:ip timeout 3600\nservice ipset save\nsystemctl start ipset\nsystemctl enable ipset<\/pre>\n\n\n\nInsert desired ruleset into \/etc\/sysconfig\/iptables<\/tt>. Following is a simple example ruleset:<\/p>\n\n\n\n*filter\n:INPUT ACCEPT [0:0]\n:FORWARD ACCEPT [0:0]\n:OUTPUT ACCEPT [0:0]\n:SSHIN - [0:0]\n\n# 1\n-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT\n-A INPUT -i lo -j ACCEPT\n-A INPUT -p tcp -m tcp --dport 22 -s 10.0.0.0\/12 -m conntrack --ctstate NEW -j ACCEPT\n\n# 2\n-A INPUT -m set --match-set sshin_bans src -j DROP\n\n# 3-4\n-A INPUT -p icmp -j ACCEPT\n-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j SSHIN\n\n# 5 Block direct SSH bruteforce\n-A SSHIN -m recent --set --name bruteforce\n-A SSHIN -m recent --update --seconds 3600 --hitcount 5 --name bruteforce -j LOG --log-level info --log-prefix \"SSH blocked: \"\n-A SSHIN -m recent --update --seconds 3600 --hitcount 5 --name bruteforce -j SET --add-set sshin_bans src\n-A SSHIN -m recent --update --seconds 3600 --hitcount 5 --name bruteforce -j DROP\n-A SSHIN -j ACCEPT\n\n# 6 if you want to filter ports:\n#-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT\n#-A INPUT -j REJECT --reject-with icmp-host-prohibited\n#-A FORWARD -j REJECT --reject-with icmp-host-prohibited\n\nCOMMIT<\/pre>\n\n\n\nExplanation of the above ruleset:<\/p>\n\n\n\n
\n- Established, localhost and new SSH connections from your private network are allowed right away.<\/li>\n\n\n\n
- The sshin_bans<\/tt> address list (set<\/tt>) is checked. If the source address is found from the set the connection is immediately dropped (i.e. no connections at all, to any port, are allowed from that specific address).<\/li>\n\n\n\n
- ICMP is allowed.<\/li>\n\n\n\n
- New SSH (port 22) connections are directed to SSHIN chain for further evaluation.<\/li>\n\n\n\n
- SSH connection counting and processing magic:\n
\n- an iptables recent<\/tt> table named bruteforce<\/tt> is checked\/updated for the packet source address.<\/li>\n\n\n\n
- The\u00a0recent<\/tt>\u00a0table is inspected:\n
\n- if during 3600 seconds (1 hour) there are 5 or more hits to the rule, then log, add the address to sshin_bans<\/tt>ipset, and drop the new connection;<\/li>\n\n\n\n
- otherwise, accept the connection.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Optional filter rules.<\/li>\n<\/ol>\n\n\n\n
Then enabling the ruleset:<\/p>\n\n\n\n
systemctl start iptables\niptables-restore \/etc\/sysconfig\/iptables\nservice iptables save\nsystemctl enable iptables<\/pre>\n\n\n\nIn this setup, the ban list is persistent as the set is saved upon shutdown but the bans expire after 1 hour. Blocked addresses can be delisted manually by using the following command:<\/p>\n\n\n\n
ipset del sshin_bans 172.16.6.10<\/span><\/pre>\n\n\n\nThis removes an address from the set and allows that host to connect again, provided it does not trigger a new ban from iptables<\/tt>\u2018s recent<\/tt> match.<\/p>\n\n\n\nHoneypotting<\/h2>\n\n\n\n
With ipset<\/tt> and the SET target<\/tt> it\u2019s easy to catch also those hosts which try to connect to a port with no daemon listening on it. If there supposedly was nothing listening on port 25, just by having a rule such as -A INPUT -p tcp --dport 25 -j SET --add-set honeypot_victims src<\/tt> adds the remote host to the honeypot_victims<\/tt> set when the offending host matches the chain \u2013 i.e. the remote host tried to connect to port 25.<\/p>\n\n\n\n
To enable this honeypot, add the rule to your \/etc\/sysconfig\/iptables<\/tt> file.<\/p>\n\n\n\n-A INPUT -p tcp --dport 25 -j SET --add-set honeypot_victims src<\/pre>\n\n\n\nThen create the honeypot_victims jail using ipset, save the config and restart the software.<\/p>\n\n\n\n
ipset create honeypot_victims hash:ip timeout 3600\nservice ipset save\nsystemctl restart ipset\nsystemctl restart iptables<\/pre>\n\n\n\nIt should be clear anyway that one got to know what they are doing when using this kind of setup. There might be innocent errors that make clients connect to the wrong host or port and denying access on the basis of so primitive heuristic might open up the chance for denial of service.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
The access control method shown in this article is lighter and more streamlined because it does not need a separate log watcher daemon (e.g. fail2ban). Another good thing is that Netfilter is usually readily available and in use anyway, so accommodating a few more rules to the ruleset does not require much extra effort.<\/p>\n\n\n\n
This is not, however, a universal solution. The real downside is that Netfilter counts only incoming connections, not failed logins, and therefore it could be easier to accidentally lock oneself out or accidentally cause a small denial of service.<\/p>\n\n\n\n
Still, the principal solution for denying access to abusive hosts as described in this article has been tried and tested by the author for a considerable length of time. Even on a small-scale multiuser system, there has only been a tiny amount of bans for legitimate users over several years (one or two cases) but obviously, this is not a large-scale multiuser solution.<\/p>\n\n\n\n
If the presented example solution wasn\u2019t suitable, a better and more intelligent solution might be sshguard<\/em><\/a> which has the ability to catch offenders during a longer timespan. sshguard can feed IP addresses into an ipset<\/tt> set too.<\/p>\n","protected":false},"featured_media":27437,"comment_status":"open","ping_status":"closed","template":"","community-category":[111,121],"class_list":["post-24710","tutorial","type-tutorial","status-publish","has-post-thumbnail","hentry","community-category-networking","community-category-security"],"acf":[],"_links":{"self":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial\/24710","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial"}],"about":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/types\/tutorial"}],"replies":[{"embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/comments?post=24710"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/media\/27437"}],"wp:attachment":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/media?parent=24710"}],"wp:term":[{"taxonomy":"community-category","embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/community-category?post=24710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}