Linux Security Series - Locking Down Logins

So, here we are in another installment of my Linux Security Series. To catch up, read the intro post, and check out the other articles.

So, as you should know by now, you should never login as root. You should login as a regular user, and then use sudo to run commands, or su to root.

The real benefit of using su/do is disallowing root logins. Here is a little exert of the logs of a server I run on the internets:
Oct 14 20:31:59 Tomahawk sshd[82597]: error: PAM: authentication error for root from 188-193-191-72-dynip.superkabel.de
Oct 14 20:32:33 Tomahawk sshd[82600]: error: PAM: authentication error for root from s01060000c5ca5b32.su.shawcable.net
Oct 14 20:33:19 Tomahawk sshd[82616]: error: PAM: authentication error for root from 58.26.82.163
Oct 14 20:33:54 Tomahawk sshd[82619]: error: PAM: authentication error for root from mail.act.by
Oct 14 20:34:34 Tomahawk sshd[82622]: error: PAM: authentication error for root from 115.168.35.219
Oct 14 20:35:20 Tomahawk sshd[82628]: error: PAM: authentication error for root from p5098cd41.dip0.t-ipconnect.de
Oct 14 20:35:54 Tomahawk sshd[82631]: error: PAM: authentication error for root from 75-148-164-97-houston.hfc.comcastbusiness.net
Oct 14 20:36:34 Tomahawk sshd[82634]: error: PAM: authentication error for root from mulligan.softspike.org
Oct 14 20:37:23 Tomahawk sshd[82639]: error: PAM: authentication error for root from 69.red-80-33-156.staticip.rima-tde.net
Oct 14 20:38:04 Tomahawk sshd[82642]: error: PAM: authentication error for root from 119.62.128.19
Oct 14 20:38:39 Tomahawk sshd[82645]: error: PAM: authentication error for root from 221.7.58.36
Oct 14 20:39:22 Tomahawk sshd[82648]: error: PAM: authentication error for root from 122.224.128.197
Oct 14 20:40:06 Tomahawk sshd[82654]: error: PAM: authentication error for root from 123.147.144.45
Oct 14 20:40:48 Tomahawk sshd[82657]: error: PAM: authentication error for root from 202.97.0.76
Oct 14 20:41:27 Tomahawk sshd[82660]: error: PAM: authentication error for root from 220.194.66.56
Oct 14 20:41:48 Tomahawk sshd[82663]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:49 Tomahawk sshd[82665]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:50 Tomahawk sshd[82667]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:52 Tomahawk sshd[82669]: Invalid user wawa from 84.1.106.142
Oct 14 20:41:53 Tomahawk sshd[82671]: Invalid user mail from 84.1.106.142
Oct 14 20:41:54 Tomahawk sshd[82673]: Invalid user mail from 84.1.106.142
Oct 14 20:41:56 Tomahawk sshd[82675]: Invalid user mail from 84.1.106.142
Oct 14 20:41:57 Tomahawk sshd[82677]: Invalid user mail from 84.1.106.142
Oct 14 20:41:58 Tomahawk sshd[82679]: Invalid user local from 84.1.106.142
Oct 14 20:42:00 Tomahawk sshd[82681]: Invalid user local from 84.1.106.142
Oct 14 20:42:01 Tomahawk sshd[82683]: Invalid user local from 84.1.106.142
Oct 14 20:42:02 Tomahawk sshd[82685]: Invalid user local from 84.1.106.142
Oct 14 20:42:05 Tomahawk sshd[82687]: error: PAM: authentication error for root from 211.143.240.6

Lots of failed login attempts for root, as well as some other common accounts (mail and local, but I've also seen lots for admin, user, test, webmaster, etc.) A friend checked his server, and saw tons of services, as well as common first and last names. These are all attempts to break into your system. Most are simply bots, that try and connect with SSH using a massive list of common usernames and passwords. If you look at the times, many are with a few seconds of each other. Almost any box on the internet with ssh running on port 22 is being bombarded with these every day.

Now, if you have root login over SSH disabled, and you don't have a common username, you're blocking the vast majority of these attempts. Great you think, now how do I do that?

Well, you could lookup how to do it on your OS (if this dosen't), but here's how to disable root logins over SSH on many Linux/Unix distros.

1) Before you continue, be sure that you have a non-root account that can login with, and either use sudo or su to become root. Without this, you will be locked out of your system. It's not too bad if you're sitting at your desktop, but it's a real pain if it's a system locked up in a datacenter somewhere. I've driven to the datacenter at 7PM before (to fix a firewall I screwed up, luckily it was only a 30 min drive), and it's not the most fun way to spend an afternoon.

Much of this process could be distribution dependent, so check your distro documentation. The useradd command is available on most (all?) linux/unix systems. You can also use any GUI tools your particular linux distribution uses. You may also want to add your user to the wheel group, or an admin or other group if your distribution has it. More details on that later.

2) Find your sshd_config file. It's usually in /etc/ssh/ or /usr/local/etc/ssh folders. If you're having trouble, try doing locate sshd_config

3) Edit the file with your favorite text editor. I'd recommend nano if you're not familiar with one. nano /etc/ssh/ssh_config

4) Search the file for "PermitRootLogin" (Ctrl+W on nano). If it's there, be sure it's not commented out (remove the leading '#' if present), and put "no" there. If you can't find it, add it in somewhere. Put it at the bottom of you don't know where else to put it.

5) Close and save the file. It's Ctrl+X on nano, then Y for saving, then press enter to save it as the same filename.

6) Restart OpenSSH (the SSH Server). Again, this is somewhat OS dependent. On Redhat derrived OS's (Redhat, Fedora, CentOS, Adios, etc.), you can simply do service sshd restart. Other linuxes, you'll probably do /etc/init.d/ssh restart. On Arch linux and FreeBSD, it's /etc/rc.d/sshd restart.

Now, try to login as "root" over ssh. It shouldn't allow it, even with the correct password.


Some other ideas for securing your system:
1) Only allow specific users to use su.
Richard Stallman apparently has no idea about being a sysadmin (read the bottom). In FreeBSD, for a user to be able so su to root, he must be a member of the wheel group. Linux does not have that restriction. The easiest way to do this is to change the permissions for the /bin/su command to only let members of wheel or some other group execute it.

chgrp wheel /bin/su
chmod 550 /bin/su

2) Use sudo for any users that need to run only a few things as root. Check out my other post on su and sudo. It's very robust, and there are lots of guides on how to use it. The idea here is very few users need to have full root access to a system. If you prevent all other users from becoming root, then you don't need to worry as much. On a well configured system, you should be able to give out your root password and not have it affect security at all (assuming your hardware is secured).

3) Secure the terminal. Physical security is a must for any security on a system. But, without absolute physical security (if there even is such a thing), you should take some steps to make sure your system is a little more secure from someone sitting at the terminal. I'll go into this more in a later post.

Linux Security Series - Su and Sudo

So, if you read my Intro post, you'll know that this is tutorial for the novice linux user, not experts. Also, this article has been in the works for a long time, and I'm finally getting around to finishing/posting it.

This all started with my roommate. He recently got the root password to a linux server to use it. As in, the person sent him the root password, and didn't make him a user account or anything. I've been really into linux/unix since about 2003, and I quickly learned that logging in as root is a bad idea. If you mistype one thing, you can quickly hose your system. Once, I was using the root account (in a way I'll explain later), and I accidentally executed a rm -rf /*. This will delete everything on your computer, even if it's read only. About a second later, I realized what I had done (I meant to do ./*), and hit Ctrl+C to stop it. I did an ls to see what the files looked like, and I got bash: ls: command not found! Oh crap, just deleted lots of important files. Turns out pwd had been deleted also. Anyway, I had to reinstall my OS, and luckily my important files didn't get deleted before I stopped it. And THAT is why you don't want to be root unless you have to!

So, if you don't log in as root, then how do you edit system files/settings, etc? You use the nifty commands su and sudo. Now, If you're a linux/unix user, then you're probably aware of what these commands do, but for those of you who don't: su is short for "substitute use" or "switch user". It allows you to become another user, usually root. When you run su user, and you type in the password of the user you're trying to become. Then BAM! (imagine Emeril Lagasse there), you've got a shell, almost exactly like that user would if they logged in. If you don't specify a user, root is assumed. So, you login as a normal user, do your work, then when you have to do something that requires root privileges, you do su for that part.

Now, what's this sudo I keep mentioning? Well, it's short for (technically, I guess it's not short for, but the same length as) "su do". It's like su, except it is used for running a single command. This makes it much more convenient when you need to run a single command (like to edit a config file), but sudo is much more that that! The biggest advantage of sudo over su, is the logging it provides, as well as the security options it gives a sysadmin.

With sudo, you can specify who can run what commands on which computers. You can even specify what users these commands are run as. You can also specify if a user needs to enter their password or not, and if so, how long before they need to enter it again (if you're running multiple commands at once). Any time someone runs sudo, it gets logged. Who ran the command, what terminal they were on, what command they ran, and what time it was. For all the details check out the sudo site, linked above.

In a later article, I'll detail why you should use sudo, and how to lock down a linux system in regards to using sudo.

IPTables "Stealth" Scan Detection

Many of you probably know about port scanning. It's a very simple process, where essentially you attempt to to make a connection on several ports of several machines. If the port is closed, a reset is returned. If the port is open, a SYN+ACK is returned.

Now, there are some other types of scans, such as a FIN scan, Xmas Tree scan, and a NULL scan. These basically work on the same principals of a SYN (normal) scan, but using some different TCP flags (ones that should never be seen in valid TCP connections).

If you'd like, read up on the different types of scans here, which is also a good site to determine what type of reply you want to give the scanning host. It also shows how to perform the scans using NMap.

So, most of the time, you want to just drop invalid packets, since the easiest way to deal with them is not to. However, you may wish to use REJECT here, since what the host does and does not return is part of the data collected. Being able to decide what to return could give you an edge over an attacker. If you return tcp-resets, then you can make an attacker (or more likely a bot) think that all the ports on the host are closed. Different operating systems also respond differently to the various stealth scans, so be mindful of that as well.


I wrote some simple firewall rules to detect, log, and block (either with a tcp-reset or just dropping the packet entirly. This script was made to run on top of an existng firewall.

## IPTables rules for detecting and blocking several different scans
## By Drew Tingen GlimpseIntoEntropy.Blogspot.com
## NOTE: Please understand the use of REJECT/DROP
## NOTE2: You may want to mirror the FORWARD rules to INPUT

## Note on Rule Order - since these are Inserts (designed to be easily plugged into
## an existing iptables config), the packet actions are above the logging action.
## If you put these at the top of a config, and change the -I to -A, reverse the order
## of the rules for logging to work properly

## TCP Null Scan
### Action for packets
### use REJECT option to make port look closed. Use drop for open/stealth
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j DROP
### Detect and log
iptables -I FORWARD -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "TCP Null Scan"


## TCP Fin Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j DROP
### Detect and Log
iptables -I FORWARD -p tcp --tcp-flags FIN,SYN FIN -m state --state NEW,INVALID -j LOG --log-prefix "TCP FIN Scan"


## TCP Xmas Tree Scan
### Action for packets
iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j REJECT --reject-with tcp-reset
#iptables -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j DROP
### Detect and Log
iptalbes -I FORWARD -p tcp --tcp-flags ALL URG,PSH,FIN -j LOG --log-prefix "Xmas Tree Scan"


Also - if someone wants these rules for OpenBSD's pf, those can be easily created.

"Hacking" out of a stateless firewall

So, when I was playing around in the kernel working on my previous entry, I found /proc/sys/net/ipv4/ip_local_port_range. The default value in my Adios sandbox VM is "32768 61000".

This is the range of ports that the kernel's TCP/IP stack will chose for the SOURCE port for new outgoing connections. That's alright, but it'd be cool if I could do something useful with it. Well, it became cool with the firewall rule my instructor wrote in my iptables class tonight.

iptables -I INPUT -i eth1 -p tcp --dport 22 -j ACCEPT #Accept incoming with a dest port of 22 - tcp
iptables -I OUTPUT -o eth1 -p tcp --sport 22 -j ACCEPT #Accept outgoing with a src port of 22 - tcp

Well, this is all well and good, a basic, stateless firewall to allow SSH clients to connect to the server.

But, it got me thinking...if I could compromise that host, then set ip_local_port_range to just port 22, I could get out, to any host/service I wanted.

So, what to do....start up a couple of VM's and try, of course!

Turns out, it actually worked. I set ip_local_port_range to "22 23" to use port 22. Screenshots to follow.


When could this be exploited? If you had a server in a DMZ. The goal of the DMZ is to isolate it from the rest of the network (workstations and internal servers). If you were using stateless filtering on the firewall from the DMZ into the enterprise network, this method could bypass that firewall. The rule you put in place to allow internal users to connect to the server, and for the server to respond, becomes the attack vector. This doesn't have to be SSH, but any port open in both directions so the clients can connect to the server - HTTP, SMTP, IMAP, POP, doesn't matter.

Note: I know, if the firewall is on the host it's useless, just disable the firewall. But if the firewall were on another machine that you can't/haven't compromised, the it comes into play. No enterprise DMZ firewall is running on their web server....I'd hope...


So, what can be done to prevent this? Use stateful packet filtering is the best. At the very least, you could add rules to not allow packets with a SYN and no ACK flag out of your DMZ. This would still leave a similar vector open for UDP attacks, and using a stateful firewall, where the states are maintained on the firewall, and not just the host, would be more secure.

Screenshots:

SSH:


HTTP connection using wget:


SSH connection in netstat, notice the source and destination port are both 22:



Addition:
The "better" rules for stateless filtering is as follows:

iptables -I OUTPUT -o eth1 -p tcp --sport 22 -j ACCEPT
iptables -I OUTPUT -o eth1 -p tcp --sport 22 --tcp-flags SYN,ACK SYN -j DROP

That second rule will not allow new connections out. If a packet has the SYN flag set without the ACK flag set, it drops it. The -I means that the rule will be inserted above the previous, and thus will match first and drop the packets.

Sending a packet to 127.0.0.1

I was sitting in my iptables class the other day, and was watctching our instructor write one of the basic firewall rules that is written every time. It is to allow all traffic in and out on the loopback.

This got me thinking - they were doing no other checks on source/dest ip at all. Pretty much every other firewall how-to I've seen does the same thing, allow loopback regardless.

Now, imagine that we took a linux box, and instead of having the loopback address being 127.0.0.1, make it something else, like 7.7.7.7 (sorry DoD). Then, add a route to 127.0.0.1, with the gateway being the remote host/router you're trying to attack.

The idea is that if you send a packet to 127.0.0.1, it will not go to the lo interface, but instead out to the host you are trying to attack. When the host relieves the packet, it would, theoretically "route" the packet to the loopback interface.

Wow, we can send a packet to the loopback address. What's the point? Say you're running a web server, and also have mysqld running on it. The smart thing to do is make mysql only listen on 127.0.0.1, so that outside users cannot access it. If we can send a packet to the host, and have it route to 127.0.0.1, we could potentially access it from the outside.

The problems:
1) This "attack" could be thwarted by a properly configured firewall.
2) You could only "attack" a host on the same subnet, since there is no way a packet destined for 127.0.0.1 would traverse a router.
3) The big one: the linux ipv4 routing implementation has sanity checks that reject (and logs) all packets with a source or destination in the 127/8 subnet block. They are "martian" packets. Check in the kernel, in net/ipv4/route.c

I'm going to have to do some more research on this topic, but I'd guess that no (modern) kernel's IP implementation would be fooled by this. I've been having problems testing, because the routing engine isn't sending packets to 127/8 addresses out over the wire. I was working on hacking the kernel to allow this for the attacker machine, but I got tired of looking though lot's of C code that I can't really understand.

Oh well, better luck next time.


On another, semi-related not:
Every address in the 127/8 block is a loopback address. You can set services to listen on 127.0.0.2, and you have to connect to them at that ip. With this, you can set services to listen on different loopback ip's, but the same port. Handy for things like running multiple we apps on the same box.

Network Manager/DBus Scripting

At my University, the wireless networks are secured with Perfigo/Cisco Clean Access. This is all well and good, but it gets annoying having to launch a web browser to sign into the captive portal each time I connect to the network. It's made even more annoying by the fact that many programs (liferea, pidgen, Thunderbird, etc.) try to connect before I login, and either end up connecting to the captive portal, or getting blocked. Either way, it's annoying.

I'm now looking into using DBus and a script/program to wait 'til I connect to one of a couple of wireless networks, then automatically authenticate using the captive portal for me. I'm still researching, but it seems that Network Manager (gnome network connection management applet) has DBus interface, like most gui programs these days. After a quick peak around my system, I didn't see it registered to DBus, but I don't really know what I'm doing yet.

I'm thinking about writing the script in Python, as my first real attempt at useful python code (other than my vPython work in physics lab 3+ years ago.) We'll see how it goes.


As a side note: I'm quite tired of network manager applet for many reasons, and am looking for a decent replacement. Any suggestions?

Apple, Phones, and Telecom - We're getting F'd Over

Alright, I was just reading this article, and it ramped up my hatred of Apple again. For you Apple fanboys, try to stick around, because I'm going to get into some other stuff after the Apple bashing.

Apple really needs to wake up. Or get sued like Microsoft did. Everything they do is designed not to play well with others. If I wanted to use an iPhone/iTouch on Linux, I'd HAVE to jailbreak it. Apple spends too much time making sure they people can only do things their way. You can be different, only if you're the different Apple wants you to be. Reminds me of liberals and their open-mindness. But I digress - this is not, nor is it ever going to be, a political blog.

Which brings me to phones, and telecom in general. The iPhone is pretty decent hardware, I'll admit it. But, as a phone, it was, until recently, lacking some things that even my el-cheapo LG has. Like recording video. And sending picture/video messages. I have no use for the picture messaging, but it's a pretty basic feature in phones these days - Apple should have gotten it right the first time.

Now, the biggest problem with the iPhone (and most phones) is not the hardware or software that is restricting features, but the carriers. Phone carriers are so interested in making money with their extra features and such, they're really screwing over the customer. Same thing goes for traditional telecoms. Like Time-Warner trying to charge based on usage. The lack of real competition in the market has destroyed any hope of moving forward. With the Ma-Bell's controlling nearly all of the long-haul connections in the country, it's impossible for anyone to compete. And now the Bells are starting to merge back together.

So, what's my dream? Not quite as epic as MLK's, but I have a dream, that one day, this nation will connect together. That data will move as freely around the country, with no priority for those with the most money or power. That everyone will be able to access the interwebs at blinding speed. Alright, enough of this.

I think that the way current teleco's manage the internet is going to hurt the country. We need Internet to be cheap and readily available. I was going to say like electricity, but Enron proved that industry isn't all fun and games either. How to get there, I'm not sure. I'm not usually one for government intervention, but I think if the government did it right, it could work brilliantly. Problem is, once the government gets their hands on it, they'll try to regulate it to death, and use it to bribe the States into doing something (Think Federal Highway funds...)

So, that's my rant. It's late, so I hope it makes sense.

Linux Disk Useage

So, my roommate was hunting for a large file/directory on his linux box today, and the way do to it is rather non-obvious.

You want to us the du or disk usage command. If you just use the command, you'll get a recursive list of directories and their sized, probably not what you want. If you want the size of the directory you are in, try du -sh - it'll simply print the size of all the files in the current directory.

More useful, however, is to list the subdirectories, and how big they are. For this, you want the --max-depth= option. The -s option is summarize, it's equivalent to --max-depth=0. Try max depth of 1 or 2, or even higher if you need.

Here is a sample from my computer:

user@computer:~/Videos$ du -sh
73G .

So the Videos folder in my home directory has 73GB worth of files in it. Alright, let's see more:

user@computer:~/Videos$ du -h --max-depth=1
21G ./Movies
53G ./TV Shows
73G .

Well, apparently I have 21GB in the Movies directory and 53GB in the TV Shows directory. Let's see a little more.

user@computer:~/Videos$ du -h --max-depth=2
6.6G ./Movies/Forgetting Sarah Marshall
4.4G ./Movies/Get Smart
4.4G ./Movies/How To Lose Friends And Alienate People
4.5G ./Movies/WALL-E
701M ./Movies/Zach and Miri
21G ./Movies
6.3G ./TV Shows/Big Bang Theory
15G ./TV Shows/Chuck
14G ./TV Shows/Get Smart
19G ./TV Shows/The Office
53G ./TV Shows
73G .

There you go, now you know what movies and tv show's I've got on my computer. Of course, it's all legal backups of stuff I own ;)

Redhat Academy - Making Life Easier

When I took the Red Hat Academy courses a while back, I knew enough about linux/unix to make life a lot easier on myself. Here is what I recommend for students doing RHA courses, all the commands are done in the terminal:

1) Add /sbin and /usr/sbin to the path variable. This will let you run commands like mount and fdisk without typing /sbin/fdisk
Open your bash profile in a text editor like nano
nano ~/.bash_profile

Find the line that says:
PATH=$PATH:$HOME/bin
And add to the end of it and make it look like this:
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
and log out and back in to apply it.

2) Add your user account to sudoers so you can use sudo without a password.
open the /etc/sudoers file in a text editor (linux guru's - I know it's not the best way to do it, but I'm not teaching vi here)
nano /etc/sudoers
At the end of the file, add the following line:
yourusername ALL=(ALL) NOPASSWD: ALL
then save and exit.

You can now type sudo x and it will run x as root. You can also do sudo su - and it will make you root, without entering a password.

That's the two biggies for now - if I think of anything else, I'll post it. If you have any suggestions or ideas, post a comment and I'll see what I can do.

And no requests for me to do your work or anything like that. Not happening.

Addition: The biggest problems that we had when I took the course was dealing with the ipsec VPN. Basically, you had to use VMWare with a bridged network connection, and you had to forward/open ports in any NAT/firewall between you and the server. I recommended OpenVPN as an SSL-based alternative VPN. It has no problems with most firewall/NAT setups, and can be run as a layer 2 or 3 VPN. There are also lots of authentication options, as well as rolling your own. I discussed this VPN option with our instructor, and I think he liked the idea. He wanted me to setup a Fedora server (VM) to test/demo it with, and I didn't have time to mess with it then (and I really dislike Fedora, for reasons I won't get into here). I've basically forgotten about it since then. If any Red Hat administrators would like my help/ideas on this, feel free to contact me. I'd be glad to help.

Linux Security Series - Intro

Alright, I've decided to write a series of how-to articles on linux security. This will be targeted to the linux novice. I'll explain what you want to do, why you would want to do it, and then walk you through how to do it for common distributions.

This will be a work in progress, as I'm going to be doing walk-throughs for multiple distributions. I may have videos for some of the more complicated setups.

Below is a list of the tutorials so far. I'll keep this updated as new ones are added. Or check out the "Linux Security Series" tag.

Tutorials:
1) Su and Sudo
2) Locking Down Logins

If you have any suggestions or tutorials you'd like to see, then make a comment on this post.

ARRL Field Day 2009

It's been a while since I updated my "blog", so here's something new for all 2 or 3 of the people that read this.

I recently got my amateur radio license. I'm a Technician class, so I can't operate HF, which lets you talk long range.

This weekend, I went out to an ARRL field day event in Greenville, NC. It was hosted by the Brightleaf Amateur Radio Club (BARC), call sign W4AMC. I ended up working throught the night, from about 10PM to 6AM, local time. In fact, if you made any phone (voice) contacts with W4AMC between 1AM and 6AM, you were talking to me :).

I was operating on 20 Meters and 80 Meters, and probably made close to 100 QSO's over the night. Most of the night I was talking to the southeast, from Florida and Georgia, all the way over to Texas. I also made some QSO's with Minnesota, the Dakotas, and that region. I heard California several times. I even talked to someone in California on 20 meters, but the signal was pretty bad. He got my call sign, but couldn't get my report (3ANC), even after several attempts.

There was some other stuff there that was pretty cool. There was someone who was working morse code. He had a machine to do the standard exchange (call sign and report), but he could copy it and key it by hand, apparently very well. One person was working digital, essentially Teletype over radio. It also used about 1/20th the bandwidth of a voice channel. Another person was using IP over radio, and was sending e-mails.

Also, there was a rig setup to communicate over amateur radio satellites. It was pretty cool, it would track the satellites as they cross the sky. You also have to account for the doppler shift when communicating with the satellite.

Improving your Wireless Security

So, you have 802.11x in your castle/home/condo/apartment/dorm room/cubicle/cardboard box and you want to secure it better? One of the best options (that's compatible with Windows without installing any additional software) is to use WPA2.

So, you have a RADIUS server and a wireless Access Point (almost any will do)? Why not use WPA2-Enterprise and require users to login with a username/password to access your wireless! If you're running pfsense, you can install the FreeRADIUS server for that, so you don't need another computer running all the time (you still do if you want to be cool, but that's for another post).

I'm still trying to set it up using my pfSense box, and a Fon running DD-WRT. Having some problems with it, not exactly sure what the problem is (don't think the authentication is getting to the radius server, but I'm not sure).

Once I get it working, I'll post a mini how-to, as well as all the options you can use.

Test your AC/Heat

So, the heat/AC in our apartment is no working right now. Luckily it's still cool at night, so we've made our own AC using a fan in front of the screen door.

Anyway - I tried to test it out today, and figured the first thing I should do (other than the basic "check the breaker, play with the thermostat, etc" was to bypass the thermostat, and try to control the HVAC unit directly. After some quick googling (love that verb) and reading, I found some info (linked below). Basically, there are 4 wires in a normal system (non-heat-pump). The red wire provides 24 VAC. The Green wire controls the relay for the blower fan. Yellow wire is for the AC compressor. White wire is for the Heater.

Before you do any of this you need to turn off the breaker to the HVAC unit. Be safe, and don't blame me if you get hurt. To bypass the thermostat, simply connect the red wire to the green wire (I used some rolled up tin foil). This should turn on the fan, and you'll feel air coming out of the registers. For heat and AC, simply tie the red wire to the yellow or white wire. Again, don't do this with the power on. And I wouldn't leave the system connected like this, it will cause your AC/Heat to run 24/7, without turning off at any temp. Although it could be useful if I ever get a Crestron system in my home. Connect it to the relays on the Crestron processor, (relatively) poor man's HVAC automation!


My source, and lots good HVAC info:
http://highperformancehvac.com/thermostat-wiring-colors.html