Would it not be easier to switch off ssh forwarding on the ssh server? Just change AllowTcpForwarding from yes to no in your /etc/ssh/sshd_config. If this doesn't suit, you could try something along the lines of
iptables -A OUTPUT -o eth1 -p tcp --cmd-owner "sshd" -j DROP
With IPTables rules, order matters. The rules are added, and applied, in order. Moreover, when adding rules manually they get applied immediately. Thus, in your example, any packets going through the INPUT and OUTPUT chains start getting dropped as soon as the default policy is set. This is also, incidentally, why you received the error
message you did. What is happening is this:
- The default DROP policy get applied
- IPTables receives a hostname as a destination
- IPTables attempts a DNS lookup on 'serverfault.com'
- The DNS lookup is blocked by the DROP action
While the source/destination options will accept hostnames, it is strongly discouraged. To quote the man page,
Hostnames will be resolved once
only, before the rule is submitted to
the kernel. Please note that
specifying any name to be resolved
with a remote query such as DNS is a
really bad idea.
Slillibri hit the nail on the head which his answer, you missed the DNS ACCEPT rule. In your case it won't matter, but generally I would set the default policy later on the process. The last thing you want is to be working remotely and allow SSH after turning on a default deny.
Also, depending on your distribution, you should be able to save your firewall rules such that they will be automatically applied at start time.
Knowing all that, and rearranging your script, here is what I would recommend.
# Allow loopback
iptables -I INPUT 1 -i lo -j ACCEPT
# Allow DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
# Now, allow connection to website serverfault.com on port 80
iptables -A OUTPUT -p tcp -d serverfault.com --dport 80 -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Drop everything
iptables -P INPUT DROP
iptables -P OUTPUT DROP
Best Answer
The thing to remember is that firewall rules are checked in the order they are listed. The kernel will stop processing the chain when a rule is triggered that will either allow or dis-allow a packet or connection.
Assuming that your current firewall only has that single rule (check for instance with
iptables-saveoriptables -L -v -n --line-numbers):You need append a second rule that instructs your firewall what to do with traffic that isn't matched by the first rule.
Rules without a more specific matching rule will match anything and the very short:
should suffice.
Check with
iptables-saveand you should see a minimal firewall similar to this:Addendum: when no rules are triggered the policy that is set on a chain gets applied. So rather than adding a rule that blocks everything at the end of your current config you can also set/change the policy on the input chain to achieve the same:
and