[SOLVED] Using existing rc.firewall IPV4 to drop all IPV6 traffic
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Using existing rc.firewall IPV4 to drop all IPV6 traffic
Running Slackware Current. I have managed to create my own rc.firewall file which is in /etc/rc.d and this has Policies to Drop all Input, Ouput and Forward Traffic not explicitly allowed. The rc.firewall is executable and runs whenever the server restarts.
Reading up on the matter, I understand that my firewall rules only apply to IPV4 traffic. I understand that you have to explicitly use IP6Tables commands to create rules and Policies.
Because we don't use IPV6 on our networks and our ISP does not yet support IPV6, I want to block IPV6 traffic passing through the firewall although probably nothing is being passed through. But I will temporarily log it to see.
I cannot find any examples using Google Search whether I can simply do something like this in my rc.firewall file or if I need to use a completely separate rc.X file to access the IPV6 Tables?
Code:
# Policy Rules
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
*Iptables rules below (for IPV4 traffic)
* No rules required for IP6Tables as no IPV6 traffic allowed through firewall
I presume that the IPv6 traffic won't be logged as my logging rules are just for Iptables not for IP6Tables?
I just had to start worry about IP6 last week. I was setting up a private part of a website and asked the people that were going to access it to give me their IP address. One of them only had an IP6 address.
I have:
ip6tables —policy INPUT DROP
ip6tables —policy OUTPUT DROP
ip6tables —policy FORWARD DROP
Pretty much your setup except I'll have to add more rules as I go so I added the --policy to it.
You should be able to see if any IP6 has hit your website by searching httpd logs for '::'
You should be able to see if any IP6 has hit your website by searching httpd logs for '::'
grep -l :: /var/log/httpd/*
:: in IPv6 means "any length of consecutive octets that are 0" - not all IPv6 addresses contain consecutive 0s; so this grep will not match every IPb6 address.
:: in IPv6 means "any length of consecutive octets that are 0" - not all IPv6 addresses contain consecutive 0s; so this grep will not match every IPb6 address.
That's true. However I've not seen many that don't have at least two ::
R
Because we don't use IPV6 on our networks and our ISP does not yet support IPV6, I want to block IPV6 traffic passing through the firewall although probably nothing is being passed through. But I will temporarily log it to see.
If your ISP is not passing IPv6, you don't have to do anything, becasue you will never see any v6 traffic.
That said, just setting default policy DROP for ip6tables might be handy, should they start playing with IPv6 without telling anyone in the future. When they do start issuing ipv6, the changes you need to make are pretty easy anyway.
Mr. Cyborg was faster than me, but I will add my regarding the sysctl and kernel network stack.
Not only will ipv6 be disabled, but iptables will know nothing of it, and neither will your network stack. At system boot up, ipv6 doesn't exist. Great for home routers or any such system that may have more than one network interface for different purposes.
Another option is by modifying your lilo configuration (/etc/lilo.conf) by adding to the append variable:
Code:
append=" ipv6.disable=1 "
Lilo, is probably the most convenient way, but requires a reboot to reverse.
You don't need to worry at all about IPv6 on a post-15.0 Slackware - SLAAC (the auto-provisioning protocol) is not enabled by default in the new rc.inet1.
You will get a ::1 IP bound to your lo interface, but this is harmless in the whole. You won't get any sort of other IPv6 address without explicitly enabling that features in rc.inet1.conf.
Also, while some of the suggestions of how to disable IPv6 may work, the only way I completely tested disabling IPv6 was following the process I documented in /usr/doc/network-scripts-*/README.IPv6
This would absolutely insure that IPv6 is never activated, without the need to add a boot time parameter, or fuss with sysctl (which has its own issue that it is applied AFTER the interfaces are brought up, so you'd still get a ::1 IP).
Sorry to take so long to get back to you. I am very pleased to see that it really is that simple. I was expecting to have to use separate files and for it to be a lot more complicated! Not sure I understand the difference between -P and -Policy. The -P works fine for me on IPv4 and I am adding rules all the time.
To clarify the use of this server - it's not a web server or anything like that. So I can't look for web traffic in that way. Disabling IPV6 on the server is not an option either as this may or may not affect Lan traffic and more importantly makes it difficult to see what actual IPv6 traffic there is on the Lan. The purpose of the server is to filter internet traffic from the lan to the Internet and second to use the firewall to block all unused ports and restrict (as much as possible) all ports in use to the specific Windows Servers or internet IP addresses where possible. Research suggests that disabling Ipv6 on Windows computers is not a good idea as Microsoft is starting to provide Windows services that only use Ipv6. At the moment we are not using any of those Microsoft services and as our ISP doesn't use IPv6 anyway, it is simpler to just drop all IPV6 connections that may or may not go through the firewall.
In addition, the client that I am setting up has two sites connected to each other via a Draytek VPN. So even though the Internet does not support IPv6, I currently have no idea what, if any IPv6 traffic is going across the vpn to the other site. Thus dropping IPv6 also works well for networks spanning more than one site if I am not going to disable IPv6 on Windows, which I have come to the conclusion is not a long term option as IPv6 is gradually being pushed by the big companies.
I must admit that I don't really see the point in Ipv6 as effectively it makes all computers IP addresses open to the Internet. I prefer IPv4 and Nat so as not to expose our entire networks to the Internet. Last but not least, it's much easier to remember IPv4 IP addresses than IPv6! I don't see IPv4 going away anytime soon.
This is a good and simple advice if IPv6 is not needed at all. But would it still be required to use explicit firewall rules if there's a requirement of logging the IPv6 traffic before dropping it?
I'd still suggest the method I documented to disable IPv6 rather than sysctl.
sysctl settings are applied AFTER interfaces are brought up, so your system would be configured with a ::1 address bound to the lo interface before IPv6 was disabled.
While having the ::1 is completely harmless, I don't know if disabling it via sysctl would remove the ::1 IP once IPv6 is disabled.
If you want to log IPv6 traffic, you would have to leave IPv6 enabled in order for the packets to be passed through netfilter.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.