An assortment of indigestible things

Category: networking

Using a Response Policy Zone with malwaredomains

Stop signThe lovely people at RiskAnalytics provide lists of domains known to serve malware at http://www.malwaredomains.com/. It makes these available in several formats including DNS zone files. They don’t even charge for the service which is, frankly, awesome!

Many people configure their DNS servers so that they spoof the zone for each domain such that traffic is redirected to 127.0.0.1 (i.e. your own machine). This effectively stops hosts on that network from connecting to those zones and downloading unpleasant stuff. However, if you’re running a local webserver, say for development purposes, things can get confusing very quickly!

An alternative is using a DNS Response Policy Zone. This requires BIND version 9.8 or greater (or another DNS server that supports RPZ). RPZs are much more flexible than the approach above because they give us finer control over what we want the DNS server to tell the client. I have taken the approach that returning NXDOMAIN is the cleanest way of blocking traffic to these domains because a web browser will immediately give up on receiving that response. There’s no need to worry that a local webserver might interfere with domain blocking.

Selectively blocking Samsung TVs’ network access

Old television

This TV probably wasn’t spying on you.

You may have read in the recent Wikileaks exposé that the CIA developed the capability of making Samsung TVs spy on their unsuspecting users. While this hack requires physical access (a specially crafted USB stick must be plugged into the telly), it got me thinking about the network traffic generated by smart TVs. I’ve already blocked a few domains that my unit connects to, and this seems like a good time to share my work.

Getting the Linksys X3500 to log to a remote syslog server

It’s always useful to get your network gear to send their logs somewhere else in case they die, reboot, or go on fire. In a domestic setting this can be very useful if you have some problems with the stability of your link. However, in the case of the X3500, Linksys’s knowledge base says

11.Does the X3500 support transmission of log information to a log server?

No, the Linksys X3500 does not support transmission of log information to a log server.

Welllll…. that’s kind of true, in that there’s no option to enable it, so I suppose it’s not supported. However, it can be done. Linksys would probably say that this will invalidate your warranty, set your hair on fire and poison the groundwater, but a big fat ‘muh’ to them.

How to get line stats out of a Linksys X3500

My Linksys X3500 (complete with muddy paw-prints)

My Linksys X3500 (complete with muddy paw-prints)

The Linksys X3500 is, as the manufacturer would have it, a very capable device indeed. I won’t bore you with the details because, if you’re reading this, you’ve probably already got one. If that’s the case, you’ll know that (like so much consumer networking kit) the management interface leaves a great deal to be desired: it’s buggy, slow, unreliable, and has a penchant for dropping your connection when you make changes. What’s more, Linksys hasn’t provided updated firmware for over six months, and for such a new device that’s kind of worrying. But that’s a rant for another day.

Getting useful information out of Intel NICs under Windows via SNMP

For a ‘lifer’ Unix engineer like me, trying to diagnose subtle problems on a Windows box can be very frustrating. You know the data is in there somewhere, but getting it out can be very tricky. Recently I’ve had a problem with a 2008R2 server and I needed to know the error statistics on each of its many NICs. Most of them are made by Intel, which made things a bit easier, and had the side-effect of revealing data for a couple of Broadcom NICs too.

Powered by WordPress & Theme by Anders Norén