A VB NAT connection its just like a simple router. All outgoing traffic but no new connections on the input side.
iptables are flushed but if policy is dropped nothing is going work.

Alright. So, it works now!

Turns out all I needed to do was add "NEW" to my OUTPUT UDP DNS port.

Then I started stripping things off. I found that I, surprisingly, could remove all DNS port access on my INPUT. No problem.

Also, no need to have this on OUTPUT, apparently:
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Anyone see anything else worth stripping?

Again, what I'm trying to achieve is to have access to web traffic through OUTPUT, with only ESTABLISHED connections coming in through INPUT.

Current settings from iptables-save are attached.

/ BLR

Attached Thumbnails

 

On the INPUT chain, you might need RELATED in addition to ESTABLISHED.

On the OUTPUT chain, you will probably need NTP to keep the time in sync.

NTP is not required for this assignment, but I will modify this for my personal use afterwards and take it into account. Thanks!

Why RELATED? If it aint broke...

It is broken.

One example would be that RELATED is needed for receiving an ICMP error in response to an attempted outgoing message.

If you are going to adapt the filter rules for your own use later, then I'll say yet again that you might look at nftables. These would be of use for that:

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

as well as the utility iptables-translate

After you get your grade be sure to get some entertainment out of asking why iptables is still being taught instead of keeping up with current developments.

1 members found this post helpful.

Now I stripped it even more, and still have access to internet. I must have misunderstood something here, clearly, because to me this should drop all incoming packets and make me loose my connection.

Attached Thumbnails

 

It's getting more and more broken.

Try clearing the counters

and then add a line to log outgoing packets right before the get dropped and watch the logs.

ESTABLISHED The packet is associated with a connection which has seen packets in both directions.

Since you are allowing a new,established for the output, traffic is now established so
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

becomes a generic rule for all incomming traffic that is already established or originated from that computer. As an example you can ssh to another computer but can not ssh from another computer to this one. A "generic" established rule allows any input from other services like NTP, network printing or updates.

Where as
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Only allows traffic established on a specific port i.e ssh.

A I understand how iptables works...

Just to help clarify:
During the TCP handshake, you send a connection request to an outside server; that is NEW.
The server sends back a ACK+SYN; that is RELATED.
You send a ACK back to the server that you are SYNc'd; you are now ESTABLISHED.

From the other direction:
BadActor tries to connect to your server; that is NEW..... -j DROP

You don't want NEW -j ACCEPT on the INPUT chain unless it also references a specific port/service that you are knowingly making available.

1 members found this post helpful.

Hello everybody.

I wanted to share with you, for posterity's sake, the solution I used.

Again, the goal being to ALLOW only ESTABLISHED connections on the INPUT, on ports required to connect to webpages on the internet. Only via OUTPUT should NEW connections be possible.

It seems I misunderstood some concepts along the way, hopefully the rules are a little bit clearer now.

If you think there's something that I should add / strip away, please feel free to come with suggestions.

/ BLR

Attached Thumbnails

 

I think this was mentioned above, but it probably got lost with the flood of information but your INPUT lines should be checking the connection tracking state (ctstate) of the SOURCE port not the DESTINATION.
--dport should be --sport on all INPUT lines.

To show this, you can make an SSH connection to some computer. Then, in another window, run:
When I run this I get
This shows that my local host is using port 41232 and is connected to the ssh port (22) on the server. Your INPUT lines won't work because they are expecting both computers to be using port 22 (ssh) and the local host won't.

A very good reference for iptables firewalls is: "Designing and Implementing Linux Firewalls with QoS using netfilter, iproute2, NAT and L7-filter". It has very good real-world examples and explains everything quite well.

1 members found this post helpful.