Monday, October 30, 2006

KDE Network Manager problems resolved

OK, knetworkmanager is fixed. All I had to do was add this:

<policy user="|my_username|">
   <allow own="org.freedesktop.NetworkManagerInfo"/>
   <allow send_destination="org.freedesktop.NetworkManagerInfo"/>
   <allow send_interface="org.freedesktop.NetworkManagerInfo"/>
</policy>

to these two files:

/etc/dbus-1/system.d/knetworkmanager.conf
/etc/dbus-1/system.d/NetworkManager.conf


I killed all instances of NetworkManager, NetworkManagerDispatcher. and knetworkmanager, then started NetworkManager and knetworkmanager (without using kdesu). It came up without errors and it recognized my network devices--yeehaw. I may submit this to Ubuntu to see if there's a way to change the default policy. Hope this helps somebody else out there.

Edit: this is quite possibly related to Ubuntu Bug #50770.

Friday, October 27, 2006

KDE Network Manager problems continued

I found an interesting error message that knetworkmanager kicks out at the console.

Error requesting name, org.freedesktop.DBus.Error.AccessDenied: Connection ":1.6" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file

This implies that it's a permissions problem, so I started the program instead like this

kdesu knetworkmanager

Boom! It's up and seeing the network devices correctly. So the problem is in one of these files

/etc/dbus-1/system.d/knetworkmanager.conf
/etc/dbus-1/system.d/NetworkManager.conf

I'll try messing with them a bit and I'll post more as I learn more.

Friday, October 20, 2006

Generate one-time-sequences file for knockd

I've been playing a little with knockd, mostly just for fun. It's a program that listens to all traffic, waiting to hear "hits" to a special sequence of TCP/UDP ports. These hits constitute a knock. When somebody gives the correct knock the program performs a custom action, usually opening up remote access to the host sending the knock.

For instance, if I want to mitigate SSH brute force attempts, I first close all ports on the firewall, then fire up knockd. When knockd hears the correct knock sequence, it opens access to TCP port 22 for 10 seconds to the "knocker", who must authenticate via SSH during those 10 seconds. Then it closes new requests to port 22, but allows the established SSH session to continue.

What about eavesdroppers listening for the knock sequence, you ask? Very good question! You have the option of using a one-time-sequences file. It's just a list of different knocks that you come up with. The client and server both have the list and they use each sequence only once. That way anybody can listen to the knock sequence and will not know what the next valid knock will be.

Here's a simple perl script to generate the secret one-time-sequences file

#!/usr/bin/perl
## The number of knock sequences to generate
$num_knocks = 1000;
## The number of ports in each knock
$knock_size = 10;

for (1...$num_knocks)
{
   print " ";
   for (1..$knock_size)
   {
     print int(rand(64511) + 1024);
     print "," unless $_ == 10;
   }
   print "\n";
}



Redirect the output into a file and put that file on both computers. Use it for the one_time_sequences directive of knockd. The knock client needs a little trickery to use the file. I'll later share a script that does just that!

Monday, October 16, 2006

The host remediation myth

We want to keep malware off our network. I've been working on a solution to make sure that hosts connecting to our network meet the following conditions:
1. Current on operating system updates
2. Running antivirus with current virus definitions
3. Aren't running "bad" software

Most solutions I've found work something like this:
1. After authenticating the user (that's an entirely different subject), prompt to install a remediation agent
2.a. if the agent is installed, run a scan for the good/bad stuff
2.b. if the agent isn't installed, run a custom security scan (usually nessus) to look for bad stuff
3.a. if the host passes the security check, let it on the network
3.b. if the host fails the check, give the user a chance to fix the problem (d/l update, virus defs, etc.) and re-run the check.
4. Schedule a scan for some time in the future

Is it just me, or does this not really solve the problem? This does a check at a moment in time to see if the host is clean. What if the user gets a worm via email while on the network? Waiting for the next remediation scan may take an hour, at best several minutes. This is plenty of time for that worm to propagate to other hosts on the network and cause problems.

I'd love a real-time remediation system. It may or may not require scans of the hosts connecting, but it would definitely keep an eye on the hosts' behavior while connected to the network. If any one misbehaved the system would immediately take action, i.e. put an ACL in to stop the behavior or quarantine the host to an isolated network. Most vendors I talked to said this was too automated and would be a headache to manage. I think it's because they didn't have a product to sell me that could do this.

Some argue that a network IDS/IPS is basically the same thing. Not exactly...it focuses on network borders more than individual hosts. True, the signatures would probably be identical. I hope that switch vendors start using modern technology (ASICs and fast CPUs) to implement this at the access port. After a short period of fine-tuning the enforcement configuration, I think this would be one sweet network janitor.

I've found one company that does something similar, but haven't done a demo.

Monday, October 09, 2006

KDE Network Manager problems

I've been using knetworkmanager in fluxbox on Kubuntu Dapper 6.06. It works OK (love it for WPA) but there are a few quirks. This is on a Dell Latitude D810 with the Intel 2915 A/B/G card, using the ipw2200 driver.

The first annoyance was that it didn't seem to work correctly with kwalletmanager. It usually didn't retrieve passwords, but the behavior was unpredictable. I decided to try whacking the config for both programs:

killall knetworkmanager kwalletmanager
mv ~/.kde/share/apps/kwallet/kdewallet.kwl ~
mv ~/.kde/share/config/knetworkmanagerrc ~
kwalletmanager &
knetworkmanager &

After that I only had to enter the network password once and it has since been saved/retrieved without issues.

Second annoyance--I usually hibernate whenever I dock/undock, but there are times when I'm forced to actually shut down. It's after a real shutdown that knetworkmanager misbehaves. The message is "No network device found" and it persists until 2-3 hibernates later. Until it decides to cooperate I can use iwconfig, wpasupplicant, and dhclient just fine on the interface. I've tried killing knetworkmanager and the backend NetworkManager processes, but the bugger won't see my network interfaces until I hibernate a few times. And no, Google doesn't have an answer yet.

First blog

I've been wanting to start a blog for a long time now. I mostly want to document some tips a tricks that I will likely otherwise forget, and probably rant a bit. I guess we'll see what creeps in...standard disclaimers apply.