Remove/blank this file, for some reason the acx module is blacklisted. Perhaps it causes some issues with other 4000 devices?

You should also check out

/etc/network/interfaces

to add some wireless networks.

You should also get rid of some startup programs (if you don’t need them)

Move the following to a safe place (/root?)

/etc/rc5.d/S10dropbear

/etc/rc5.d/S20syslog

/etc/rc5.d/S23bluetooth

This will disable bluetooth support, logging and remote SSH access.

In order for wireless to work after suspend, you need to make two files.

/etc/apm/suspend.d/S50ifdown

case $1 in
start)
ifdown wlan0
rmmod -f acx
;;
esac

/etc/apm/resume.d/S50ifup

case $1 in
start)
modprobe acx
sleep 1
ifup wlan0
;;
esac

Set up your /etc/network/interfaces file (or use the GUI) for ifdown/ifup to work.

You might also want to remove /etc/apm/resume.d/50-gpe-bluetooth-resume

In Windows, browse to your ‘Storage Card’ and run the exe file. Choose the second of the three options for booting linux, and if all goes well you’ll running linux in no time! You will lose all your Windows settings.

If anything goes wrong, do the following to perform a ‘hard reset’

1. Hold down the power button

2. Use the stylus to press down the reset button on the side of the PDA

3. Let go of the power button while still pressing the reset button

4. Let go of reset. Device should boot into Windows.

Other issues/Comments

For some reason, my battery is not detected under Windows 2003 (can’t tell there’s a battery, nor the charge). Works with Linux, so not sure what’s up with that.

Wireless so far has performed flawlessly. I get the same latency I get from my laptop when pinging yahoo.com, and see 2-4ms latency on the same network. Very surprising, since on Windows internal network latency would be around 20-40, with outside networks having horrible (100-200) latency.

All in all, I think I’m going to have a lot of fun with this device. And for around $80 on ebay, it’s not a bad deal.

When you use sftp/scp to transfer directories, you notice it ends up taking a long time. It works on files one at a time and they can often take a small amount of time to start and finish. A solution is to use tar to stream the file over ssh (so you have one continuious stream, without starting/stopping a lot).

As I come across network security issues in Linux, I can’t help but wish that Debian had decent default firewall rules (and kernel network protection in general) like many other distros.

This applies to both Debian 4.0 and Ubuntu 7.10.

By default, a Ubuntu or Debian install of Linux is vulnerable to a SYN flood. If behind a router, chances are there won’t be a problem. But if it’s a standalone Linux machine connected to the internet, the machine is vulnerable to a DoS attack.

The second should probably be used if it’s a server. The first way may still have quite a few open SYN connections.

You may just want to block the IP(s) that are conducting a SYN flood on you (keep an eye on netstat or iptables.log). A script that does this would be pretty useful; I wonder if there are any out there (or if I have to write one?).

iptables -I -s ip.to.ban -j DROP

Along with rules to help protect against flooding, it seems like it would be a good idea to block all ports by default.

One solution could be to have a folder called /etc/security/iptables that contains files that get passed to iptables at startup (in the same way /etc/rc2.d gets read in numeric order). So you could have files like 22ssh, 23ftp, etc. with iptable rules in each file. You could also have an ‘ENABLED’ variable like some files in /etc/default have (so that ports wouldn’t be opened by default; the user would have to manually enable them for the port to be opened).

Then they’d just run /etc/init.d/iptables restart and the port would be opened (flush the rules, reapply).

I’ve put together a proof-of-concept for this; feel free to check it out. Extract it somewhere, and check out the source. Then try the following

tar xvzf debian-iptables.tar.gz -C /

Which will create and fill /etc/security/iptables and put an init file in /etc/init.d and a link in /etc/rc2.d

It hasn’t been tested as much as I’d like, but it should work.

Please do this at the computer itself; if you do it over the network you might be locked out.

When using iptables to log, you generally make a ‘LOG’ chain, and then

iptables -A INPUT -j LOG

iptables -A INPUT -j DROP

To log and then drop.

LOG has some disadvantages though. Using LOG, information will fill up the output of the ‘dmesg’ command as well as the kern.log file. Using Debian Etch, I was unable to get iptables to log to any other file but kern.log.

There are some issues with remote logging using syslogd. By default, anyone can write logs to syslod if it is accepting connections. This can be an issue if someone wants to fill your /var/log with junk.

On a default install of Debian (or just about any distro) you should have all the tools you need already.

This will make nfs-kernel-server complain about ‘no_subtree_check’; feel free to add it.

no_root_squash means that the ‘root’ user on a client system going to this directory will be root on the server share as well. This is something you’ll only want to use in a protected LAN. Otherwise, ‘root’ will be ‘nobody’ while in the shared directory.

NEVER ALLOW NFS TO BE SHARED ACROSS THE INTERNET.

NFS is unencrypted by default (I believe you can only encrypt it using Kerebos).

You should now be in without having to be asked a password. There are some obvious security implications here; nothing you should have to worry about if you have a strong password and good permissions on /home/user.

LDAP still gets me from time to time. I’ve set up multiple Debian LDAP servers now, and each time it seems like something new gets me. I’m going to try to put together a set-by-step LDAP guide that is sure to work (with Debian Etch). If you have any problems, please post! This setup has been tested on x86 and amd64 Debian variants.There seem to be some bugs with debian’s default ldap install (missing .so files, config files that don’t work, not remembering settings from the setup screens). However, once everything works it’s rock solid.

snoppy is an awesome tool available on the debian archives. It allows you to see what commands your users have run (by default logs to /var/log/auth.log). It acts like a beefed up .bash_history that users cannot disable/delete/etc.

logcheck scans your logs for weird things, and emails them to you.

By default, these two programs do not get along. snoopy entries show up in logcheck’s emails (which can get very, very big). This sort of defeats the purpose of logcheck, since you get sent massive emails with the important stuff hidden between giant blocks of snoopy logs.