Hiya,

I'm using the iptables rules from the Linode library, and haven't needed to change anything so far.

Is there anything I need to do to use similar rules for IPv6 (and ip6tables)?

*filter

#  Allow all loopback traffic and drop all traffic to 127/8 that doesn't use lo0.
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j DROP

#  Accept all established inbound connections.
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic.
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere.
#  -A INPUT -p tcp --dport 80 -j ACCEPT
#  -A INPUT -p tcp --dport 443 -j ACCEPT

#  Allow SSH connections.
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ICMP.
-A INPUT -p icmp -j ACCEPT

#  Log iptables denied calls.
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound traffic - default deny unless explicitly allowed policy.
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

From what I've read, it looks like I'd need to change 127.0.0.0/8 to ::1/128, and icmp to icmpv6.

Does that seem right, and is there anything I've missed?

Many thanks!

Those translations look correct. ip6tables is almost exactly the same as iptables, aside from any protocol names (e.g. icmp -> icmpv6) and IP addresses.

Out of curiosity, why block anything on the localhost? It's highly doubtful your Linode will attack itself without hacker interference (in which case, you're better off rebuilding anyways).

_________________
Kris the Piki Geeker

He's not blocking localhost; he's blocking traffic targeting 127/8 that does travel over the loopback network. This is likely to be externally spoofed traffic and so dropped.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

Ok, so he's partly blocking localhost, albeit a localhost IP address that's generally not used (127.0.0.0). Since that IP address isn't used on most systems, I'm a bit confused as to how any traffic would use it to begin with -- especially since the default policy for INPUT is DROP, and that only ESTABLISHED,RELATED and explicitly specified stuff is allowed.

_________________
Kris the Piki Geeker

Unless I'm mistaken, he's not protecting anything with that rule. Your machine should not take input on eth0 with destination address 127.0.0.0/8. Seems like a misguided application of the already questionably useful bogon filtering.

Not quite. If I see any traffic to 127.0.0.1 that appears on eth0 then I know it's illegal and invalid traffic. Drop it. Now as to the utility of this rule? I'm not convinced. I've seen it in a few tutorials. I don't do it, myself

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

If you assign 127.0.0.1 to eth0, it would be legal

However, this is highly unlikely to happen, regardless of whether we're talking 127.0.0.1 or 127.0.0.0. IMO it's pointless to assign any DROP rules for 127.* since hackers would first need to worm their way through whatever other ports and services first to utilitize it -- something highly unlikely (though not impossible) with a well-configured and up-to-date system.

_________________
Kris the Piki Geeker

Spoofing the source address is trivially simple. Hackers do it all the time. UDP services (eg DNS servers) are particularly vulnerable to IP address spoofing. TCP services are harder 'cos the three-way handshake. What damage could spoofing localhost traffic cause? Off the top of my head, not sure. This rule may be unnecessary. As I said, I don't have it... but then I don't really have a firewall at all on my linode!

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

A spoofed address doesn't mean automagically mean entry through the firewall. Remember the ESTABLISHED,RELATED clause (why do you think I consider DROP useless on localhost?)

Provided it does get through, the amount of damage depends on which services communicate on localhost.

As for your Linodes... good luck!

_________________
Kris the Piki Geeker

7 years and running. The only thing a firewall would do is block unauthorised listening ports - that'd require someone breaking into the machine via a service _not_ blocked in the first place (eg via a cgi bug, or an apache bug, or an SMTP server bug).

Firewalls are good if you have "untrusted" machines behind them (eg a corporate environment where anyone could start up a listening process on their own machine, or at home where you have older Windows instances). They're not so useful for a single instance run by a single person who has configured each port (and documented them) so he knows what is listening and where.

(I do, in fact, use iptables to rate-limit SSH connection attempts and spammer attempts; that's to stop noise in the logs more than for security).

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Would also cause the OS to not responds to connection attempts, useful for someone like me who has poor documentation skills (does Linux even respond on ports running no service? if so, can also save bandwidth)

Also to block incoming pings if, for instance, you get some %@$^ ticked off at you and he decides to set up a botnet. You know where I'm going with that, right?

_________________
Kris the Piki Geeker

Thanks for all the replies! The IPv6 rules seem to be working.

That loopback rule is an interesting one. I'm not sure whether the kernel will actually accept packets to/from 127.x.x.x on eth0. If it will, then it seems like a useful rule since an attacker can spoof UDP traffic to services which only listen locally. If not, it does seem useless

Does anyone know for sure?

Cheers!

I don't know the inner workings of the kernel, however after 6 years using Linux I've never had it listen on IP addresses which weren't actually assigned to anything, nor have I seen it listen on IP addresses on the wrong interface (e.g. 127.0.0.1 on eth0).

It wouldn't hurt to get a second opinion on that, however as I said, a well-configured and up-to-date machine shouldn't have much to worry about. Also well-documented as sweh suggested.

_________________
Kris the Piki Geeker

It won't help for services that only listen on localhost (127.0.0.1, ::1) because that'd require the _destination_ address in the packet to be set to localhost and it won't be routed.

However if you have a service that's listening on all addreses but makes policy decisions based on the source address then the rule might be interesting. One scenario might be a DNS server which is authoratative for your domains but only allows recursive calls from localhost. Someone might be able to come up with a scenario in which this could be used to make you attack yourself (the typical "lookup ISC" won't work 'cos things will be cached after the first call).

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

-A INPUT -p icmp -j ACCEPT

is referring to IPv4 icmp.

for IPv6 use:

-A INPUT -p icmpv6 -j ACCEPT