|
ipv6 stafeful firewall rules
![[de]](/s/countries/de.gif) Shadow Hawkins on Wednesday, 25 February 2015 11:35:34
Dear all,
I have set up an ipv6 router including radvd and a firewall including logging as described in the sixxs wiki here:
https://www.sixxs.net/wiki/IPv6_Firewalling#A_more_sophisticated_script_for_IPv6_stateful_firewall
I noticed now that when performing e.g. apt-get dist upgrade on the router or on a machine on my LAN it is now using ipv6 by default. The upgrade succeeds, however on my router machine i can see the following lines in my syslog originating from the firewall log-rules:
INPUT-v6:IN=sixxs OUT= MAC=<someMAC> TUNNEL=<ip4 of sixxs pop>-><my lan ip4> SRC=2a00:1450:4013:0c01::6d DST=<local ip6 tunnel addr> LEN=80 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=993 DPT=41021 WINDOW=42594 RES=0x00 ACK SYN URGP=0
The firewall is set up as default deny and produces a log line for all packets that have not been accepted by previous rules.
As my traffic is not seemingly affected in any way I am not sure what this means but I'd prefer to understand why these packets are getting dropped. Does anybody understand what is happening? Any more information that I can provide? Is this maybe just an unwanted connection attempt which is supposed to end up in the default deny target or am i doing something wrong? The src address translates to "ea-in-x6d.1e100.net" which I probably do not have any business with.
I also apply above mentioned firewall rules (except the forwarding parts) on some clients of my LAN. When performing apt-get dist-upgrade I can see the following lines in the syslog of the respective machine:
INPUT-v6:IN=eth0 OUT= MAC=<someMAC> SRC=2001:0a78:0005:0000:0216:35ff:fe7f:be4f DST=<local machine ip6> LEN=80 TC=0 HOPLIMIT=54 FLOWLBL=0 PROTO=TCP SPT=80 DPT=38335 WINDOW=28560 RES=0x00 ACK SYN URGP=0
The src address translates to "lobos.debian.org" which seems to try to connect to me during the upgrade. Here I do not understand why this connection attempt is happing. As the upgrade succeeds it does not seem to necessary? Secondly I do not understand why this connection attempt by lobos passes the forwarding filter on my router my machine.
I am sorry for this lengthy post but it seems that ip6tables rules are a bit more complex to me than I first thought. Any help in understand this would be greatly appreciated.
Thank you :)
ipv6 stafeful firewall rules
INPUT-v6:IN=sixxs OUT= MAC=<someMAC> TUNNEL=<ip4 of sixxs pop>-><my lan ip4> SRC=2a00:1450:4013:0c01::6d DST=<local ip6 tunnel addr> LEN=80 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=993 DPT=41021 WINDOW=42594 RES=0x00 ACK SYN URGP=0
The src address translates to "ea-in-x6d.1e100.net" which I probably do not have any business with.
1e100 == Google.
SPT=993, I assume Source Port 993, is typicaly IMAPS (TLS edition of IMAP)
Does your local client use Gmail maybe?
I also apply above mentioned firewall rules (except the forwarding parts) on some clients of my LAN.
Do you mean on the host itself, why not centralize your firewall rules? (FORWARD chain)
INPUT-v6:IN=eth0 OUT= MAC=<someMAC> SRC=2001:0a78:0005:0000:0216:35ff:fe7f:be4f DST=<local machine ip6> LEN=80 TC=0 HOPLIMIT=54 FLOWLBL=0 PROTO=TCP SPT=80 DPT=38335 WINDOW=28560 RES=0x00 ACK SYN URGP=0
The src address translates to "lobos.debian.org" which seems to try to connect to me during the upgrade.
That is return traffic on port 80 HTTP, which is consistent with an apt-get upgrade.
Note the "ACK SYN", that is an acknowledgement to the SYN, which would be sent by your host.
Check your /etc/apt/sources* and you'll likely find that one of the hosts there maps to the address of that machine.
As the upgrade succeeds it does not seem to necessary?
Your client is likely falling back to another server instead. Likely, IPv4.
Run a tshark/tcpdump or maybe better a wireshark and you will learn a lot about this all.
(You can do "tcpdump -w /tmp/log.pcap -n -i eth0" and then check it with Wireshark for easier insight into what happens.)
ipv6 stafeful firewall rules
Shadow Hawkins on Thursday, 26 February 2015 13:20:481e100 == Google.
SPT=993, I assume Source Port 993, is typicaly IMAPS (TLS edition of IMAP)
Does your local client use Gmail maybe?
Yes, I am.
Do you mean on the host itself, why not centralize your firewall rules? (FORWARD chain)
Thats what I am aiming for. So far I am doing both. I do not have any experience with iptables so I set up these log targets on some hosts in order to check if I was missing something on the router iptables. Also I figured it'd be good to play around in order to gain experience.
That is return traffic on port 80 HTTP, which is consistent with an apt-get upgrade. Note the "ACK SYN", that is an acknowledgement to the SYN, which would be sent by your host.
So it seems that all that I have seen is return traffic which is fine. It seems that I simply forgot to add accept "established, related" not only to the forwarding chain of the router but also to the input chain of the hosts. Now that I understand the concept the latter should probably be replaced by a default accept.
Your client is likely falling back to another server instead. Likely, IPv4.
Run a tshark/tcpdump or maybe better a wireshark and you will learn a lot about this all. (You can do "tcpdump -w /tmp/log.pcap -n -i eth0" and then check it with Wireshark for easier insight into what happens.)
Thank you for these hints. That all makes a lot of sense now :)
ipv6 stafeful firewall rules
SPT=993, I assume Source Port 993, is typicaly IMAPS (TLS edition of IMAP) Does your local client use Gmail maybe? Yes, I am.
Then you now know what that host is about :)
It seems that I simply forgot to add accept "established, related"
Do note that that stateful firewalling is in a way magic. Mostly it will work (99%) but there are corner cases where the TCP/IP state machines will be different in knowledge than the stateful firewall. Also, there are corner cases that allow traffic that comes in bound that you do not want.
Because of connection flooding stateful anything is considered a bad idea. It all depends on your use case (and adversaries) of course if those things can be problematic or not. Most 'routers' aka home CPE NAT boxes have a limited (16k) amount of connections they can track, after that things break down, you can find ample amounts of examples in the bittorrent forums about this as bittorrent makes lots and lots of connections.
It is thus typically considered better to do firewalling on the host that terminates the communication.
Of course a static rule can be put in the middle of a network, but do send ICMP ADMIN REJECT to indicate that that is happening for clarity and to avoid the need for timeouts to notice that something is wrong.
For OSX users it is very heavily recommended to use Little Snitch for that matter, IMHO one can't live without that on a host. Windows apparently has NetLimiter (never used it), on Linux you'll have to write your own it seems at the moment.
With those tools then you can do 'firewalling' per process/time. The only problem with that is that you need to configure them per-machine and non-tech users might be a bit overloaded with it.
ipv6 stafeful firewall rules
Shadow Hawkins on Friday, 27 February 2015 10:18:02
Thank you Jeroen for your input. I will look into what you suggested.
With ip4 I have been living kind of in the "I feel secure because NAT protects me" world. Now I want to develop an understanding of what I can (have?) to do with ip6 and firewalling. I figure there must be lots of people like me. Do you maybe know some kind of tutorial through which I can learn an which can guide me through this process? As you said, the firewall probably has to be adapted to my setup so I figure I have to develop an understanding of the basics first. So far I set the tables to default deny and dropped in as many accept rules until everything worked ... :)
ipv6 stafeful firewall rules
With ip4 I have been living kind of in the "I feel secure because NAT protects me" world.
There is nothing "secure" about NAT. The only property that helps, a little bit, is that it effectively makes a stateful firewall. But that is also its weakness as the stateful firewall can accidentally open up things that you do not want to have open.
For most home networks that is quite fine though, as you won't have to defend against DDoS attacks or similar situations in most cases anyway.
Do you maybe know some kind of tutorial through which I can learn an which can guide me through this process?
Unfortunately the subject is extremely large, a tutorial would IMHO not suffice. There are lots of good thick books about it, but most importantly this kind of knowledge comes from experience.
But the first questions you have to ask in any security situation:
- who is the adversary?
- what do you want to protect?
- what/who do you want to protect things from?
- which people are involved, how much do you trust them?
- how much pain can afford?
The first one, as if you are protecting against a nation-state, then you have lost already unless you invest lots or go offline. The last one is there because when you disconnect, you are the safest.
For a home network you likely want "less pain" for the users. Thus a "Little Snitch" on the host can already be too painful for most people. Hence a centralized stateful firewall is pretty good there.
If you have devices that never should talk to the Internet (eg lightbulbs, webcams), put them in a separate VLAN, route them, but firewall them to the extreme (or completely, and/or just not route/forward that prefix at all). For actually reaching them, use a central proxy server or a VPN into the network.
For corporate networks, only allow things to talk that are supposed to talk. Don't allow any unwanted traffic.
Which brings one to port 80/443. As these are very hard to firewall in most environments and actually contain the bulk of the stuff you likely do not want to see. But even if you close those, somebody will open an email and click on things.
Hence, monitoring becomes really important too, and so is storing netflow for after-the-fact evidence/reporting.
As stated... it all depends :)
ipv6 stafeful firewall rules
Shadow Hawkins on Monday, 02 March 2015 12:39:34
thanks again Jeroen. I will get more into it with time i guess. So far i think i replicated nat/ stateful firewall behaviour. for my small home network that should suffice for now i hope.
|
![[ch]](/s/countries/ch.gif)
on Wednesday, 25 February 2015 13:40:23
Posting is only allowed when you are