Underscore in Hostname

I had to add this line to my Bind9 configuration for my home DNS server:

check-names master warn;

Had to do this mainly because I was getting crap like "bad owner name (check-names)" in my syslog everytime my Android phone tried to join the network.  Apparently, DNS doesn't like special characters in hostnames.  It seems Android phones tend to have an underscore character in their hostnames.  The annoying thing about this is that you can't change the hostname on a non-rooted phone.

But anyway, using the line up above in your named.conf file will stop your syslog from adding these alerts.  I think it's probably not the best thing to do, but until my phone uses a normal hostname, I have to do it to avoid sifting through tons of useless syslog alerts.

Interestingly enough, before adding that to clean up the log, Snort was also firing each time my phone joined the network, citing it as a possible Bind9 DoS attempt.  So even if I wasn't checking my logs regularly, snort would have at least let me know that I should pay closer attention to my phone. 

IPtables Port Spanning -- Sort of

I installed Snort on a Debian virtual machine in my home test lab.  I thought it would be fun to learn more about it.  What better way to learn than to just start using it?

I pretty much just followed one of the guides available at snort.org to get snort installed with PulledPork for downloading updated rulesets.  I've actually installed snort before, but it was several years ago and on Slackware instead of Debian.  I have noticed some things that are new to snort since the last time I installed it.  Things like the sensitive data preprocessor.  No, SDP, you're wrong.  None of those web packets contain CCN's or SSN's.  I actually disabled SDP in the end.  If you just comment out the sensitive data preprocessor line in snort.conf and the sensitive-data-rules line, you'll probably find that snort will die often and complain about something with "sd_pattern".  Just look in the snort.rules file and comment out the alert lines containing "sd_pattern".  That should solve that problem.  Unless of course, you really do need to look for sensitive data.  In that case, don't turn it off.  But do get ready for loads of false positives.

Having an IDS installed is not fun if you can't get packets for it to process, though.  I don't really care about chatter inside my network between the different machines.  I just wanted to process any packets sent or received through my router (machine running Debian and iptables).

I own a switch, not a hub, so plugging in the physical network connection used by the snort VM won't do any good.  And my switch is a cheap, unmanaged switch.  So I can't do a span port on it, either.

Then I learned about the TEE target in iptables.  It will copy the packets passing through the firewall and forward them over the network to another machine.  Yes, it's probably not the most secure method in the world, but it was exactly what I needed for my home network.  Kind of like a simulated span port.

However, it was a pain to get going on Debian stable.  In fact, you have to use xtables-addons along with iptables.  But it's not easy to get working correctly because of the versions of xtables-addons and iptables in the stable repos.  Instead I just ended up upgrading my router to Debian testing.  It was the easy way out.  That way everything is a new version and I got a nice shiny new 3.x kernel.  Once you get your system to recognize the TEE target and the --gateway option, you can add something like this to your iptables rules:

iptables -t mangle -A PREROUTING -j TEE --gateway x.x.x.x

(where x.x.x.x is the IP of the machine you want to receive the packets.)

Now that that's over, I can get back to configuring snort.  Any traffic coming into or out of my network through my router will also get copied over to snort for processing.  Yay!