There are many ways to address vulnerabilities, however the first thing you should know is that Linux isn't as susceptible to intrusion as other Operating Systems. This is mainly due to lack of malware that targets *NIX. Nevertheless, you want to be aware of the ways in which your system can be accessed.
Passwords
Firstly you should change the default passwords for any users that are able to login. For Debian this is just the default user Pi. For Arch Linux this is the super user root.
Passwords are changed when logged in as the user by typing passwd on the command line.
A secure password policy is encouraged, as it would be fairly simple to run brute force dictionary attacks on your default user. Pick a decent, medium length password.
Obscurity
Remote access is probably the most important security hole. What we can use here is named security by obscurity.
A common method of attack is to scan a range of IP addresses for open ports.
So one of the simplest countermeasures we can take is to be a user who does not use the default ports.
All that needs to be done here is to change the default ports for commonly used protocols. For example, the default SSH port is 22 and FTP is 21. On my system SSH uses 222 and FTP 221, which should obscure these protocols from any automated attack.
Connection Security
Firstly, the most important security concern is that the root account should not be able to log in via SSH. You can disable root login in the /etc/ssh/sshd_config file by commenting or removing this line:
PermitRootLogin yes
It should be set to no by default, but it is best to make sure.
If you use SSH a lot, and are worried about man in the middle attacks, dictionary attacks against your password, then you can use SSH Keys.
Key-based authentication has several advantages over password authentication, for example the key values are significantly more difficult to brute-force than plain passwords.
To set up SSH key authentication you need to first create the key pair. This is most easily done on your client machine (the machine with which you want to access the Pi).
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.
As you can see, this has created two files, the private key id_rsa and the public key id_rsa.pub.
The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.
So what we would like to do is copy the public key onto the Raspberry Pi. We can do this very easily:
ssh-copy-id pi@address
Where pi is the Raspberry Pi username, and address is the IP address of the Pi.
I'll reiterate, we distribute the public key. The private key is yours. Hold onto it tightly, to release that key breaks the security of the system.
The Arch wiki has an excellent description on how this works:
When an SSH server has your public key on file and sees you requesting
a connection, it uses your public key to construct and send you a
challenge. This challenge is like a coded message and it must be met
with the appropriate response before the server will grant you access.
What makes this coded message particularly secure is that it can only
be understood by someone with the private key. While the public key
can be used to encrypt the message, it cannot be used to decrypt that
very same message. Only you, the holder of the private key, will be
able to correctly understand the challenge and produce the correct
response.
For more information on the security of public key authentication, Wikipedia has a thorough explanation.
With SSH security in place you can do an awful amount of encrypted, secure data transfers. Practically every other port connection can be routed through SSH if needed. You can even forward the X session through SSH so that it appears on another machine.
As an interesting example, yesterday I was running Eclipse on my Desktop, viewing it on my Raspberry Pi, and controlling the mouse and keyboard from my Netbook. Such is the power of SSH.
Permissions
File permissions are the crux of the Linux security system. They effect who can see your files and folders, and can be very important at protecting your data.
For example, log in to the Raspberry Pi as a normal user and run:
cat /etc/shadow
The shadow file contains encrypted passwords for the users on the system, so we wouldn't want just about anyone to take a look at it! So you should see this response:
cat: /etc/shadow: Permission denied
We can see why this is by taking a look at the permissions of the file:
ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow
This tells us that the file is owned by root, and only the owner has read/write permissions. Let's break down that output.
-rw-------
This is the state of the permissions.
The first bit tells us the type of file (- means regular file).
The next three bits represent the actions available to the owner of the file. The second three bits represent the group, and the final three are for other or everyone else. Thus a directory with full permissions would look like this:
drwxrwxrwx 10 root root 280 Jun 20 11:40 tmp/
That's read, write and execute permissions for the owner, group and everyone else.
The next important part is the two names. In our case root root. The first user is the owner of the file. The second is the usergroup. For example it would be common to see:
drwxr-xr-x 10 pi users 280 Jun 20 11:40 home/pi
This would allow read/write access for the user pi on his home directory, and read access for all other users.
Permissions most often referred to and controlled using octal values. For example, if we want to set rw for only the owner we would type:
chmod 600 /path/to/file
This is a basic overview, for more details on Linux file permissions, here is a good article.
This understanding is important when securing files and folders. For example, say we have just set up SSH keys. We definitely do not want any other users to see inside our ~/.ssh directory, or they would be able to take our private key. Thus we remove their read privileges:
chmod 700 ~/.ssh
ls -la ~/.ssh
drwx------ 2 james users 4096 Jun 18 03:05 .
I hope this clears up some of your concerns with securing Linux. From this you should be able to see that it is a pretty secure system and if you are careful you should have no security issues.
