Aaron’s Worthless Words

Stretch at Packetlife has a lively little write-up on the Australian government’s attempt to implement a nation-wide web filtering service.

From Packetlife.net:

Setting aside the myriad of technical barriers to implementing such a system, the most obvious question is, “who decides what gets blocked?” When a corporation implements a web filter, it does so in accordance with corporate policy — policy that is set by the owner of the network. But the Internet doesn’t belong to any one entity, be it governmental or commercial, so such an authority simply doesn’t exist at this scale. In a very Orwellian sense, this filtering initiative appears to want to create that authority out of thin air.

I don’t know enough about the specifics down under to weigh in very heavily, but I would never support any service that filters web content from my house.

• Leave a comment... (0)

My friend Josh over at blindhog.net has found a collection of cheat sheet gems for the network dude(tte).  There’s sheets on BGP, OSPF, Subnetting, QoS, connector types, and more.  Check it out.

Cheat Sheets - Packetlife.net

• Leave a comment... (1)

GRE tunnels rock.  They are interfaces on a router that are used to “connect” to another router somewhere on your LAN, your WAN, the Internet, wherever.  The most popular use for them is for router-to-router VPNs.

I’ll let my friend Josh from blindhog.net show you how to do it.  He’s got a video on how to configure the tunnels, and another on how to set it up for VPN.

• Leave a comment... (0)

I’ve seen a thousand [tag]firewalls[/tag] in my time, and nearly all of them are poorly configured. The biggest culprit? No [tag]outbound[/tag] [tag]filtering[/tag]. I guess a lot of people think that firewalls are there to protect the network from the Internet, but that’s only part of it. The firewall is to protect every segment from every other segment — all segments both inbound and outbound.

I guess that way back in the day that was true. You had your well-behaved network behind a firewall, and the only threat was from the evil hackers of the Internet. That’s not true any more, though. What about viruses? Or spyware? You don’t want those things spreading out from your network, do you? Think about liability, too. If you run a corporate network and an employee starts illegally downloading stuff from Kazaa, the company is liable for that, and the first step is to block any unneeded traffic from getting out.

Forget that your workstation sits on the inside of the firewall and remember that the intern down in development has a machine there. You know — the guy who “learned all about computers” in school. Use your firewall to protect the Internet from him!

—-

The note: Outbound filtering doesn’t keep the badies out completely. One of the first rules on your list will be to allow all users to TCP/80 on any host so everyone can surf. Any worm worth its salt these days will use TCP/80 for all its communications to take advantage of that hole, so you need to keep your antivirus and antispyware software updated to protect yourself and everyone else.

• Leave a comment... (0)

I finally got around to looking into [tag]SNMP[/tag] v3 and was shocked at how easy it actually is. When I first looked up info on it so many moons ago, I saw table after tables of views and privilege levels and thought I would have to put in a billion hours getting it customized. I settled down and went through some Google results and found a blog post by Richard Bejtlich that shows the simplest of configurations. Works like a champ!

SNMP v3 gives you a few things that you’ll like. First of all, the transactions can be encrypted, so you don’t have to worry about people sniffing your traffic on the evil Internet. You also get username and password combos for authentication. Older versions use the community, which serves as a password. My buddy has a story about using the default communities on his cable modem to find upstream hosts, the using the same on his ISP’s network gear. That’s pretty lackluster security that could be hardened with v3.

This version of SNMP is very complicated, and the key to starting off is to forget about the views. Views make SNMP v3 ultra-powerful, but you don’t need them in a simple setup. Obviously, we all evolve, and you’ll probably use it later, but there’s no need to worry yourself to start.

Let’s do this, then. First, you need to define a v3 group and user/pass. Just something simple will do. Let’s choose a group name of “snmp-group” and a user of “snmp-user” with the password “user-pass”. Now all we have to do is configure the thing. I’m assuming you’re setting it up on a Cisco IOS device of some kind, but SNMP v3 has been available for quite a while on a lot of platforms and OSes.

snmp-server group snmp-group v3 auth
snmp-server user snmp-user snmp-group v3 auth md5 user-pass priv des56 encryption-key

Note that we’re using an MD5 hash for the password right now. If you have the right code, you can do DES56 encryption, but every version of [tag]IOS[/tag] that supports SNMP v3 also supports MD5.

That’s it, actually. By default, you have read-only access to the whole MIB tree. If you want to set up more granular access, you can look at views, but that’s beyond the scope here. I’m sure I’ll have an article about that later.

Let’s test our new setup with an snmpwalk. There’s some new flags you need to pass to use v3, but it’s pretty straightforward. “a” is for encyrption; “u” is for user; “A” is for password; “l” is for the authorization level (another advanced SNMP v3 topic).

snmpwalk -v 3 -a MD5 -u snmp-user -A user-pass -X encryption-key -l authPriv hostname .1

You should see a whole list of stuff scrolling by. If you don’t, check the username and password and try again. Let me know if you need any help getting it running.

—-

Here’s my usual note. If you still have your “snmp-server community” line configured, then v1 or v2c is still available. If you’re converting completely to v3, then just remove the community line. This will disable the old school versions and let you enjoy your encrypted goodness.

Also note that I’m not sure if Cacti or Nagios actually supports SNMP v3 encryption.  You’re on your own with that one.  If you decide to not use encryption, you can just take out the “priv” section of the user configuration to go with authentication only.

• Leave a comment... (0)

By default, most Cisco [tag]IOS[/tag] devices come configured to be accessed via telnet. This is probably fine for your house, but I really cringe when I run across corporate networks that use [tag]telnet[/tag] to access the devices. Telnet is old and out-dated and can be very dangerous. It’s in plain-text, which means that anyone who sees the packets can get your username and password. It also has no remote identification mechanism, so you can’t guarantee you’re talking to the device you think you are; you could be telnetting to a rogue device on your network without knowing it. [tag]SSH[/tag] gives you both things and more.

On IOS devices, SSH is encrypted based on host [tag]keys[/tag]. This means your stream cannot be read by anyone but you and the box. Since the [tag]encryption[/tag] is based on host keys, it guarantees that you are talking to the router or whatever you meant to. If you wind up on a rogue box or something, your SSH client tells you that the key the host provided isn’t the same as the one that was used the last time you SSHed over. Possibly the most important thing to know about SSH is that it is required for PCI or SarBox compliance where telnet is a no-no. Yes, I hate compliance, too, but what’s an admin gonna do?

So, how do we do this? Let’s work on the prerequisites first.

First of all, you have to be sure your IOS version actually supports it. Since there are two IOS naming standards, there’s not a magic number or letter to look for to know if yours is supported. I suspect that the letters “k9″ will guarantee that SSH is supported, but, if in doubt, the easiest thing to do is to look at the Cisco Software Advisor and look for a version that support “Secure Shell SSH Version 2″ (SSH version 1 is a terrible [tag]implementation[/tag] and should be avoided). Upgrade your box if needed.

The next prerequisite is pretty elementary: you simply have to add a domain name. You may have this configured already, but you need it to generate a host key. Here’s how.

ip domain-name your.domain.name

There’s another thing that is not really a prerequisite, but, in my mind, it is a wonderful thing to do. You should have a way to authenticate users instead of the telnet password/enable password thing. I mean where you put in a username and password and authenticate against some source somewhere. I recommend TACACS+ since it loves Cisco devices, but Radius or even local [tag]authentication[/tag] are fine. I’ll show you how to set up local authentication here since it’s the easiest thing to do here.

aaa new-model
username myuser password mypass
username myuser privilege 15

This is very simple, and I would never run it like this, but here’s what it means. The “aaa new-model” says to use the advanced authentication model to authenticate users. The default is to use local authentication, but it is fully customizable (this sounds like another article for later). The “username myuser password mypass” sets the password, duh! The last line sets your privilege level to 15, which is the same as getting into enabled mode. I suggest you set your users to other privilege levels and have everyone enables; it’s the same as logging into a Linux box and doing a sudo. NOTE: Try to log into the box from another window before you log off to make sure AAA is working. You may get locked out if you log out before testing!

Alright, now for the SSH part. First we need to generate a key.

cryto key generate rsa

It’ll ask you for the length. The standard is 2048, so just type that in for now. You can always re-generate your keys later. That’s actually all you need to configure to enable SSH. Yes, I realize 95% of the configure time is prerequisites. It’s comical, really.

After you get the key generated, open another window and try to SSH to it from your local SSH client or Linux box. It should ask if you want to add the key to the key ring or known_hosts file. Just say yes so you can track the keys in the future (remember the remote identification thing?). If it works, you’re golden. If not, check your firewall or AAA for problems.

Done, right? Wrong. Try to telnet over to your box — it’s still available. We should turn off everything but SSH. It’s not hard. The lines here will turn off all access to the CLI on the box except for SSH.

line vty 0 15
transport input ssh

One more thing and we’re done. You should set your SSH version to 2 instead of the default negotiate. This will make sure you’re not running the vulnerable and exploitable SSH version 1.

ip ssh version 2

The configuration is done, and we all still have all our toes, but what would a Cisco article be without a show commands. Here’s how to list all the settings for SSH on your box.

show ip ssh

Don’t you dare complain that this was hard because it wasn’t. Leave a comment or drop me an email if you have any questions or problems. I’ll be glad to help.

• Leave a comment... (0)

I was talking to a coworker the other day about setting up his home network more securely.  “No problem,” I said, and we started listing devices on his network to see what we needed to do.  I was pretty surprised that he had so many things on his network.  I mean, I was quite amazed.  He had all sorts of stuff — from gaming consoles to guest machines to special-purpose Linux boxes to sewing machines.  A sewing machine?  Yes, a sewing machine.

We beat out a pretty good function list for his to segment everything out, but his huge list of stuff got me thinking about the things that are network-ready nowadays.  You can get refrigerators, exercise bikes, and pet feeders.  Who knows how to secure a refrigerator?  I would think that nobody really does, so what’s the best thing you can do to protect yourself from your refrigerator?  Good question.

If you step back and take another look at it, you could definitely consider those hosts to be untrusted.  You may or may not have any management on them, and they go about doing their thing without your intervention.  What else is an untrusted host?  How about your buddies who bring their laptops over?  The same thing applies to them, too, so why not?

Segmentation is a really good start with security, especially if you don’t know exactly what a box does, so let’s start there.  If you have a bunch of stuff that’s not traditionally a network device, you should first think about making a network segment for those guys.  If you have a Linux box as a firewall/router, you can simply add a NIC to it and voila!  New network segment for untrusted devices.  Lock that puppy down and you should be good.  In my setup at home, that segment has its own SSID for guests to connect to and contains my Wii.  The only thing that hosts have access to is HTTP and HTTPS and all access to my other networks is denied completely.  This protects my machine from them and doesn’t let them go running amok.

—-

My usual note:  You should probably have separate segments for untrusted devices, trusted workstations like laptops and PCs, and servers such as file servers.  If you want to be really anal about stuff, you should get a managed switch that supports private VLANs so hosts on the same network can’t get to each other.  That sounds like another article to me, though.

• Leave a comment... (0)

Separation of function is another important security concept that people often overlook.  It can mean that a single person is only responsible for one part of a process.  Or it can mean that one server only does one function.  Or it can mean that one network is used for servers of one type.  Or it can mean that a whole data center is for only one production and not development.  It depends on your scope and your point of view.

What does it give you?  Think about it for a second.

• If a server is a web server and not a database server, then you don’t have to open up any type of access from the Internet to the database server.  If you had them both on one box and the webserver was owned, guess what?  The database server is owned, too.
• If you have a network segment that’s only for web servers and one of them gets owned, then they only have access to other web servers.  If you had web servers and database servers on the same network, a compromise of a web server has direct access to the database server.
• If a developer can only write code and someone else deploys it or tests it, then he can’t deploy code without telling anyone or deploy code that emails credit card numbers to himself.
• If a data center blows up but contains only development servers, you don’t lose any production time since all those boxes are on the other side of town.

You can see there are some advantages, but everything has a downside.  In this case, you have to pay for the extra whatever — be it a new server, new firewall, new data center, new tester.  The advantages, though, can often outweigh the costs since you have a while mess more controls in in place.

NOTE:  Most or all compliance programs like PCI or SarBox can REQUIRE separation of function on a lot of areas like server function separation, and developer/tester/deployer separation.

• Leave a comment... (0)

A few months ago, a friend of mine told me about the concept of port knocking, where you send packets to a server on certain ports to authenticate access to the box. A daemon running on your server detects the sequence of packets that you send and runs a script (usually IPtables commands), waits a certain amount of time, then runs another script (usually to take the IPtables commands out). This seems like a good way to get access to your home firewall from anywhere without having to open up access to the whole Internet.

To set it up, you have to install knock, which is the daemon that listens to the port knocking. Just use yum or apt-get to install it and you’ll wind up with the configuration file in /etc/knockd.conf. This is where you set up one or more knock sequences to do what you want. I won’t go into the internals of how it works or how you should set it up but I will go into a few examples.

I use port knocking on my home network to protect administrative access to everything on the network. I wrote a custom IPtables script that, when activated, open access from my IP on the wireless network to SSH (TCP/22) on my firewall, file server, access point, and switch. After 30 seconds, another script runs, and those rules are removed. Here’s an example of a config file that opens up SSH when you hit ports 1234, 5678, 9876, and 5432. After 30 seconds, it kills the rule.

[options]
logfile = /var/log/knockd.log

[openssh]
sequence = 1234, 5678, 9876, 5432
seq_timeout = 5
tcpflags = syn
start_command = -A INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT
cmd_timeout = 30
stop_command = -D INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT

So, how do you generate these packets? On my CentOS boxes, you get the knock command which is the port knocking client. On Windows, I use KnockKnock. I have no clue about Macs, but there are lots and lots of clients out there, so just look around and I’m sure you’ll find one.

• Leave a comment... (0)

The hardest part of messing with firewall configs is knowing what is going to lock you out of the firewall itself.  It doesn’t to me very often, but I’ve been doing firewalls for 10 years now.  I was thinking about my own IPtables implementation at home and realized that I do most of my tweaking remotely.  If I were to fat-finger something, I’d have to get on the console, and everything would be down until then.  I don’t need a lot of uptime at my house, but I really can’t stand downtime, but I digress.

Since I use IPtables at home, I took a look at some of the inner workings and found the “save” option.  This writes your running configuration to a file /etc/sysconfig/iptables.  Since IPtables doesn’t write this file automatically, you can use this mechanism to keep a known-good copy on disk.  So how?  You can use this command to restore the good config.

iptables-restore < /etc/sysconfig/iptables

If you stick this command in root’s cron to run every 15 minutes, you can make any changes you want, and, if you hose it up, the known good config will be restored in a few minutes.  When you make changes and everything seems fine, you just do a “/etc/init.d/iptables save”, and your new config is saved off for later.

By the way, I use “iptables-restore” to make any changes.  I have a file that I make changes to and then use the syntax above to apply it.  The command actually flushes all the tables and puts the config in the file back, so you don’t have to remove any rules from memory if they conflict with new rules.  Remember that order is important when configuring IPtables rules.

• Leave a comment... (0)