0

I am working on Debian Stable and it is working very well.

I see apf-firewall to simplify iptables. I want my firewall to only allow web browsing (including forms) and block all other network access. How is this possible with apf-firewall?

Or could I do it with FireHol software? It seems to have simple configuration commands:

version 6 interface4 eth0 home server dns accept server ftp accept server samba accept server squid accept server dhcp accept server http accept server ssh accept server icmp accept interface4 ppp+ internet server smtp accept server http accept server ftp accept

Which lines should I keep if I want only web browsing to be permitted?

Edit: Will following 2 rules using nftables be sufficient for my needs?

nft add rule ip filter input tcp dport 80 ct state new,established accept nft add rule ip filter input tcp dport 443 ct state new,established accept
Improve this question
9
  • 1
    I've skimmed trough the linked document (not in detail) and can't see any advantage over nftables, please correct me if I'm wrong. Commented Sep 30, 2024 at 14:45
  • Are you going to allow name resolution, too (resolve "foo.org" to 1.2.3.4)? Are you going to allow for software updates? ssh access so it can be maintained? What are you afraid of? Why won't a standard system work? Commented Sep 30, 2024 at 14:48
  • @waltinator : I believe standard system (Debian Stable) has no iptables. Is that ok for a general student use? I just want to make a safe system for an average school student who uses network only for web browsing. I do not even know technical details like "name resolution" and "ssh" (can you believe it!). Commented Sep 30, 2024 at 17:04
  • @metablaster : I was not aware of nftables. It look much easier than iptables. What would be rule statements in nftables for my needs? Commented Sep 30, 2024 at 17:07
  • 2
    @mso Before you go any further, you need to understand what a firewall is, and how it relaes to the Internet and general networking. May I recommend this rather old, but still informative 3D video: Warriors of the Net - Dawn of the Internet. I know it looks dated but the underlying concepts have not changed in 40 years+ Commented Sep 30, 2024 at 20:45

2 Answers 2

Reset to default
3

For general web browsing, you should not need to accept any incoming connections at all, since everything you'll need are outgoing connections from your system to your DNS resolver server(s) and the various HTTP and HTTPS servers.

Any legitimate incoming packets should then be responses to your outgoing requests only, so any firewall configuration that includes connection tracking can automatically match them up with the outgoing connections they belong to, and automatically accept them.

The two rules you specified:

nft add rule ip filter input tcp dport 80 ct state new,established accept nft add rule ip filter input tcp dport 443 ct state new,established accept

... would allow incoming HTTP and HTTPS connections, so these rules might be applicable in a basic web server.

Likewise, the FireHol configuration you listed is about listing the services running on the firewall host i.e. it assumes FireHol is running on a server system which needs to provide some services to other hosts. On any system that does not provide any services to other systems, you should generally have no server ... accept lines at all.

A connection tracking nft firewall configuration would have something like this at the top of the input filter chain:

nft add rule iifname "lo" accept nft add rule ip filter INPUT ct state related,established accept

... and in your case, perhaps nothing else in the input filter chain.

The restriction to allow web browsing only would then be done in the output filter chain, either by allowing new outbound connections to ports 53 (for DNS resolution), 80 and 443 only. However, this will allow through any protocols that have been designed to use the same ports as web browsing traffic: this includes some VPN protocols.

A more secure "web browsing only" configuration can be achieved by forcing all web browsing traffic to use a web proxy.

Forcing a web proxy will also allow more detailed protocol-level inspection of the traffic if you want that. Note that depending on jurisdiction and the nature of your clients, there might be privacy issues you should be aware when doing this.

Improve this answer
5
  • You have dport as 80 and 443 and it will not work. For return traffic it should be sport of 80 and 443 Commented Apr 25 at 23:35
  • @Bruce Malaudzi The two nft lines are copied verbatim from the OP's question, and just replacing dport with sport would let external hosts attack any local port at all as long as the traffic is initiated from port 80/443 (which is a common enough trick to exploit stateless firewalls. Added an example connection tracking configuration, which only lets in return traffic to known connections that have been initiated in the outbound direction. Commented Apr 26 at 3:23
  • Thanks for the feedback. I accidentally included NEW in the input chain. I will edit the answer. However, with regards to destination and source port, these are flipped around by client and server, such that destination port from client becomes source port from server. Being said that, netfilter uses this information to track ESTABLISHED or RELATED connections Commented Apr 26 at 22:28
  • @BruceMalaudzi My answer was written relative to the original question only: just like you, I was trying to highlight that the nft lines described in the question would be a mistake. But the input rule withct state established,related is not just about port numbers: it will track outgoing connections and only let in packets that seem like valid responses to them, by not only checking port numbers, but also TCP sequence numbers, flag states and segment sizes agreed on that connection so far. The ruleset in your answer seems fine. Commented Apr 27 at 2:08
  • Thanks for the positive discussion. This is helpful and educative Commented Apr 27 at 10:35
1

When a web client makes an HTTP or HTTPS connection to a remote server, the following will happen:

  1. Client system will make a DNS request to DNS server, to resolve web server's hostname or FQDN to IP. The destination port for this packet is normally UDP 53 while the source port is ephemeral (randomly selected by client between 1024-65535). TCP 53 is usually used by DNS servers than clients, for purposes such as zone transfers. Therefore you might not need permit TCP 53 in this case.
  2. DNS server will respond with an IP that points to web server. The source port this time is 53
  3. Client then makes an HTTP request to web server, using destination IP and destination port of the web server (TCP 80 or 443 by default). The source port (ephemeral port) belongs to client. Ephemeral ports are higher port numbers that the client randomly select as source port (between 1024 and 65535).
  4. In the HTTP response, the IP addresses and ports are flipped around. Web server will respond with destination IP of client, destination port that the client initially selected as source port. The source IP and source port (TCP 80 or 443) belongs to web server in this case.

When making firewall rules, you will need at least three OUTPUT chain entries and three INPUT chain. The three INPUT chain entries can be consolidated into one entry. The OUTPUT chain will permit outgoing request from client to internet, and the INPUT chain will permit return traffic from internet to client

# Flush previous rules to avoid conflicts sudo nft flush ruleset # Allow outgoing traffic (OUTPUT chain) sudo nft add rule ip filter output udp dport 53 ct state new,established accept sudo nft add rule ip filter output tcp dport 80 ct state new,established accept sudo nft add rule ip filter output tcp dport 443 ct state new,established accept # Allow return traffic (INPUT chain) sudo nft add rule ip filter input tcp sport 53 ct state related,established accept sudo nft add rule ip filter input tcp sport 80 ct state related,established accept sudo nft add rule ip filter input tcp sport 443 ct state related,established accept # Optional: You can consolidate all INPUT chain entries into one entry. sudo nft add rule ip filter input ct state related,established accept # Block anything that you did not permit sudo nft add rule inet filter input drop sudo nft add rule inet filter output drop sudo nft add rule inet filter forward drop # If consider to persist the rules (survive after system reboot) sudo nft list ruleset > /etc/nftables.conf
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.