If you are still running telnet instead of ssh, you should take a break from
this manual and change this. Ssh should be used for all remote logins
instead of telnet. In an age where it is easy to sniff internet traffic
and get cleartext passwords, you should use only protocols which
use cryptography. So, perform an
apt-get install ssh on your system n
Encourage all the users on your system to use ssh instead of telnet, or
even better, uninstall telnet. In addition you should avoid logging
into the system using ssh as root and use alternative methods to become root
sudo. Finally, the sshd_config file,
/etc/ssh, should be modified to increase security as well:
Try not to permit Root Login wherever possible. If anyone wants to become root via ssh, now two logins are needed and the root password cannot be brute forced via SSH.
Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs.
Empty passwords make a mockery of system security.
AllowUsers alex ref
Allow only certain users to have access via ssh to this machine.
AllowGroups wheel admin
Allow only certain group members to have access via ssh to this machine. AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Not surprisingly they are called "DenyUsers" and "DenyGroups".
It is completely your choice what you want to do. It is more secure only to allow access to machine from users with ssh-keys placed in the /.ssh/authorized_keys file. If you want so, set this one to "no".
As a final note be aware, that these directives are from a OpenSSH configuration file. Right now, there are three commonly used SSH daemons, ssh1, ssh2 and OpenSSH by the OpenBSD people. Ssh1 was the first ssh daemon available and it is still the most commonly used (there are rumors that there is even a windows port). Ssh2 has many advantages over ssh1 except it is released under an non-opensource license. OpenSSH is completely free ssh daemon, which supports both ssh1 and ssh2. OpenSSH is the version installed on Debian when the package 'ssh' is chosen.
If you really have to use FTP (without wrapping it around a SSL tunnel), you should chroot your users into their home directory, that they are unable to see anything else than their own directory. Otherwise they could traverse your root filesystem just like if they had a shell. You can add the following line in your proftpd.conf in your global section to enable this chroot feature:
Restart proftpd by
/etc/init.d/proftpd restart and check whether
you can escape from your homedir now.
Today X-Terminals are being used by more and more companies where one server
is needed for a lot of workstations. This can be dangerous, because you need
to allow the file server to connect to the the clients (X server from the X
point of view. X switches the definition of client and server).
If you follow the (very bad) suggestion of many docs, you type
xhost + on your machine. This allows any X client to connect to your
system. For slightly better security, you can use the command
xhost +hostname instead to only allow access from specific hosts.
A much more secure solution, though, is to use ssh to tunnel
X and encrypt the whole session. This is done automatically when you ssh
to another machine. This has to be disabled in /etc/ssh/ssh_config by
yes. In times of SSH, you should
drop the xhost based access control completely.
For best security, if you do not need X access from other machines, is to switch off the binding on tcp port 6000 simply by typing:
startx -- -nolisten tcp
If you only want to have a display manager installed for local usage
(having a nice graphical login ie), make sure the XDMCP (X Display Manager
Control Protocol) stuff is disabled. In XDM you can do this with this line
Normally, all display managers are configured not to start XDMCP services per default in Debian.
Imagine, you arrive at work, and the printer is spitting out endless amounts of paper because someone is DoSing your line printer daemon. Nasty, isn't it? So keep your printer servers specially secure.
FIXME. Content missing. (No lpr experience)
Reading/receiving mail is the most common cleartext protocol. If you use either POP3 or IMAP to get your mail you send your password cleartext across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Socket Layer) to receive your mails. The other alternative is ssh, if you have a shell account on your box.
Here is a basic fetchmailrc:
poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 </dev/null > /dev/null'
The preconnect is the important line. It fires up a ssh session and creates the necessary tunnel, which automatically forwards connections to localhost port 1236 to the imap mail server, but encrypted. Another possibility would be to use fetchmail with the ssl feature.
If you want to provide encrypted mail services like POP and IMAP,
apt-get install stunnel and start your daemons this way:
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
This command wraps the provided daemon (-l) to the port (-d) and uses the
specified ssl cert (-p).
A loghost is a host which collects syslog data remotely over the network. If
one of your machines is cracked the intruder is not able to cover his tracks,
unless he hacks the loghost as well. So, the loghost should be especially
secure. Making a machine a loghost is really simple. Just start the
syslogd with 'syslogd -r' and a new loghost is born. Now you have to configure
your other machines to send the data to the loghost. Add an entry like this
facility should be one of authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local1 up to local7. level should be alert, crit, err, warning, notice, info debug. If you want to log everything remote, just write:
into your syslog.conf. Logging remotely as well as locally is the best solution (the attacker might presume to have covered his tracks after deleting the local log files). See the syslog(3), syslogd(8) and syslog.conf(5) manpage for additional information.
On a standard Debian installation, the name service daemon, BIND, runs as user root and group root. It is quite easy to run BIND under another user ID (UID). However, if another user than root runs BIND, then BIND cannot detect new interfaces automatically. For example, if you stick a PCMCIA card into your laptop. Check the README.Debian file in your named documentation directory for more information about this issue. There have been many recent security problems concerning BIND, so switching the user is useful when it is possible.
To run BIND under a different user, first create a separate user and group for
it (it is not a good idea to use nobody or nogroup for every service not running
as root). In this example, the user and group
named will be used. You
can do this by entering:
addgroup named adduser --system --ingroup named named
/etc/init.d/bind with your favorite editor and change the
line beginning with
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u
All you need to do now is to restart bind via '/etc/init.d/bind restart', and then check your syslog for two entries like this:
Sep 4 15:11:08 nexus named: group = named Sep 4 15:11:08 nexus named: user = named
Voila! Your named now does not run as root. To achieve maximum BIND security, now build a chroot jail (See 3.13) around your daemon.
snort is a flexible packet sniffer or logger that detects attacks due to
an attack signature dictionary. It detects a variety of other attacks and
probes, such as buffer overflows, stealth port scans, CGI attacks, SMB
probes, and much more. Snort has a real-time alerting capability. This is
a tool which should be installed on every router to keep an eye on your
network. Just install it via
apt-get install snort, follow the
questions, and watch it log.