1

I'm new to Linux and more familiar with Windows I describe the situation with the latter so I can ask the proper question in given context. On Windows, if you run the local system firewall in strict Block mode, there are a few requirement to even have network connections to work properly. The default built-in firewall setup has a few rules usually called "Core Networking" that are present and enabled to ensure you have network connectivity going. For example:

Core Networking - Destination Unreachable Fragmentation Needed (ICMPv4-In)
Core Networking - Dynamic Host Configuration Protocol (DHCP-In) 
Core Networking - Internet Group Management Protocol (IGMP-In)
Core Networking Diagnostics - ICMP Echo Request (ICMPv4-In)
(and their counterparts for Outbound)

This is the bare minimum needed for the networking to work. The rest is app-domain configuration, i.e. whatever app and its functionality you need - you add custom rules.

My question then: does Linux operate similarly? For example, if I install default Arch, I will have no pre-configured iptables or firewall rules and I would need to make them myself. Is there some specific set of default required global rules I would need to have if I put my firewall into "Block all that is not explicitly allowed" to have core networking available?

The reason I'm asking is I know some distros, especially the server ones, have such state by default - you have to explicitly allow/open ports you want or need. I had used quite a few of them that were provided with the VPS/VDS. The thing I dont know is the intricacies of how that was set up. I dont have much experience to make educated conclusion. Obviously I know how to make global iptabels rule that rejects all incoming data on any port and I know how to make exception for port 22, for example. What I dont know is if there is something besides that, behind the scene, I need to setup, similar to the example with Windows above.

I've tried something like:

iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
iptables -A INPUT -j DROP

But now this wont even allow outgoing stuff like simple ping ip.ip.ip.ip.

What I'm missing?

1 Answer 1

0

You blocked ping replies (or any connection reply). You are missing rules to implement a stateful firewall. For example since you're using Arch Linux this is documented in Simple stateful firewall. The important part that you miss is:

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

This will tell iptables for every incoming packet to query the conntrack subsystem if the packet just received is already part of a tracked flow. If this flow does exist and in the expected state, that means it (ie: the very first packet of this flow) was previously accepted when first seen (eg: the OUTPUT chain accepts everything in OP's case) and so accept the packet (and short-circuit any remaining rule).

Applying this to a ping: the incoming ping reply packet will be seen as part of the flow created by the outgoing ping request and will thus be accepted instead of being dropped because there's no rule to allow it.

Remember order does matter. This rule should be the first rule (or use -I INPUT instead of -A INPUT to insert it in first position if done later). You should read the rest of that Arch Linux wiki page for additional details.

Don't expect to find an exact parity for features from other OSes, you might have to change the way of thinking about it.

5
  • Isnt this rule creates loophole? Let's say I have a service that binds ports 9000 and 9001. Now, there is no way to configure said service to disable 2nd port for extra functionality, so, taking into the context my desired firewall setup, I block all but allow 9000. Wouldnt the stateful rule then automatically allow later 9001 as well as a part of the network state of the app? This is what essentially happens with web-server, connection to 80 then delegated to other random port so 80 can accept next query.
    – Digika
    Commented Apr 30, 2022 at 16:57
  • This does not happen. How would there be a relation between ports 9000 and 9001?
    – A.B
    Commented Apr 30, 2022 at 17:19
  • And there is no "delegated to other random port than 80" either.
    – A.B
    Commented Apr 30, 2022 at 17:20
  • I think you are applying Windows assumptions on Linux. Accepting a connection on port 80 never creates any other port.
    – A.B
    Commented Apr 30, 2022 at 17:21
  • Last but not least: I put various links in my answer. One of them the documentation on Arch Linux, an other about conntrack on Wikipedia. You really should read them.
    – A.B
    Commented Apr 30, 2022 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .