Blog

Checking that there’s only one default gateway, part one

In our last post in the series about the String Presence Check in Halo, we checked that your routing table includes the correct IP address of your default gateway.  Now we’ll make sure there are no other default routes that might funnel packets through a sniffing machine at your cloud provider.

How do we check that there aren’t any other default gateways set up?  Couldn’t someone add a second one that routes packets through, say 172.16.1.5?

Since there are 4 billion IPv4 IP addresses alone, we can’t put in a rule for each one saying

/proc/net/route Does not contain “^eth0s+00000000s+00000000s.*s00000000s”
/proc/net/route Does not contain “^eth0s+00000000s+01000000s.*s00000000s”
/proc/net/route Does not contain “^eth0s+00000000s+02000000s.*s00000000s”
/proc/net/route Does not contain “^eth0s+00000000s+03000000s.*s00000000s”

We have to get sneakier.  🙂

The alert I want is this: tell me if there’s a default route line (“^eth0s+00000000s+{something}s.*s00000000s”) that has something other than 010110AC in the default gateway column.  Instead of saying “I need the default gateway to be 010110AC”, I want to be warned if those characters are anything except 010110AC.

Our Search Expressions have something that looks promising; negating sets of characters with the caret symbol.  If I use paired brackets (“[{characters}]”), I match any character in between the brackets.  But if I place a caret right after the left square bracket, that says match any character except the ones in this set.  For example, “[0-9ABCDEF]” will match any digit or letter between uppercase A and uppercase F.  But if I put a caret right after the left square bracket: “[^0-9ABCDEF]”, that matches anything that isn’t an uppercase hexadecimal character ( %, &, j, d, H, L, etc.).

OK, so let’s try negating each character in the default gateway and see if that works:

#Does this work?
/proc/net/route Does not contain “^eth0s+00000000s+[^0][^1][^0][^1][^1][^0][^A][^C]s.*s00000000s”

To test this, let’s assume we have a second default gateway line in /proc/net/route:

# cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask   MTU      Window  IRTT
eth0    00000000        010110AC        0003    0       0       0       000000000       0       0
eth0    00000000        FEDCBA09        0003    0       0       0       000000000       0       0
eth0    000110AC        00000000        0001    0       0       0       00FFFFFF0       0       0

Our second bogus default gateway is FEDCBA09.  That matches each of the above sets (F is a character other than 0, E is a character other than 1, D is a character other than 0, C is a character other than 1, etc.).  So we have a line that matches the Search Expression.  Since we specifically didn’t want any lines that match, that will set off an alert and the planet is safe again.

Not so fast.

There’s a problem there; in our example, every single character in FEDCBA09 was different from its corresponding character in 010110AC, and since each one had to be different for the alert to go off, the alert went off.  What happens if the second bogus default gateway is different but has some characters that do match?

For simplicity, let’s say that we get a second default route through 172.16.1.255.  The reverse hex of that is FF0110AC.  Now see if that matches “^eth0s+00000000s+[^0][^1][^0][^1][^1][^0][^A][^C]s.*s00000000s”.

F is not 0, so we match there.  The second F is not 1, so we match there.  0 in our default gateway does equal 0, so we don’t match “[^0]”.  Oops, FF0110AC does not match [^0][^1][^0][^1][^1][^0][^A][^C], and since we only alert if there is a match, we won’t get an alert.

Is your head spinning like mine is?  Trust me; I had to both stop and think about this very carefully (especially because of the double negatives) and double check my logic with colleagues Apurva and Christian to make sure I got this right (thanks guys!).

So there’s the problem; we alert in the first case because all 8 characters we pulled (“FEDCBA09”) were different from their counterparts in the search expression ([^0][^1][^0][^1][^1][^0][^A][^C]).  But we didn’t alert in the second case because some of the characters in “FF0110AC” were different from that search expression and some were the same as their counterparts.  So this Search Expression doesn’t alert on every gateway except 010110AC.  🙁

Stay tuned for part 2!

Related Posts