2014-11-26
Using iptables to block traffic that's not protected by IPSec
When I talk about my IPSec setup, I often say that I use GRE over IPSec (or 'an IPSec based GRE tunnel'). However, this is not really what is going on; a more accurate but more opaque description is that I have a GRE tunnel that is encrypted and protected by IPSec. The problem, and the reason that the difference matters, is that there is nothing that intrinsically ties the two pieces together, unlike something where you are genuinely running X over Y such as 'forwarding X11 over SSH'. In the X11 over SSH case, if SSH is not working you do not get anything. But in my case if IPSec isn't there for some reason my GRE tunnel will cheerfully continue working, just without any protection against either eavesdropping or impersonation.
In theory this is undoubtedly not supposed to happen, since you (I)
designed your GRE setup to work in conjunction with IPSec. Unfortunately
in practice there are any number of ways for IPSec to go away on
you, possibly without destroying the GRE tunnel in the process.
Your IPSec IKE daemon probably removes the IPSec security policies
that reject unencrypted traffic when it shuts down, for example,
and if you're manually configuring IPSec with setkey
you can do
all sorts of fun things like accidentally leaving a 'spdflush;
'
command in a control file that only (re)loads keys and is no longer
used to set up the security policies.
The obvious safety method is to add some iptables rules that block
unencrypted GRE traffic. If you are like me, you'll start out by writing
the obvious iptables
ruleset:
iptables -A INPUT -p esp -j ACCEPT iptables -A INPUT -p gre -j DROP
This doesn't work. As far as I can tell, the Linux IPSec system
effectively re-injects the decrypted packets into the IP stack,
where they will be seen in their unencrypted state by iptables rules
(as well as by tcpdump
, which can be both confusing and alarming).
The result is that after the re-injection the ipfilters rules see
a plain GRE packet and drop it.
Courtesy of this netfilter mailing list message, it turns out that what you need is to match packets that will be or have been processed by IPSec. This is done with a policy match:
iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT iptables -A INPUT -p gre -j DROP # and for outgoing packets: iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT iptables -A OUTPUT -p gre -j DROP
Reading the iptables-extensions manpage suggests that I should add
at least '--proto esp
' to the policy match for extra paranoia.
I've tested these rules and they work. They pass GRE traffic that is protected by IPSec, but if I remove the IPSec security policies that force IPSec for my GRE traffic these iptables rules block the unprotected GRE traffic as I want.
(Extension to non-GRE traffic is left as an exercise to the reader. I have a simple IPSec story in that I'm only using it to protect GRE and I never want GRE traffic to flow without IPSec to any destination under any circumstances. Note that there are potentially tricky rule ordering issues here and you probably want to always put this set of rules at the end of your processing.)
Using go get
alone is a bad way to keep track of interesting packages
When I was just starting with Go, I kept running into interesting Go
packages that I wanted to keep track of and maybe use someday. 'No
problem', I thought, 'I'll just go get
them so I have them sitting
around and maybe I'll look at them too'.
Please allow yourself to learn from my painful experience here and don't
do this. Specifically, don't rely on 'go get
' as your only way to keep
track of packages you want to keep an eye on, because in practice doing
so is a great way to forget what those packages are. There's no harm in
go get
'ing packages you want to have handy to look through, but do
something in addition to keep track of what packages you're interested
in and why.
At first, there was nothing wrong with what I was doing. I could
easily look through the packages and even if I didn't, they sat
there in $GOPATH/src
so I could keep track of them. Okay, they
were about three levels down from $GOPATH/src
itself, but no big
deal. Then I started getting interested in Go programs like vegeta, Go Package Store,
and delve, plus I was
installing and using more mundane
programs like goimports
and golint.
The problem with all of these is that they have dependencies of
their own, and all of these dependencies wind up in $GOPATH/src
too.
Pretty soon my Go source area was a dense thicket of source trees
that intermingled programs, packages I was interested in in their
own right, and dependencies of these first two.
After using Go seriously for not very long I've wound up with far too
many packages and repos in $GOPATH/src
to keep any sort of track of,
and especially to remember off the top of my head which packages I was
interested in. Since I was relying purely on go get
to keep track of
interesting Go packages, I have now essentially lost track of most of
them. The interesting packages I wanted to keep around because I might
use them have become lost in the noise of the dependencies, because I
can't tell one from the other without going through all 50+ of the repos
to read their READMEs.
As you might guess, I'd be much better off if I'd kept an explicit list of the packages I found interesting in some form. A text file of URLs would be fine; adding notes about what they did and why I thought they were interesting would be better. That would make it trivial to sort out the wheat from the chaff that's just there because of dependencies.
(These days I've switched to doing this for new interesting packages I
run across, but there's some number of packages from older times that
are lost somewhere in the depths of $GOPATH/src
.)
PS: This can happen with programs too, but at least there tends to
be less in $GOPATH/bin
than in $GOPATH/src
so it's easier to
keep track of them. But if you have an ever growing $GOPATH/bin
with an increasing amount of programs you don't actually care about,
there's the problem again.