Issues when configuring with iptables

B.L.R · 06-03-2021, 09:08 AM

Hello!

I'm currently taking an introductory course on Linux and networking, with no prior practical experience, so please feel free to assume that my knowledge is quite limited.

I'm currently setting up the rules for a ipv4 network firewall with iptables and need help with going through some basic commands to secure my server.

My goal is to make only web related traffic possible on my OUTPUT-chain. On my INPUT-chain, I want to only connect to previously established connections. No other traffic should pass through what so ever.

This is what my current settings are:
INPUT DROP
FORWARD DROP
OUTPUT DROP

ALLOWED INPUT:
Only previously ESTABLISHED web traffic connections.
tcp + udp connections through ports 22 (SSH), 80 (HTTP), 443 (HTTPS), 53 (DNS).

Eg command line (for SSH):
sudo iptables -A INPUT -p tcp --dport 22 --state ESTABLISHED -j ACCEPT

ALLOWED FORWARD:
NONE

Allowed OUTPUT:
Only tcp + udp connections through ports 22 (SSH), 80 (HTTP), 443 (HTTPS), 53 (DNS).

Eg: sudo iptables -A OUTPUT -p tcp --sport 22 --state -j ACCEPT.

For some reason, this current setting isn't allowing me to connect to a specific url. Do I have to specify source/destination adress, or interface, or is it something completely different that I have missed?

All help is very kindly appreciated.

Regards,
B.L.R

smallpond · 06-03-2021, 01:30 PM

You want dport rather than sport in OUTPUT. Source port can be any value on the client when making web or ssh connections to port 80 or 22 on the server. Just remove the dport from INPUT since it will already know the port for established connections.

Turbocapitalist · 06-03-2021, 01:40 PM

There are probably additional outgoing services which you need to allow, such as NTP for sure and maybe IMAPS and SMTP if it is normal desktop or laptop.

Incoming ICMP is another of the things which must be allowed, too, so that your networking is not broken.

I see IPv4 in your example. What role will IPv6 have in this?

Also, if you are new to packet filtering you might take a step back and remove iptables and give nftables a go isntead. All the current development is happening on nftables. iptables is more or less deprecated and will go away much sooner than later, so you will have to invest in learning nftables anyway, so why not now?

https://wiki.nftables.org/wiki-nftab..._in_10_minutes

B.L.R · 06-03-2021, 02:24 PM

Quote:

Originally Posted by smallpond

You want dport rather than sport in OUTPUT. Source port can be any value on the client when making web or ssh connections to port 80 or 22 on the server. Just remove the dport from INPUT since it will already know the port for established connections.

Thanks for the reply!

So...

INPUT:
sudo iptables -A INPUT -p tcp --state ESTABLISHED -j ACCEPT

OUTPUT:
sudo iptables -A OUTPUT -p tcp --dport 22 --state -j ACCEPT

Like this?

B.L.R · 06-03-2021, 02:34 PM

Quote:

Originally Posted by Turbocapitalist

There are probably additional outgoing services which you need to allow, such as NTP for sure and maybe IMAPS and SMTP if it is normal desktop or laptop.

Incoming ICMP is another of the things which must be allowed, too, so that your networking is not broken.

I see IPv4 in your example. What role will IPv6 have in this?

Also, if you are new to packet filtering you might take a step back and remove iptables and give nftables a go isntead. All the current development is happening on nftables. iptables is more or less deprecated and will go away much sooner than later, so you will have to invest in learning nftables anyway, so why not now?

https://wiki.nftables.org/wiki-nftab..._in_10_minutes

Thanks!

How will I know which ports are necessary? When using netstat or nmap on my laptop without the firewall active, the only other ports I can identify is localhost:smtp (protocol: tcp, port: 25). Added a pic.

Regarding ipv6, I think iptables can only do ipv4. I wanted to challange myself to learn iptables for future reference!

Regards,
BLR

Turbocapitalist · 06-04-2021, 12:23 AM

The word "future" and iptables don't go together. It is a deprecated technology. The future of packet filtering in GNU/Linux is nftables, at least for the forseeable future.

Which distro is this for, including version? Is it going to be on a desktop or other client system and not a server?

As you see in your screenshot, you'll have to allow the loopback device to talk with itself. As for IPv6, just make a second set of rule using ip6tables and keep those updated in parallel to the iptables rules.

However, if you are just starting out, your time would be better invested in nftables unless you are into retro computing. Here's something to get started with nftables (untested, probably flawed)

Code:

#!/usr/sbin/nft -f

table ip filter4 {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" ip saddr 127.0.0.0/8 ip daddr 127.0.0.0/8 counter accept
                ct state established,related counter accept
                icmp type echo-request limit rate 1/second counter accept
                tcp dport 22 ct state new limit rate 4/minute counter accept
                counter reject
        }

        chain output {
                type filter hook output priority filter; policy drop;
                oifname "lo" ip saddr 127.0.0.0/8 ip daddr 127.0.0.0/8 counter accept

                udp dport  53 ct state new,established counter accept
                tcp dport  53 ct state new,established counter accept
                tcp dport  22 ct state new,established counter accept
                tcp dport  25 ct state new,established counter accept
                tcp dport 465 ct state new,established counter accept
                udp dport 123 ct state new,established counter accept
                tcp dport { 80,443 } ct state new,established counter accept

                ip protocol icmp counter accept
                counter reject
        }    
}

table ip6 filter6 {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" ip6 saddr ::1 ip6 daddr ::1 counter accept
                ct state established,related counter accept
                icmpv6 type echo-request limit rate 1/second counter accept
                tcp dport 22 ct state new limit rate 4/minute counter accept
                counter reject
        }

        chain output {
                type filter hook output priority filter; policy drop;
                oifname "lo" ip6 saddr ::1 ip6 daddr ::1 counter accept

                udp dport  53 ct state new,established counter accept
                tcp dport  53 ct state new,established counter accept
                tcp dport  22 ct state new,established counter accept
                tcp dport  25 ct state new,established counter accept
                tcp dport 465 ct state new,established counter accept
                udp dport 123 ct state new,established counter accept
                tcp dport { 80,443 } ct state new,established counter accept

                ip6 nexthdr ipv6-icmp counter accept
                counter reject
        }
}

That would go in /etc/nftables.conf once the bugs are worked out.

Code:

sudo nft flush ruleset
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

See the nftables wiki for more options and details.

B.L.R · 06-04-2021, 06:04 AM

Quote:

Originally Posted by Turbocapitalist

The word "future" and iptables don't go together. It is a deprecated technology. The future of packet filtering in GNU/Linux is nftables, at least for the forseeable future.

Which distro is this for, including version? Is it going to be on a desktop or other client system and not a server?

As you see in your screenshot, you'll have to allow the loopback device to talk with itself. As for IPv6, just make a second set of rule using ip6tables and keep those updated in parallel to the iptables rules.

However, if you are just starting out, your time would be better invested in nftables unless you are into retro computing. Here's something to get started with nftables (untested, probably flawed)

Code:

#!/usr/sbin/nft -f

table ip filter4 {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" ip saddr 127.0.0.0/8 ip daddr 127.0.0.0/8 counter accept
                ct state established,related counter accept
                icmp type echo-request limit rate 1/second counter accept
                tcp dport 22 ct state new limit rate 4/minute counter accept
                counter reject
        }

        chain output {
                type filter hook output priority filter; policy drop;
                oifname "lo" ip saddr 127.0.0.0/8 ip daddr 127.0.0.0/8 counter accept

                udp dport  53 ct state new,established counter accept
                tcp dport  53 ct state new,established counter accept
                tcp dport  22 ct state new,established counter accept
                tcp dport  25 ct state new,established counter accept
                tcp dport 465 ct state new,established counter accept
                udp dport 123 ct state new,established counter accept
                tcp dport { 80,443 } ct state new,established counter accept

                ip protocol icmp counter accept
                counter reject
        }    
}

table ip6 filter6 {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" ip6 saddr ::1 ip6 daddr ::1 counter accept
                ct state established,related counter accept
                icmpv6 type echo-request limit rate 1/second counter accept
                tcp dport 22 ct state new limit rate 4/minute counter accept
                counter reject
        }

        chain output {
                type filter hook output priority filter; policy drop;
                oifname "lo" ip6 saddr ::1 ip6 daddr ::1 counter accept

                udp dport  53 ct state new,established counter accept
                tcp dport  53 ct state new,established counter accept
                tcp dport  22 ct state new,established counter accept
                tcp dport  25 ct state new,established counter accept
                tcp dport 465 ct state new,established counter accept
                udp dport 123 ct state new,established counter accept
                tcp dport { 80,443 } ct state new,established counter accept

                ip6 nexthdr ipv6-icmp counter accept
                counter reject
        }
}

That would go in /etc/nftables.conf once the bugs are worked out.

Code:

sudo nft flush ruleset
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

See the nftables wiki for more options and details.

Thanks! I'll look into it!

In the meantime - any suggestions how I can configure with iptables instead?

/ BLR

Turbocapitalist · 06-04-2021, 06:10 AM

Yes, the same advice regarding the loopback, DNS, NTP, and ICMP for iptables as for nftables.

Again which distro is this for?

B.L.R · 06-04-2021, 06:19 AM

Quote:

Originally Posted by Turbocapitalist

Yes, the same advice regarding the loopback, DNS, NTP, and ICMP for iptables as for nftables.

Again which distro is this for?

Sorry - Debian GNU/LINUX 10.

Any suggestions as to which commands I should specifically use to configure iptables?

/ BLR

Turbocapitalist · 06-04-2021, 06:28 AM

One way is to make a shell script containing the legacy iptables commands. Here is a beginning:

Code:

#!/bin/sh

PATH=/usr/bin:/usr/sbin:/bin:/sbin;

iptables --policy INPUT   DROP;
iptables --policy OUTPUT  DROP;
iptables --policy FORWARD DROP;

iptables -Z; # zero counters
iptables -F; # flush (delete) rules
iptables -X; # delete all extra chains

# input
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request \
        -m limit --limit 1/s -j ACCEPT

# output
iptables -A OUTPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -o lo -j ACCEPT
# fill in the dots ... 
iptables -A OUTPUT ... -j ACCEPT
iptables -A OUTPUT ... -j ACCEPT
iptables -A OUTPUT ... -j ACCEPT
iptables -A OUTPUT ... -j ACCEPT
iptables -A OUTPUT -j REJECT

Note that the last rule appended to the OUTPUT chain is REJECT. That is so your own connections get either let through or else blocked in a timely manner. If you don't do that, then default is reject, and your application will have to time out first before you notice that it is blocked.

Again, a the risk of nagging, iptables is deprecated and you should be looking towards nftables for both your current and future needs.

B.L.R · 06-09-2021, 03:01 AM

Hey guys. Still got no access to internet...!

I used the following commands:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED, RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

iptables -A input -p icmp --icmp type echo-request

#then adds#
#OUTPUT#
iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW, ESTABLISHED
#etc#

#INPUT#
iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED
#etc#.

Thoughts?
You can find my current rules attached.

michaelk · 06-09-2021, 06:34 AM

What you posted and the screenshot are not the same.
Lets start with a more basic set of rules.

Code:

#!/bin/sh
iptables --policy INPUT   ACCEPT
iptables --policy OUTPUT  ACCEPT
iptables --policy FORWARD DROP

iptables -Z; # zero counters
iptables -F; # flush (delete) rules
iptables -X; # delete all extra chains

#input
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -j DROP

It allows all outgoing traffic but only allows connection from outside using ssh.
Basically iptables works by examining each rule in order and what ever is left at the end is dropped. Similar to drop policy except you add a drop rule at the end.

B.L.R · 06-09-2021, 06:58 AM

Quote:

Originally Posted by michaelk

What you posted and the screenshot are not the same.
Lets start with a more basic set of rules.

Code:

#!/bin/sh
iptables --policy INPUT   ACCEPT
iptables --policy OUTPUT  ACCEPT
iptables --policy FORWARD DROP

iptables -Z; # zero counters
iptables -F; # flush (delete) rules
iptables -X; # delete all extra chains

#input
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -j DROP

It allows all outgoing traffic but only allows connection from outside using ssh.
Basically iptables works by examining each rule in order and what ever is left at the end is dropped. Similar to drop policy except you add a drop rule at the end.

Thanks!

Not sure what you are referring to in the screenshot being different, but if it's the top rule in INPUT and OUTPUT (Allowing all anywhere, anywhere) that's how it's presented after adding the loopback.

I'm starting to think that maybe the problem is in my undefined "source" and "destination" address. s it possible that the problem I'm having is related to Debian going through VirtualBox via NAT (bridged)?

I spotted that I need to add UDP going through DNS. However, I'm still not connecting properly.

Turbocapitalist · 06-09-2021, 07:04 AM

If digging into ipatbles (instead of nftables), then the output from iptables-save is much more precise and easy to read. It can be attached as a text file rather than a screen shot. That would help here a lot.

You might append a rule which logs outgoing packets right at the end of the chain before the packet gets rejected. (Drop is for incoming Reject is better for outgoing.) That way you can then get at least some information from the logs abour what is not getting through and that may give you a strong clue about what needs to be opened up.

B.L.R · 06-09-2021, 07:27 AM

Quote:

Originally Posted by Turbocapitalist

If digging into ipatbles (instead of nftables), then the output from iptables-save is much more precise and easy to read. It can be attached as a text file rather than a screen shot. That would help here a lot.

You might append a rule which logs outgoing packets right at the end of the chain before the packet gets rejected. (Drop is for incoming Reject is better for outgoing.) That way you can then get at least some information from the logs abour what is not getting through and that may give you a strong clue about what needs to be opened up.

Sorry Turbocapitalist for persisting with iptables, but I need to learn how to use this program for my studies. It's also stated in the brief that I need to use policy Drop for all connections.

I'll send you a screenshot of the text input from iptables-save.
UFW is of course disabled.