Will using iptables secure Ubuntu?

[aboka]

@TheFu - for the localhost, i will just use what @SeijiSensei suggest as i find out localhost is the same as loopback.

Can you pls explain this - 'Open ports as seen on the server are always different than open ports seen from outside' like how do we check if the port are exposed to the world?

read an article yerterday saying that dnsmasq is actually DNS+DHCP so that might be the reason why it has an open port? hv also read about dhcpd. do you think dnsmasq will create a security risk since it has an open port and we should replace it with dhcpd?

thank you,

[TheFu]

The only way to see what the outside world sees is to run a port scan using an external address, not on the system. Use nmap for that.

On the same machine, we can ask netstat.

# Open ports with listeners, not localhost
$ ss -lnt|egrep -v 127
$ netstat -tunl|grep LISTEN|grep -v 127
$ sudo netstat -tulpn |grep LISTEN|grep -v 127

Note which need and don't need sudo.

[aboka]

The only way to see what the outside world sees is to run a port scan using an external address, not on the system. Use nmap for that.

On the same machine, we can ask netstat.

# Open ports with listeners, not localhost
$ ss -lnt|egrep -v 127
$ netstat -tunl|grep LISTEN|grep -v 127
$ sudo netstat -tulpn |grep LISTEN|grep -v 127

Note which need and don't need sudo.

hi, thanks for the prompt reply could we do it on Windows or use web service like canyouseeme.org?

i just check on my Windows(while connected to the server using Softether vpn) and goto canyouseeme.org and it say 'Success: I can see your service on' on all the port here - 22, 53, 443, 1194, 5555

here is the result running the netstat command-
LISTEN 0 128 0.0.0.0:1194 0.0.0.0:*
LISTEN 0 128 0.0.0.0:5555 0.0.0.0:*
LISTEN 0 32 0.0.0.0:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 0.0.0.0:443 0.0.0.0:*

so do you think we need to replace the dnsmasq with dhcpd? or we could just block the port and not expose the port to the world. thank you.

[aboka]

Please take a look and see if this is ok, and if there is anything left out.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # for the current session
sudo iptables -A INPUT -i lo -j ACCEPT # for loopback/localhost
sudo iptables -A INPUT -p icmp -j ACCEPT # for ping response
sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT # for ssh connection
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT # for vpn
sudo iptables -A INPUT -p all --dport 1194 -j ACCEPT # for vpn and 'all' bcoz it could use both protocol
sudo iptables -A INPUT -p tcp --dport 5555 -j ACCEPT # vpn
sudo iptables -A INPUT -j DROP # drop everything not in the list above

thank you,

[TheFu]

Do you really want to try and manually setup all the stuff yourself? There are a number of firewall script tools. CNF is one that is well-regarded and used by professionals: https://www.digitalocean.com/communi...-csf-on-ubuntu Those instructions are from 2013, but iptables hasn't changed THAT much since then. Looking through all the things CNF handles will give you some ideas for things missing.

UFW silently handles many things too, while being uncomplicated.

But if you want to have your own wheel, great!

[aboka]

Do you really want to try and manually setup all the stuff yourself? There are a number of firewall script tools. CNF is one that is well-regarded and used by professionals: https://www.digitalocean.com/communi...-csf-on-ubuntu Those instructions are from 2013, but iptables hasn't changed THAT much since then. Looking through all the things CNF handles will give you some ideas for things missing.

UFW silently handles many things too, while being uncomplicated.

But if you want to have your own wheel, great!

hi, thanks for the suggestion and it really sounds great with so many protections. but think will just stick with iptables for now as it is the 'default'. perhaps will 'upgrade' to it after all is done.

cheers,

[TheFu]

hi, thanks for the suggestion and it really sounds great with so many protections. but think will just stick with iptables for now as it is the 'default'. perhaps will 'upgrade' to it after all is done.

cheers,

Sorry. Perhaps i wasn't clear. iptables is still used. CNF is just a script to create the iptables rules. CNF handles all the things you and i don't remember or don't know are necessary for a more secure firewall. it puts them in the correct order and addresses abusive connections.

it is very common for a script to make a script in the Unix world. i write scripts that make scripts a few times every week.

But there's nothing wrong with learning the ugly parts yourself either. That helps to get the lower level knowledge so later you can concentrate on getting the solution solved, better, faster, easier.

Also, UFW sets up iptables rules too. UFW is the ubuntu standard tool, but there are times when dropping down to iptables is necessary. Ufw is just a little too lite sometimes. CNF isn't, though both allow adding direct iptables rules when needed.

[aboka]

@TheFu thanks for explaining that. Will try out the iptables and then decide if wanna try ConfigServer. It is great looking at all the things it could do, but it is just little overwhelming, especially now. Could you let me know if the rules below are ok? Thank you very much

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # for the current session
sudo iptables -A INPUT -i lo -j ACCEPT # for loopback/localhost
sudo iptables -A INPUT -p icmp -j ACCEPT # for ping response
sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT # for ssh connection
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT # for vpn
sudo iptables -A INPUT -p all --dport 1194 -j ACCEPT # for vpn and 'all' bcoz it could use both protocol
sudo iptables -A INPUT -p tcp --dport 5555 -j ACCEPT # vpn
sudo iptables -A INPUT -j DROP # drop everything not in the list above

anything left out? and do we need FORWARD or OUTPUT rules?

[aboka]

hi guys, i hv create another vps and hv applied the rules. here are the 'output' -

root@NY-UBUNTU-01:~# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT

does it look ok?

thanks,

[The Cog]

Looks OK to me. But the "-A INPUT -j DROP" is redundant because your policy for undecided packets is to drop them anyway. It doesn't do any harm though, except that it makes it harder to add another ACCEPT clause on the fly.