2

I have seen two set of rules to allow SSH communication:

Set A:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Set B:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

None of both sets is superior in general, but the question is specifically about ordinary SSH communications, with key-pairs-authentication-only if that simplifies the matter (and pretty much a must in the context of security), since that way we know brute force attacks are not going to pass through in any case.

Which of both sets is more restrictive (will filter out or mitigate more non-intended communication or resource-consumption)? Furthermore, is it possible to combine both sets to make an even more restrictive rule?

mikl
  • 145
  • 5
  • iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT why is this rule needed? – kalyan Mar 13 '17 at 22:40
  • @kalyan I don't have that rule in the question, I think you are referring to symcbean's answer. That rule is for establishing the connection from server to client (am I right?), but I will work only from client to server, then your question correctly suggest that the rule is not necessary? – mikl Mar 13 '17 at 23:01

1 Answers1

2

Set B, in isolation does not allow ssh communications. It merely permits a connection allowed by other rules to be continued or (subject to certain combinations such as for H.323 and FTP) for new connections to be established between IP addresses which have an existing entry in the conntrack table.

The problem with Set A is that it is not stateful - an attacker could create a client connection to any port on your server as long as the client end used port 22. To address this problem you need a stateful firewall - i.e. one that takes into consideration the direction of the connection. Hence its more common to see something like:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT 
iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Putting ESTABLISHED,RELATED first means that the whole ruleset need only be parsed once per connection - subsequent packets are matched by the first 2 rules. This can have a lot of impact on a latency with a complex ruleset.

The downside of using stateful firealling is that it consumes resource on the server - when the conntrack table fills up, the firewall will start dropping connections. OTOH, the stateful module allows for more complex demand management - typically by limiting the rate of connections.

with certificate-authentication-only

Really? While there are versions of ssh using certificates for managing keys it is a very unusual case. Do you mean key pairs?

None of both sets is superior in general

...

Which of both sets is more restrictive

If neither is superior, how can one be better?

For a host firewall, you should use stateful firewalling - to prevent the bypass described earlier.

symcbean
  • 18,278
  • 39
  • 73
  • Sorry, I was indeed referring to key pairs, edited that in my question. By "not superior" I was thinking they were interchangeable approaches to the particular situation, but I see that's not the case. – mikl Mar 13 '17 at 22:37