I was thinking about port knocking the other day (yep, that’s how I roll) and while I consider it to be a valid security layer, it occurred to me that it would be pretty easy to set up a poor implementation of it that was susceptible to being gamed. Here’s how that thought process went.
Caveat: This is a proof of concept and has many points against it which I outline at the end of this post.
For the uninitiated, port knocking is a process whereby some port on a server can be fire-walled off until some pre-determined set of ports are ‘knocked’ on, and then the firewall can be reconfigured to open some other port. A practical example is a server where you need SSH access, but you don’t want to leave the SSH daemon running wide open to the world all the time. You can use a port knocking daemon like knockd, coupled with an IPTables firewall to protect that port. The normal configuration would be to have the SSH daemon running on some arbitrary port and have the firewall dropping connections to that port until a valid set of ports are knocked on, and then the IPTables would be rewritten, usually temporarily, to allow connections to the SSH port.
Continue reading “Defeating poor port knocking configurations”
Sysadmins have a love/hate relationship with logs. We spend hours and hours every day diving through them looking for clues about what happened that shouldn’t have, what didn’t happen that should have, what systems and people are actually doing, and gauging capacity for the future.
It’s one thing to look at one log for one particular issue; but some complex issues lead a merry chase through many logs or many servers which can get very complicated very fast. To ease that burden, all but the simplest of setups should employ some form of log centralization. Centralized logs are easier to access en masse and they’re easier to bring analytical tools to bear to pry out their secrets.
Continue reading “Centralizing logs with Papertrail”
Curl is one of those quintessential *nix tools that adheres beautifully to the “one tool, one task” philosophy.
curl exists to give us the ability to issue requests against web servers. As sysadmins we’re usually concerned with how the web server responds to requests rather than how the actual page renders so a CLI tool like
curl is quick and easy. It also lets us spoof things like user agents and referers in case we want to see how the web site responds to different browsers or different referers.
Let’s look at this site:
$ curl http://slumpedoverkeyboarddead.com | head
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<title>Slumped Over Keyboard Dead</title>
<meta name="description" content="That's how they'll find me one day..." />
<meta name="HandheldFriendly" content="True" />
Continue reading “Fun with Curl”