Steam and iptables

Amanda S · 2014-02-01 21:53:52

My rules for iptables initially were

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/di … 946078893/

So, after literally 6 hours of research and hundreds of threads read, adding the following lines solved the problem:

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 even if the order of these lines above don't compromise the final result of being able to play online, I don't know if there needs to be any specific order to put them that does not compromise the INPUT packages filtering security. Could you guys lend any help?

brebs · 2014-02-01 22:38:46

You're just adding confusion by using "-I" and especially "-D". The precise order of all these rules is vitally important!

To show us the rules, best way is simply show the output of:

iptables-save

You're not explicily allowing loopback, which is probably a mistake - it's a very standard rule.

Remove those portscan checks. Do you think you need them? How do you know they're not blocking legitimate traffic also? Have you tested them? Not bothering to specify "hitcount"??

Should be logging more, especially when rejecting or dropping, to see what's happening.

Amanda S · 2014-02-01 22:51:54

brebs wrote:

You're just adding confusion by using "-I" and especially "-D". The precise order of all these rules is vitally important!

I'm mostly just following the Wiki, which says:

Restore the Final Rule
If either or both of the portscanning tricks above were used the final default rule is no longer the last rule in the INPUT chain. It needs to be the last rule otherwise it will intercept the trick port scanner rules you just added and they will never be used. Simply delete the rule (-D), then add it once again using append (-A) which will place it at the end of the chain.
# iptables -D INPUT -j REJECT --reject-with icmp-proto-unreachable
# iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

brebs wrote:

To show us the rules, best way is simply show the output of:
iptables-save

[root@junior Desktop]# iptables-save
# Generated by iptables-save v1.4.21 on Sat Feb  1 20:48:32 2014
*nat
:PREROUTING ACCEPT [1102:66644]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1473:92090]
:POSTROUTING ACCEPT [2565:135770]
COMMIT
# Completed on Sat Feb  1 20:48:32 2014
# Generated by iptables-save v1.4.21 on Sat Feb  1 20:48:32 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [40701:5553994]
: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 20:48:32 2014
[root@junior Desktop]#

brebs wrote:

You're not explicily allowing loopback, which is probably a mistake - it's a very standard rule.

I know. The Wiki said it 'might' be required for some applications. I tested it many times, it's not required by any app I have installed.

brebs wrote:

Remove those portscan checks. Do you think you need them? How do you know they're not blocking legitimate traffic also? Have you tested them? Not bothering to specify "hitcount"??

Yes, I tested them. No hit count is present in the Wiki.

Do I need them? Well, do I need 10 locks on my door? Better safe then sorry

brebs · 2014-02-01 23:06:05

On the other side of the coin, it just adds confusion when you block legitimate traffic by being overzealous with blocking.

Heck, in *my* firewall rules, I block a lot of ports, but my default INPUT is to ACCEPT

Amanda S · 2014-02-01 23:16:17

brebs wrote:

On the other side of the coin, it just adds confusion when you block legitimate traffic by being overzealous with blocking.
Heck, in *my* firewall rules, I block a lot of ports, but my default INPUT is to ACCEPT

Well, I never missed anything with these rules (except for Steam)
And you obviously have more experience than me, so maybe you're a lot more confident.
Also, locking everything and then opening what is needed is the more logical way of being secure when you don't know what you're doing, which is my case. Not to mention I don't have a router Firewall, I'm connected directly to my Modem (Motorola), so every precaution is welcome.

So, back to topic, do you think any changes in the order need to be made?

brebs · 2014-02-01 23:48:59

On my usual theme of excessive blocking being bad, in general "--ctstate INVALID -j DROP" is not advisable. What if it's a "friendly" - you're making them wait for a timeout, rather than a friendly REJECT to let them know and possibly re-send much sooner. You're potentially hurting yourself with these excessive blocking rules

Specifying "-m tcp" is weird and redundant.

You're got duplicate lines for dport 22.

You're still too free with the REJECT and DROP, without any logging to warn you of problems with them. You must enjoy 6 hours of head-scratching, rather than checking a logfile

Here's another way to look at it: What makes you think you're a vulnerable target? Who's going to launch a denial-of-service or attempted-login attack on you? Hackers just scan random IP addresses, on e.g. port 80 and 22, looking for extremely easy targets. (Use a different port for ssh, not 22, e.g. 22300.)

Amanda S · 2014-02-01 23:57:27

What is a friendly consisted of? I'm a single user on my network, I don't see why others would try to connect to my machine other than attacking me hehehe.

Here's another way to look at it: What makes you think you're a vulnerable target?

Paranoia (among other things I can't tell). You can't argue with that

Specifying "-m tcp" is weird and redundant.

Hmm. Guess I should do a deeper research other than just following the Wiki on this subject.

But does it work anyway? What could I do to reduce it's redundancy?

brebs · 2014-02-02 10:08:24

Amarildo wrote:

What could I do to reduce it's redundancy?

Simply remove this exact text: -m tcp (I've removed it from the wiki)

It's already tcp from the "-p tcp" in the line, it can't be anything else.

Arch's wiki article is too complex, for a "simple" set of rules - Ubuntu's is more suitable as a starting point.

Last edited by brebs (2014-02-02 10:19:07)

Arch Linux

#1 2014-02-01 21:53:52

Steam and iptables

#2 2014-02-01 22:38:46

Re: Steam and iptables

#3 2014-02-01 22:51:54

Re: Steam and iptables

#4 2014-02-01 23:06:05

Re: Steam and iptables

#5 2014-02-01 23:16:17

Re: Steam and iptables

#6 2014-02-01 23:48:59

Re: Steam and iptables

#7 2014-02-01 23:57:27

Re: Steam and iptables

#8 2014-02-02 10:08:24

Re: Steam and iptables

Board footer