iptables rules for Steam

My rules for iptables initially were

Code:

iptables -N TCP
iptables -N UDP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-rst
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable
iptables -A TCP -p tcp -m tcp --dport 22 -j DROP
iptables -A TCP -p tcp --dport 80 -j DROP
iptables -A TCP -p tcp --dport 443 -j DROP
iptables -A TCP -p tcp --dport 22 -j DROP
iptables -A UDP -p udp --dport 53 -j DROP
nano /etc/sysctl.d/90-firewall.conf

net.ipv4.conf.all.rp_filter=1

iptables -I TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst
iptables -D INPUT -p tcp -j REJECT --reject-with tcp-rst
iptables -A INPUT -p tcp -m recent --set --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst
iptables -I UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN -j REJECT --reject-with port-unreach
iptables -D INPUT -p udp -j REJECT --reject-with icmp-port-unreach
iptables -A INPUT -p udp -m recent --set --name UDP-PORTSCAN -j REJECT --reject-with icmp-port-unreach
iptables -D INPUT -j REJECT --reject-with icmp-proto-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

But I noticed I wasn't able to play online: http://steamcommunity.com/app/221410/discussions/0/558746745946078893/
So, after literally 6 hours of research and hundreds of threads read, adding the following lines solved the problem:

Code:

iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT --dport 27014:27050
iptables -A INPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT --dport 27000:27015
iptables -A INPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT --dport 27015:27030

I'm new to iptables, so I don't know if there needs to be any specific order to put them that does not compromise the overall security. Could you guys lend a help?

Code:

[root@junior junior]# iptables-save
# Generated by iptables-save v1.4.21 on Sat Feb  1 23:23:39 2014
*nat
:PREROUTING ACCEPT [2547:139827]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [7532:415619]
:POSTROUTING ACCEPT [9955:512539]
COMMIT
# Completed on Sat Feb  1 23:23:39 2014
# Generated by iptables-save v1.4.21 on Sat Feb  1 23:23:39 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1291511:85540228]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m recent --set --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset
-A INPUT -p udp -m recent --set --name UDP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A INPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 27014:27050 -j ACCEPT
-A INPUT -p udp -m state --state NEW,ESTABLISHED -m udp --dport 27000:27015 -j ACCEPT
-A INPUT -p udp -m state --state NEW,ESTABLISHED -m udp --dport 27015:27030 -j ACCEPT
-A TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset
-A TCP -p tcp -m tcp --dport 22 -j DROP
-A TCP -p tcp -m tcp --dport 80 -j DROP
-A TCP -p tcp -m tcp --dport 443 -j DROP
-A TCP -p tcp -m tcp --dport 22 -j DROP
-A TCP -p tcp -m tcp --dport 6881 -j DROP
-A TCP -p tcp -m tcp --dport 8881 -j DROP
-A UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable
-A UDP -p udp -m udp --dport 53 -j DROP
COMMIT
# Completed on Sat Feb  1 23:23:39 2014
[root@junior junior]# 

 

First off, I have to warn you that you should probably do more research on iptables. Take a look at the man page; particularly the parts about the "filter" table, which is what desktops use.

There must indeed be a specific order. The rules are processed from top to bottom, but processing for a packet stops as soon as it reaches the first matching rule. If you follow up an ACCEPT rule with more specific REJECT rule, the REJECT rule will not be enforced.

Re your original rules, they're kind of redundant. There's no need to block ports specifically if you drop all unsolicited input by default.

OTOH, your fix for Steam involves accepting unsolicited input on a few dozen high ports, which doesn't seem like a good idea to me.

My advice is...

1. Get rid of your iptables rules. (You can flush them without rebooting; refer to the man page.)

2. Implement some simple rules. To get you started:

Code:

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT # No need to block outbound connections
-A INPUT -i lo -j ACCEPT # Accept any and all loopback connections
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Accept solicited inbound backets
COMMIT

Applying them for IPv6 as well would be a prudent. Also remember to allow the right inputs if you need e.g. SSH access or a ping response.

3. Run Steam. See if playing online works.

4. If it doesn't, run 'netstat -upantl' as root, and see what Steam is doing.

5. If Steam really is listening on a bunch of high ports, think a while before unblocking them. There might be a good reason for its behavior, or there might not. Accepting unsolicited connections, without explicitly telling you why, is not what I'd consider friendly behavior by an application.

Edit: also note that one rapidly reaches a point of diminishing returns, when trying to secure a desktop with iptables rules. Basically you just want to block unsolicited inbound stuff, in case some stupid program opens a port.

Most desktop security problems these days involve client vulnerabilities, the majority of which involve browsers, and the majority of which in turn involve browser plugins. Disabling Java and Flash where they're not needed would offer a much better return than messing with iptables IMHO.

 

Those are the ports needed by Steam: https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711

Why exactly?

I started with those simple rules. But I'm too paranoid, and the Arch Wiki explains more things and specify the rules. https://wiki.archlinux.org/index.php/Simple_Stateful_Firewall

I don't need ssh nor ping response, so I keep them disabled.

I can, but these rules aren't enough for my paranoia.

Without these ports opened I can't play online. So what changes should I do to those specific port rules?

 

Hmm. Not sure why they should need inbound ports, unless there's some peer-to-peer element. I don't know much about Steam, doesn't it use a client/server model?

Because having a complicated and redundant ruleset confuses things, and makes problems like this difficult to solve.

The fancy rules aren't doing anything better, and may be doing something worse. Also, satisfying "paranoia" makes you less secure, not more, because it gives you a false sense of security.

Real security is about reducing risks. To do that you have to have some idea of what risks you face, and how they can be dealt with.

Those are two very incompatible notions there.

If you "feel" that a standard iptables firewall setup is not secure enough, the rules aren't the problem; the problem is that you don't know enough about iptables.

On the other hand, if you value security that much, why on Earth are you willing to allow open ports for some silly online game?

In any case, I'd recommend (again) reading the iptables man page, specifically the part about the "filter" table. That will tell you exactly what you need to know.

 

After some internal debate, I have to say the following...

@amarildojr: If you want to learn more about Linux, I would recommend skipping iptables for now, and instead looking into general shell scripting, e.g.

http://tldp.org/LDP/abs/html/

Automating stuff is where Linux really shines, and believe me, you will eventually find something you want to automate.

(A relevant example: what would you do if you wanted to print a bunch of slightly different iptables rules, for VMs running different services?)

Also, if you want to learn more about security, you should probably try to get into C, which is the foundational language of most OSes and also the source of most security problems. There are some very good free books on C, e.g.

http://publications.gbdirect.co.uk/c_book/

Point is, you won't be able to understand security if you don't understand the context. I've been using Linux for ~10 years now, have made a career out of it, and I'm still basically a newbie. There's a huge amount to learn in this field, so don't let yourself get bogged down in trivialities.

 

My firewall "expertise" in Linux extends as far as block inbound, allow outbound. The exact same rules as the Windows Firewall.

Steam works perfectly fine with it. If you happen to encounter a game using P2P, that isn't actually anything to do with Steam. Steam offers networking API that doesn't require opening ports, which that game has opted not to use.