Score:0

iptables block everything but http/https/ssh

pk flag

I have this iptables configuration on my vps which is supposed to run Wordpress. What I want to do is block every incoming request except http on port 80, https on port 443 and ssh on port 22.

Chain INPUT (policy ACCEPT)
    num  target     prot opt source               destination         
    1    f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh
    
    Chain FORWARD (policy ACCEPT)
    num  target     prot opt source               destination         
    
    Chain OUTPUT (policy ACCEPT)
    num  target     prot opt source               destination         
    
    Chain f2b-sshd (1 references)
    num  target     prot opt source               destination         
    1    REJECT     all  --  [retracted_ip]       anywhere             reject-with icmp-port-unreachable
    2    REJECT     all  --  [retracted].com     anywhere             reject-with icmp-port-unreachable
    3    RETURN     all  --  anywhere             anywhere            

I have found some commands online, but what I'm not sure about is if they might conflict with fail2ban.

Score:0
uy flag

First let's backup :)

sudo iptables-save > ./mybackup

If you lost connect and want KVM you can easy back to your start of backup

sudo iptables-restore < ./mybackup

Then you can start adding rules

sudo iptables -A INPUT -d YOURIPPUBLIC -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -d YOURIPPUBLIC  -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -d YOURIPPUBLIC  -p tcp -m tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -d YOURIPPUBLIC  -p tcp -m tcp --dport 22 -j DROP
sudo iptables -A INPUT -d YOURIPPUBLIC  -j DROP

this above if you want make firewall for ip another than your instance, YOURIPPUBLIC : 33.33.33.33 or with netmask 33.33.33.33/32

RELATED,ESTABLISHED - If got before connect just skip all firewall next rules, To get connect this follow next rules :)

if you want whole network

sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -j DROP
sudo iptables -A INPUT -j DROP

You can save for later to edit:

iptables-save > /.mynew.iptables.list.txt
Score:0
ar flag
bob

In general:

Firewall rules get processed in the order they are set and appear (in the output of the iptables -L -v -n --line-numbers , iptables -L -v -n -t nat --line-numbers, iptables-save and/or similar commands).

Creating new rules in the wrong chains and/or the wrong order will result in unwanted consequences, breaking functionality, security and/or locking out valid traffic.

Be aware that running low level iptables commands to manage your firewall may not always be the best solution. As far as I know in Ubuntu using the UFW tooling is preferred and will work reliably in concert with fail2ban.


Fail2ban creates one or more custom chains (that handle most of the heavy lifting for blocking specific misbehaving IP-addresses) like the f2b-sshd chain. Normally you let fail2ban manage the entries in those chains.

Additionally fail2ban creates rules to the custom chains it creates in the INPUT chain. Normally those rules must come first in the INPUT chain, before any other rules you create.

In your current firewall config when you use iptables with the -A switch to append new rules to the INPUT chain everything should work.


Running the following commands will append the usual rules to create a firewall that allows ssh, http and https, and which blocks all other incoming traffic.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp  -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp  -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.