Thursday, May 11, 2006

Iptables again

During the last 3-4 days, I've been playing with Iptables:

1. I'm having an issue where my SSH sessions to time out. Last night, I flushed the firewall rules and left the firewall bare of rules for the night while leaving a term logged in via SSH. The session still timed out but I don't know if this is an eventual time out or something related to SSH. I don't have any rulesets related to SSH in my Iptables file (with the exception of allowing all SSH).

2. I've been testing some firewall log parsers, namely fwlogwatch and wflogs. Both are nice, but wflogs has more configuration options. Both supposedly parse Snort logs, but I haven't been able to do this with either tool. Both tools are out-dated with no activity to either project in the last few years.

3. The ##slackware bot, slackboy, doesn't start automatically when I reboot the server, but does throw a MSG534 error, which doesn't make sense. There's also not much Google data on this particular error, especially solutions to the issue. I've a line added in /etc/rc.d/rc.local (su ron -c /home/ron/eggdrop/eggdrop /home/ron/eggdrop/slackboy.conf) that will sometimes run and sometimes not (when I execute it manually). Today, I just ran it as a normal user in the bot's directory (eggdrop -c slackboy.conf) and it worked. Weird.

I'm also using my Linksys wifi card (the WPC54GS PCMCIA card). I've done this in the past and actually have a script that I use to initiate the card. This card has no opensource drivers so I use ndiswrapper. Here's the dmesg initiation data:

ndiswrapper version 0.11 loaded (preempt=no,smp=no)
PCI: Setting latency timer of device 03:00.0 to 64
ndiswrapper: using irq 11
wlan0: ndiswrapper ethernet device 00:0f:66:4a:42:6a using driver lsbcmnds
wlan0: encryption modes supported: WEP, WPA with TKIP, AES/CCMP
ndiswrapper: driver lsbcmnds (Cisco-Linksys ,LLC.,02/19/2004, added

The lsbcmnds driver is a Windows driver that ndiswrapper uses. I can't use this driver for things such as Kismet, but for typical enduser type work, it is functional. I'd rather not have to buy another wifi card just to be Linux-idealistic.

I also want to be able to use WPA, but I'm only using WEP at the moment. The reason for this is that my Tivo uses wireless to pull programming data. The wifi adapter that I'm using is supported by Tivo but I don't believe it has WPA capability. This is the only thing holding me back from using WPA. The adapter is a WUSB11 v2.8. I shall double-check to see if it is WPA-capable. Even so, I'd still like to eventually get away from 11B. That's going to be hard to get away from, since Tivo only has limited support for 54G.

Sunday, May 07, 2006

Whoosh, Over His Head...

|splat| haha
NeoSadist |splat|,
Half-Left lol
|splat| heh
Half-Left NeoSadist, nice :-)

-- a bit later, when I was no longer away from the keyboard, I saw it, laughed, then copy/pasted into the channel --

W|GGL|T |splat| haha
W|GGL|T NeoSadist |splat|,
W|GGL|T lol!
|splat| hehe
* muteW has quit ("Exeunt muteW")
* gm152 has quit (Remote closed the connection)
thrice` doesn't work

Of course it doesn't work...that wasn't the point NeoSadist was trying to make..., some people just don't have common sense.

Shell Scripting | Creation of a Subnet and Securing Wireless Access Points

I've been trying to automate some things on my Linux and BSD boxes, so I've been scripting a bit lately.

For one, I like the mailed stats that FreeBSD and OpenBSD provides the administrator, so I've attempted to do the same for Slackware. I've a version that also runs on BSD, although you have to hack it to get it to work under a BSD machine. I'm currently looking over it to see if I can lessen the hacking of the script when using it on a non-Linux or non-Slackware machine, but for now it does work. It does not mail the admin yet, but it does keep a listing of stats every hour on the hour (via cron).

I've used several web-based resources to create this script:

I've also bought a few scripting books:

Unix Shells by Example, 3rd Edition, by Ellie Quigley
Linux Shell Scripting with Bash, by Ken O. Burtch
Learning the bash Shell, 2nd Edition, by Cameron Newham and Bill Rosenblatt

There's a ton of shell scripting books out there, along with a ton of free online tutorials, but the ones I've mentioned gave me the most insight.

I shall post a link to my script when I've finished working it to my liking.

I've also done a few things to my network during the last week.

I bought a Netgear VPN Firewall (FVS114). I want to play with hardware a bit and this unit was cheap. Sometime in the near future, I want to inplement a VPN tunnel from my residence to my linode. Sure, I can implement it via open-source software but I have to start delving with hardware if I want to sell myself as a professional security consultant. Anyways, I was previously utilizing a Linksys WRT54X4 Firewall/Router/WAP as my border router/gateway, which was fine where it was, but in order to utilize the Netgear to its fullest (which I plan to do), it needed to be placed at the border, so I put the Netgear in the Linksys' place. I then put the Linksys inside my LAN, as I needed it's WAP capabilities.

It took me a week to get things the way I wanted them. I wanted the Linksys on its own network, and that required creating a subnet. I opted to let it use its default network segment, It pulled an IP from the Netgear (the Netgear is set up to serve IP addresses via DHCP). I was able to run a CAT5 from the Linksys to my Shuttle box and gain access to the administrative browser. Everything was going well, until I found that I couldn't ping other machines on the Linksys network segment. I spent a week trying to figure out why until I got a coworker to come over and take a look at things. He almost immediately got things working. I found that the Sygate firewall that I had installed on the Shuttle was impeding things. I turned it off and the laptop that was associated with the WAP was able to ping the Shuttle. One more problem was apparent: I wasn't able to get out to the internet on any laptop, although I could on the Shuttle. The reason? The Linksys FW was enabled. Once that was turned off, I was able to open up a browser and point it to Those were pretty simple solutions that any competent engineer should have been able to fix. My issue? Well, most engineers run standard tools in their work environment. I'd forgotten about the Sygate firewall, which is only installed on two of my many, its not so standard within my network environment, so it was easy to forget. That, and I was so wrapped up with getting this setup to work that I didn't check the obvious items.

All that is left now is to add a static route on the Netgear that will allow communcations from the Linksys netrange.

This is a decent setup, as you always want to segregate your WAP from your network. For home users, the basic setup is fine, but I'm not a regular home user. I want to at least TRY to do things the right way.

Now, since we're talking about WAPs, I'll let you know that I'm using WEP, the protocol that's branded 'unsecure'. Why am I using it? Because not all of my wireless devices can use the WPA protocol. Some people say that WEP is so insecure that its better off not using it...that's total B.S. You always want to use security in-depth anyways, which means you need to implement your security in layers to cover all potential weaknesses. Here's what I normally do:

1. Create a good, long password for the administrative GUI.

2. Either limit the DHCP pool to a very small amount (depending on how many wireless devices you have...I've at least 5, so I have a DHCP pool of 7), or turn off DHCP and assign your devices static IPs. This way, if someone gains access to your network, he's smart enough to get his own IP and not have it given to him. The lesson is to not make it easy to bust into your network.

3. Change your WEP key from time to time, maybe once a month. My Linksys will ask for any phrase and create 4 keys based off of that one phrase. Rotate those every once in awhile. Why do all this? The WEP key is supposedly easy to crack. A coworker of mine did attempt to crack a key. He couldn't. Many people think it is easy, but apparently its not as easy as many people say, but in case it IS easy, rotate your keys from time to time.

4. You can use MAC address authentication. Sure, someone could spoof a MAC, but remember that we're layering security...he may spoof a MAC but he won't be able to circumvent the rest of the things you've implemented.

5. Don't broadcast your SSID. Those who know how to hack will find it anyways, but what you want to worry about is the script kiddies out there and the ocassional bandwidth leech. Don't worry about the serious crackers out there, as if they wanted to pop your box, they could easily do it, with or without your basic security layering.

6. On some WAPs, you can dial down the power a bit so the wireless signal doesn't broadcast out to 2-3 blocks. Of course, when you do this, your wireless bandwidth gets throttled. Weigh the cost of this in your own mind and decide what would be best for your network. I don't throttle my signal but I do have my WAP in the basement, which does cut down on the signal. If you've a WAP on a 2nd or 3rd floor home or building, its going to be hard to throttle the signal to the point that others won't see it, since the WAP is physically on higher ground.

I may be missing a few wifi pointers, but I'll let others fill in the blanks. The above are the ways I keep my WAP and network secure. I hope you guys and gals can benefit from those tips.