[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]


Securing Debian Manual
Chapter 5 - Securing services running on your system

Services can be secured in a running system in two ways:

Restricting services so that they can only be accessed from a given place can be done by restricting access to them at the kernel (i.e. firewall) level, configure them to listen only on a given interface (some services might not provide this feature) or using some other methods, for example the Linux vserver patch (for 2.4.16) can be used to force processes to use only one interface.

Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See xinetd.conf(5). 

     service nntp
     {
             socket_type     = stream
             protocol        = tcp
             wait            = no
             user            = news
             group           = news
             server          = /usr/bin/env
             server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
     +/usr/sbin/snntpd logger -p news.info
             bind            = 127.0.0.1
     }

The following sections detail how specific individual services can be configured properly depending on their intended use.

5.1 Securing ssh

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 clear-text passwords, you should use only protocols which use cryptography. So, perform an apt-get install ssh on your system now.

Encourage all the users on your system to use ssh instead of telnet, or even better, uninstall telnet/telnetd. In addition you should avoid logging into the system using ssh as root and use alternative methods to become root instead, like su or sudo. Finally, the sshd_config file, in /etc/ssh, should be modified to increase security as well:

You can also restrict access to the ssh server using pam_listfile or pam_wheel in the PAM control file. For example, you could keep anyone not listed in /etc/loginusers away by adding this line to /etc/pam.d/ssh: 

     auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

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 a closed-source 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.

You can read more information on how to set up SSH with PAM support in the security mailing list archives.

5.1.1 Chrooting ssh

Currently OpenSSH does not provide a way to chroot automatically users upon connection (the commercial version does provide this functionality). However there is a project to provide this functionality for OpenSSH too, see http://chrootssh.sourceforge.net, it is not currently packaged for Debian, though. You could use, however, the pam_chroot module as described in Restricting users's access, Section 4.10.8.

In Chroot environment for SSH, Appendix G you can find several options to make a chroot environment for SSH.

5.1.2 Ssh clients

If you are using an SSH client against the SSH server you must make sure that it supports the same protocols that are enforced on the server. For example, if you use the mindterm package, it only supports protocol version 1. However, the sshd server is, by default, configured to only accept version 2 (for security reasons).

5.1.3 Disallowing file transfers

If you do not want users to transfer files to and from the ssh server you need to restrict access to the sftp-server and the scp access. You can restrict sftp-server by configuring the proper Subsystem in the /etc/ssh/sshd_config.

You can also chroot users (using libpam-chroot so that, even if file transfer is allowed, they are limited to an environment which does not include any system files.

5.1.4 Restricing access to file transfer only

You might want to restrict access to users so that they can only do file transfers and cannot have interactive shells. In order to do this you can either:

5.2 Securing Squid

Squid is one of the most popular proxy/cache server, and there are some security issues that should be taken into account. Squid's default configuration file denies all users requests. However the Debian package allows access from 'localhost', you just need to configure your browser properly. You should configure Squid to allow access to trusted users, hosts or networks defining an Access Control List on /etc/squid/squid.conf, see the Squid User's Guide for more information about defining ACLs rules. Notice that Debian provides a minimum configuration for Squid that will prevent anything, except from localhost to connect to your proxy server (which will run in the default port 3128). You will need to customize your /etc/squid/squid.conf as needed. The recommended minimum configuration (provided with the package) is shown below: 

     acl all src 0.0.0.0/0.0.0.0
     acl manager proto cache_object
     acl localhost src 127.0.0.1/255.255.255.255
     acl SSL_ports port 443 563
     acl Safe_ports port 80          # http
     acl Safe_ports port 21          # ftp
     acl Safe_ports port 443 563     # https, snews
     acl Safe_ports port 70          # gopher
     acl Safe_ports port 210         # wais
     acl Safe_ports port 1025-65535  # unregistered ports
     acl Safe_ports port 280         # http-mgmt
     acl Safe_ports port 488         # gss-http
     acl Safe_ports port 591         # filemaker
     acl Safe_ports port 777         # multiling http
     acl Safe_ports port 901         # SWAT
     acl purge method PURGE
     acl CONNECT method CONNECT
     (...)
     # Only allow cachemgr access from localhost
     http_access allow manager localhost
     http_access deny manager
     # Only allow purge requests from localhost
     http_access allow purge localhost
     http_access deny purge
     # Deny requests to unknown ports
     http_access deny !Safe_ports
     # Deny CONNECT to other than SSL ports
     http_access deny CONNECT !SSL_ports
     #
     # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
     #
     http_access allow localhost
     # And finally deny all other access to this proxy
     http_access deny all
     #Default:
     # icp_access deny all
     #
     #Allow ICP queries from everyone
     icp_access allow all

You should also configure Squid based on your system resources, including cache memory (option cache_mem), location of the cached files and the amount of space they will take up on disk (option cache_dir).

Notice that, if not properly configured, someone may relay a mail message through Squid, since the HTTP and SMTP protocols are designed similarly. Squid's default configuration file denies access to port 25. If you wish to allow connections to port 25 just add it to Safe_ports lists. However, this is NOT recommended.

Setting and configuring the proxy/cache server properly is only part of keeping your site secure. Another necessary task is to analyze Squid's logs to assure that all things are working as they should be working. There are some packages in Debian GNU/Linux that can help an administrator to do this. The following packages are available in Debian 3.0 and Debian 3.1 (sarge):

When using Squid in Accelerator Mode it acts as a web server too. Turning on this option increases code complexity, making it less reliable. By default Squid is not configured to act as a web server, so you don't need to worry about this. Note that if you want to use this feature be sure that it is really necessary. To find more information about Accelerator Mode on Squid see the Squid User's Guide - Accelerator Mode

5.3 Securing FTP

If you really have to use FTP (without wrapping it with sslwrap or inside a SSL or SSH tunnel), you should chroot ftp into the ftp users' home directory, so that the user is unable to see anything else than their own directory. Otherwise they could traverse your root file system just like if they had a shell in it. You can add the following line in your proftpd.conf in your global section to enable this chroot feature: 

     DefaultRoot ~

Restart ProFTPd by /etc/init.d/proftpd restart and check whether you can escape from your homedir now.

To prevent ProFTPd DoS attacks using ../../.., add the following line in /etc/proftpd.conf: DenyFilter \*.*/

Always remember that FTP sends login and authentication passwords in clear text (this is not an issue if you are providing an anonymous public service) and there are better alternatives in Debian for this. For example, sftp (provided by ssh). There are also free implementations of SSH for other operating systems: putty and cygwin for example.

However, if you still maintain the FTP server while making users access through SSH you might encounter a typical problem. Users accessing anonymous FTP servers inside SSH-secured systems might try to log in the FTP server. While the access will be refused, the password will nevertheless be sent through the net in clear form. To avoid that, ProFTPd developer TJ Saunders has created a patch that prevents users feeding the anonymous FTP server with valid SSH accounts. More information and patch available at: ProFTPD Patches. This patch has been reported to Debian too, see Bug #145669.

5.4 Securing access to the X Window System

Today, X terminals are 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 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. For this to work, you have to configure both the ssh client and the ssh server. On the ssh client, ForwardX11 should be set to yes in /etc/ssh/ssh_config. On the ssh server, X11Forwarding should be set to yes in /etc/ssh/sshd_config and the package xbase-clients should be installed because the ssh server uses /usr/X11R6/bin/xauth (/usr/bin/xauth on Debian unstable) when setting up the pseudo X display. 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, switch off the binding on TCP port 6000 simply by typing: 

     $ startx -- -nolisten tcp

This is the default behavior in Xfree 4.1.0 (the Xserver provided in Debian 3.0 and 3.1). If you are running Xfree 3.3.6 (i.e. you have Debian 2.2 installed) you can edit /etc/X11/xinit/xserverrc to have it something along the lines of: 

     #!/bin/sh
     exec /usr/bin/X11/X -dpi 100 -nolisten tcp

If you are using XDM set /etc/X11/xdm/Xservers to: :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. If you are using Gdm make sure that the DisallowTCP=true option is set in the /etc/gdm/gdm.conf (which is the default in Debian). This will basically append -nolisten tcp to every X command line [39].

You can also set the default's system timeout for xscreensaver locks. Even if the user can override it, you should edit the /etc/X11/app-defaults/XScreenSaver configuration file and change the lock line: 

     *lock:                  False

(which is the default in Debian) to: 

     *lock:                  True

FIXME: Add information on how to disable the screensavers which show the user desktop (which might have sensitive information).

Read more on X Window security in XWindow-User-HOWTO (/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).

FIXME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to do this.

5.4.1 Check your display manager

If you only want to have a display manager installed for local usage (having a nice graphical login, that is), make sure the XDMCP (X Display Manager Control Protocol) stuff is disabled. In XDM you can do this with this line in /etc/X11/xdm/xdm-config: 

     DisplayManager.requestPort:     0

For GDM there should be in your gdm.conf: 

     [xdmcp]
     Enable=false

Normally, all display managers are configured not to start XDMCP services per default in Debian.

5.5 Securing printing access (the lpd and lprng issue)

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?

In any UNIX printing architecture, there has to be a way to get the client's data to the host's print server. In traditional lpr and lp, the client command copies or symlinks the data into the spool directory (which is why these programs are usually SUID or SGID).

In order to avoid any issues you should keep your printer servers especially secure. This means you need to configure your printer service so it will only allow connections from a set of trusted servers. In order to do this, add the servers you want to allow printing to your /etc/hosts.lpd.

However, even if you do this, the lpr daemon accepts incoming connections on port 515 of any interface. You should consider firewalling connections from networks/hosts which are not allowed printing (the lpr daemon cannot be limited to listen only on a given IP address).

Lprng should be preferred over lpr since it can be configured to do IP access control. And you can specify which interface to bind to (although somewhat weirdly).

If you are using a printer in your system, but only locally, you will not want to share this service over a network. You can consider using other printing systems, like the one provided by cups or PDQ which is based on user permissions of the /dev/lp0 device.

In cups, the print data is transferred to the server via the HTTP protocol. This means the client program doesn't need any special privileges, but does require that the server is listening on a port somewhere.

However, if you want to use cups, but only locally, you can configure it to bind to the loopback interface by changing /etc/cups/cupsd.conf: 

     Listen 127.0.0.1:631

There are many other security options like allowing or denying networks and hosts in this config file. However, if you do not need them you might be better off just limiting the listening port. Cups also serves documentation through the HTTP port, if you do not want to disclose potential useful information to outside attackers (and the port is open) add also: 

     <Location />
      Order Deny,Allow
      Deny From All
      Allow From 127.0.0.1
     </Location>

This configuration file can be modified to add some more features including SSL/TLS certificates and crypto. The manuals are available at http://localhost:631/ or at cups.org.

FIXME: Add more content (the article on Amateur Fortress Building provides some very interesting views).

FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing system.

FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian.

5.6 Securing the mail service

If your server is not a mailing system, you do not really need to have a mail daemon listening for incoming connections, but you might want local mail delivered in order, for example, to receive mail for the root user from any alert systems you have in place.

If you have exim you do not need the daemon to be working in order to do this since the standard cron job flushes the mail queue. See Disabling daemon services, Section 3.6.1 on how to do this.

5.6.1 Configuring a Nullmailer

You might want to have a local mailer daemon so that it can relay the mails sent locally to another system. This is common when you have to administer a number of systems and do not want to connect to each of them to read the mail sent locally. Just as all logging of each individual system can be centralized by using a central syslog server, mail can be sent to a central mailserver.

Such a relay-only system should be configured properly for this. The daemon could, as well, be configured to only listen on the loopback address.

The following configuration steps only need to be taken to configure the exim package in the Debian 3.0 release. If you are using a later release (such as 3.1 which uses exim4) the installation system has been improved so that if the mail transport agent is configured to only deliver local mail it will automatically only allow connections from the local host and will not permit remote connections.

In a Debian 3.0 system using exim, you will have to remove the SMTP daemon from inetd: 

     $ update-inetd --disable smtp

and configure the mailer daemon to only listen on the loopback interface. In exim (the default MTA) you can do this by editing the file /etc/exim.conf and adding the following line: 

     local_interfaces = "127.0.0.1"

Restart both daemons (inetd and exim) and you will have exim listening on the 127.0.0.1:25 socket only. Be careful, and first disable inetd, otherwise, exim will not start since the inetd daemon is already handling incoming connections.

For postfix edit /etc/postfix/main.conf: 

     inet_interfaces = localhost

If you only want local mail, this approach is better than tcp-wrapping the mailer daemon or adding firewalling rules to limit anybody accessing it. However, if you do need it to listen on other interfaces, you might consider launching it from inetd and adding a tcp wrapper so incoming connections are checked against /etc/hosts.allow and /etc/hosts.deny. Also, you will be aware of when an unauthorized access is attempted against your mailer daemon, if you set up proper logging for any of the methods above.

In any case, to reject mail relay attempts at the SMTP level, you can change /etc/exim/exim.conf to include: 

     receiver_verify = true

Even if your mail server will not relay the message, this kind of configuration is needed for the relay tester at http://www.abuse.net/relay.html to determine that your server is not relay capable.

If you want a relay-only setup, however, you can consider changing the mailer daemon to programs that can only be configured to forward the mail to a remote mail server. Debian provides currently both ssmtp and nullmailer for this purpose. In any case, you can evaluate for yourself any of the mail transport agents [40] provided by Debian and see which one suits best to the system's purposes.

5.6.2 Providing secure access to mailboxes

If you want to give remote access to mailboxes there are a number of POP3 and IMAP daemons available.[41] However, if you provide IMAP access note that it is a general file access protocol, it can become the equivalent of a shell access because users might be able to retrieve any file that they can through it.

Try, for example, to configure as your inbox path {server.com}/etc/passwd if it succeeds your IMAP daemon is not properly configured to prevent this kind of access.

Of the IMAP servers in Debian the cyrus server (in the cyrus-imapd package) gets around this by having all access to a database in a restricted part of the file system. Also, uw-imapd (either install the uw-imapd or better, if your IMAP clients support it, uw-imapd-ssl) can be configured to chroot the users mail directory but this is not enabled by default. The documentation provided gives more information on how to configure it.

Also, you might want to run an IMAP server that does not need valid users to be created on the local system (which would grant shell access too), courier-imap (for IMAP) and courier-pop, teapop (for POP3) and cyrus-imapd (for both POP3 and IMAP) provide servers with authentication methods beside the local user accounts. cyrus can use any authentication method that can be configured through PAM while teapop might use databases (such as postgresql and mysql) for user authentication.

FIXME: Check: uw-imapd might be configured with user authentication through PAM too.

5.6.3 Receiving mail securely

Reading/receiving mail is the most common clear-text protocol. If you use either POP3 or IMAP to get your mail, you send your clear-text password across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Sockets Layer) to receive your mail. The other alternative is SSH, if you have a shell account on the box which acts as your POP or IMAP server. Here is a basic fetchmailrc to demonstrate this: 

     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 an 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 certificate (-p).

5.7 Securing BIND

There are different issues that can be tackled in order to secure the Domain server daemon, which are similar to the ones considered when securing any given service:

5.7.1 Bind configuration to avoid misuse

You should restrict some of the information that is served from the DNS server to outside clients so that it cannot be used to retrieve valuable information from your organization that you do not want to give away. This includes adding the following options: allow-transfer, allow-query, allow-recursion and version. You can either limit this on the global section (so it applies to all the zones served) or on a per-zone basis. This information is documented in the bind-doc package, read more on this on /usr/share/doc/bind/html/index.html once the package is installed.

Imagine that your server is connected to the Internet and to your internal (your internal IP is 192.168.1.2) network (a basic multi-homed server), you do not want to give any service to the Internet and you just want to enable DNS lookups from your internal hosts. You could restrict it by including in /etc/bind/named.conf: 

     options {
                 allow-query { 192.168.1/24; } ;
                 allow-transfer { none; } ; 
                 allow-recursion { 192.168.1/24; } ;
                 listen-on { 192.168.1.2; } ;
                 forward { only; } ;
                 forwarders { A.B.C.D; } ;
     };

The listen-on option makes the DNS bind to only the interface that has the internal address, but, even if this interface is the same as the interface that connects to the Internet (if you are using NAT, for example), queries will only be accepted if coming from your internal hosts. If the system has multiple interfaces and the listen-on is not present, only internal users could query, but, since the port would be accessible to outside attackers, they could try to crash (or exploit buffer overflow attacks) on the DNS server. You could even make it listen only on 127.0.0.1 if you are not giving DNS service for any other systems than yourself.

The version.bind record in the chaos class contains the version of the currently running bind process. This information is often used by automated scanners and malicious individuals who wish to determine if one's bind is vulnerable to a specific attack. By providing false or no information in the version.bind record, one limits the probability that one's server will be attacked based on its published version. To provide your own version, use the version directive in the following manner: 

      options { ... various options here ...
     version "Not available."; };

Changing the version.bind record does not provide actual protection against attacks, but it might be considered a useful safeguard.

A sample named.conf configuration file might be the following: 

     acl internal {
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // internal
             aa.bb.cc.dd;            // eth0 IP
     };
     
     acl friendly {
             ee.ff.gg.hh;            // slave DNS
             aa.bb.cc.dd;            // eth0 IP
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // internal
     };
     
     options {
             directory "/var/cache/bind";
             allow-query { internal; };
             allow-recursion { internal; };
             allow-transfer { none; };
     };
     // From here to the mysite.bogus zone 
     // is basically unmodified from the debian default
     logging {
             category lame-servers { null; };
             category cname { null; };   
     };
     
     zone "." {
             type hint;
             file "/etc/bind/db.root";
     };
     
     zone "localhost" {
             type master;
             file "/etc/bind/db.local";
     };
     
     zone "127.in-addr.arpa" {
             type master;
             file "/etc/bind/db.127";
     };
     
     zone "0.in-addr.arpa" {
             type master;
             file "/etc/bind/db.0";
     };
     
     zone "255.in-addr.arpa" {
             type master;
             file "/etc/bind/db.255";
     };
     
     // zones I added myself
     zone "mysite.bogus" {
             type master;
             file "/etc/bind/named.mysite";
             allow-query { any; };
             allow-transfer { friendly; };
     };

Please (again) check the Bug Tracking System regarding Bind, specifically Bug #94760 (regarding ACLs on zone transfers). Feel free to contribute to the bug report if you think you can add useful information.

5.7.2 Changing BIND's user

Regarding limiting BIND's privileges you must be aware that if a non-root user runs BIND, then BIND cannot detect new interfaces automatically, for example when you put a PCMCIA card into your laptop. Check the README.Debian file in your named documentation (/usr/share/doc/bind/README.Debian) directory for more information about this issue. There have been many recent security problems concerning BIND, so switching the user is useful when possible. We will detail here the steps needed in order to do this, however, if you want to do this in an automatic way you might try the script provided in Sample script to change the default Bind installation., Appendix E.

Notice, in any case, that this only applies to BIND version 8. In the Debian packages for BIND version 9 (since the 9.2.1-5 version, available since sarge) the bind user is created and used by setting the OPTIONS variable in /etc/default/bind9. If you are using BIND version 9 and your name server daemon is not running as the bind user verify the settings on that file.

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 --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Notice that the user named will be quite restricted. If you want, for whatever reason, to have a less restrictive setup use: 

     adduser --system --ingroup named named

Now you can either edit /etc/init.d/bind with your favorite editor and change the line beginning with 

     start-stop-daemon --start

to[42] 

     start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Or you can change (create it if it does not exit) the default configuration file (/etc/default/bind for BIND version 8) and introduce the following: 

     OPTIONS="-u named -g named"

Change the permissions of files that are used by Bind, including /etc/bind/rndc.key: 

     -rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key

and where bind creates its pidfile, using, for example, /var/run/named instead of /var/run: 

     $ mkdir /var/run/named
     $ chown named.named /var/run/named
     $ vi /etc/named.conf
     [ ... update the configuration file to use this new location ...]
     options { ...
             pid-file "/var/run/named/named.pid";
     };
     [ ... ]

Also, in order to avoid running anything as root, change the reload line in the init.d script by substituting: 

     reload)
            /usr/sbin/ndc reload

to: 

     reload)
             $0 stop
             sleep 1
             $0 start

Note: Depending on your Debian version you might have to change the restart line too. This was fixed in Debian's bind version 1:8.3.1-2.

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[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

Voilą! Your named now does not run as root. If you want to read more information on why BIND does not run as non-root user on Debian systems, please check the Bug Tracking System regarding Bind, specifically Bug #50013: bind should not run as root and Bug #132582: Default install is potentially insecure, Bug #53550, Bug #52745, and Bug #128129. Feel free to contribute to the bug reports if you think you can add useful information.

5.7.3 Chrooting the name server

To achieve maximum BIND security, now build a chroot jail (see General chroot and suid paranoia, Section 5.10) around your daemon. There is an easy way to do this: the -t option (see the named(8) manpage or page 100 of Bind's 9 documentation (PDF)). This will make Bind chroot itself into the given directory without you needing to set up a chroot jail and worry about dynamic libraries. The only files that need to be in the chroot jail are: 

     dev/null
     etc/bind/       - should hold named.conf and all the server zones
     sbin/named-xfer - if you do name transfers
     var/run/named/  - should hold the PID and the name server cache (if
                       any) this directory needs to be writable by named user
     var/log/named   - if you set up logging to a file, needs to be writable
                       for the named user
     dev/log         - syslogd should be listening here if named is configured to
                       log through it

In order for your Bind daemon to work properly it needs permission in the named files. This is an easy task since the configuration files are always at /etc/named/. Take into account that it only needs read-only access to the zone files, unless it is a secondary or cache name server. If this is your case you will have to give read-write permissions to the necessary zones (so that zone transfers from the primary server work).

Also, you can find more information regarding Bind chrooting in the Chroot-BIND-HOWTO (regarding Bind 9) and Chroot-BIND8-HOWTO (regarding Bind 8). This same documents should be available through the installation of the doc-linux-text (text version) or doc-linux-html (HTML version). Another useful document is http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux.

If you are setting up a full chroot jail (i.e. not just -t) for Bind in Debian, make sure you have the following files in it[43]: 

     dev/log - syslogd should be listening here
     dev/null
     etc/bind/named.conf 
     etc/localtime
     etc/group - with only a single line: "named:x:GID:"
     etc/ld.so.cache - generated with ldconfig 
     lib/ld-2.3.6.so
     lib/libc-2.3.6.so
     lib/ld-linux.so.2 - symlinked to ld-2.3.6.so
     lib/libc.so.6 - symlinked to libc-2.3.6.so
     sbin/ldconfig - may be deleted after setting up the chroot
     sbin/named-xfer - if you do name transfers
     var/run/

And modify also syslogd listen on $CHROOT/dev/log so the named server can write syslog entries into the local system log.

If you want to avoid problems with dynamic libraries, you can compile bind statically. You can use apt-get for this, with the source option. It can even download the packages you need to properly compile it. You would need to do something similar to: 

     $ apt-get source bind
     # apt-get build-dep bind
     $ cd bind-8.2.5-2
       (edit src/port/linux/Makefile so CFLAGS includes the '-static'
        option)
     $ dpkg-buildpackage -rfakeroot -uc -us
     $ cd ..
     # dpkg -i bind-8.2.5-2*deb

After installation, you will need to move around the files to the chroot jail[44] you can keep the init.d scripts in /etc/init.d so that the system will automatically start the name server, but edit them to add --chroot /location_of_chroot in the calls to start-stop-daemon in those scripts or use the -t option for BIND by setting it in the OPTIONS argument at the /etc/default/bind (for version 8) or /etc/default/bind9 (for version 9) configuration file.

For more information on how to set up chroots see General chroot and suid paranoia, Section 5.10.

FIXME: Merge info from http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://www.cryptio.net/~ferlatte/config/ (Debian-specific), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html and http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.

5.8 Securing Apache

FIXME: Add content: modules provided with the normal Apache installation (under /usr/lib/apache/X.X/mod_*) and modules that can be installed separately in libapache-mod-XXX packages.

You can limit access to the Apache server if you only want to use it internally (for testing purposes, to access the doc-central archive, etc.) and do not want outsiders to access it. To do this use the Listen or BindAddress directives in /etc/apache/http.conf.

Using Listen: 

     Listen 127.0.0.1:80

Using BindAddress: 

     BindAddress 127.0.0.1

Then restart apache with /etc/init.d/apache restart and you will see that it is only listening on the loopback interface.

In any case, if you are not using all the functionality provided by Apache, you might want to take a look at other web servers provided in Debian like dhttpd.

The Apache Documentation provides information regarding security measures to be taken on Apache web server (this same information is provided in Debian by the apache-doc package).

More information on further restricting Apache by setting up a chroot jail is provided in Chroot environment for Apache, Appendix H.

5.8.1 Disabling users from publishing web contents

The default Apache installation in Debian permits users to publish content under the $HOME/public_html. This content can be retrieved remotely using an URL such as: http://your_apache_server/~user.

If you do not want to permit this you must change the /etc/apache/http.conf configuration file commenting out (in Apache 1.3) the following module: 

     LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

If you are using Apache 2.0 you must remove the file /etc/apache2/mods-enabled/userdir.load or restrict the default configuration by modifying /etc/apache2/mods-enabled/userdir.conf.

However, if the module was linked statically (you can list the modules that are compiled in running apache -l) you must add the following to the Apache configuration file: 

     Userdir disabled

An attacker might still do user enumeration, since the answer of the web server will be a 403 Permission Denied and not a 404 Not available. You can avoid this if you use the Rewrite module.

5.8.2 Logfiles permissions

Apache logfiles, since 1.3.22-1, are owned by user 'root' and group 'adm' with permissions 640. These permissions are changed after rotation. An intruder that accessed the system through the web server would not be able (without privilege escalation) to remove old log file entries.

5.8.3 Published web files

Apache files are located under /var/www. Just after installation the default file provides some information on the system (mainly that it's a Debian system running Apache). The default webpages are owned by user root and group root by default, while the Apache process runs as user www-data and group www-data. This should make attackers that compromise the system through the web server harder to deface the site. You should, of course, substitute the default web pages (which might provide information you do not want to show to outsiders) with your own.

5.9 Securing finger

If you want to run the finger service first ask yourself if you need to do so. If you do, you will find out that Debian provides many finger daemons (output from apt-cache search fingerd):

ffingerd is the recommended finger daemon if you are going to use it for a public service. In any case, you are encouraged to, when setting it up through inetd, xinetd or tcpserver to: limit the number of processes that will be running at the same time, limit access to the finger daemon from a given number of hosts (using tcp wrappers) and having it only listening to the interface you need it to be in.

5.10 General chroot and suid paranoia

chroot is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). If you do not trust a user or a service, you can create a modified root environment for him. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. But then, even if the user does something malicious, the scope of the damage is limited to the jail.

Many services running as daemons could benefit from this sort of arrangement. The daemons that you install with your Debian distribution will not come, however, chrooted[45] per default.

This includes: name servers (such as bind), web servers (such as apache), mail servers (such as sendmail) and ftp servers (such as wu-ftpd). It is probably fair to say that the complexity of BIND is the reason why it has been exposed to a lot of attacks in recent years (see Securing BIND, Section 5.7).

However, Debian does provide some software that can help set up chroot environments. See Making chrooted environments automatically, Section 5.10.1.

Anyway, if you run any service on your system, you should consider running them as secure as possible. This includes: revoking root privileges, running in a restricted environment (such as a chroot jail) or replacing them with a more secure equivalent.

However, be forewarned that a chroot jail can be broken if the user running in it is the superuser. So, you need to make the service run as a non-privileged user. By limiting its environment you are limiting the world readable/executable files the service can access, thus, you limit the possibilities of a privilege escalation by use of local system security vulnerabilities. Even in this situation you cannot be completely sure that there is no way for a clever attacker to somehow break out of the jail. Using only server programs which have a reputation for being secure is a good additional safety measure. Even minuscule holes like open file handles can be used by a skilled attacker for breaking into the system. After all, chroot was not designed as a security tool but as a testing tool.

5.10.1 Making chrooted environments automatically

There are several programs to chroot automatically servers and services. Debian currently (accepted in May 2002) provides Wietse Venema's chrootuid in the chrootuid package, as well as compartment and makejail. These programs can be used to set up a restricted environment for executing any program (chrootuid enables you to even run it as a restricted user).

Some of these tools can be used to set up the chroot environment easily. The makejail program for example, can create and update a chroot jail with short configuration files (it provides sample configuration files for bind, apache, postgresql and mysql). It attempts to guess and install into the jail all files required by the daemon using strace, stat and Debian's package dependencies. More information at http://www.floc.net/makejail/. Jailer is a similar tool which can be retrieved from http://www.balabit.hu/downloads/jailer/ and is also available as a Debian package.

5.11 General cleartext password paranoia

You should try to avoid any network service which sends and receives passwords in cleartext over a net like FTP/Telnet/NIS/RPC. The author recommends the use of ssh instead of telnet and ftp to everybody.

Keep in mind that migrating from telnet to ssh, but using other cleartext protocols does not increase your security in ANY way! Best would be to remove ftp, telnet, pop, imap, http and to supersede them with their respective encrypted services. You should consider moving from these services to their SSL versions, ftp-ssl, telnet-ssl, pop-ssl, https ...

Most of these above listed hints apply to every Unix system (you will find them if reading any other hardening-related document related to Linux and other Unices).

5.12 Disabling NIS

You should not use NIS, the Network Information Service, if possible, because it allows password sharing. This can be highly insecure if your setup is broken.

If you need password sharing between machines, you might want to consider using other alternatives. For example, you can setup an LDAP server and configure PAM on your system in order to contact the LDAP server for user authentication. You can find a detailed setup in the LDAP-HOWTO (/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz).

You can read more about NIS security in the NIS-HOWTO (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).

FIXME (jfs): Add info on how to set this up in Debian.

5.13 Securing RPC services

You should disable RPC if you do not need it.

Remote Procedure Call (RPC) is a protocol that programs can use to request services from other programs located on different computers. The portmap service controls RPC services by mapping RPC program numbers into DARPA protocol port numbers; it must be running in order to make RPC calls.

RPC-based services have had a bad record of security holes, although the portmapper itself hasn't (but still provides information to a remote attacker). Notice that some of the DDoS (distributed denial of service) attacks use RPC exploits to get into the system and act as a so called agent/handler.

You only need RPC if you are using an RPC-based service. The most common RPC-based services are NFS (Network File System) and NIS (Network Information System). See the previous section for more information about NIS. The File Alteration Monitor (FAM) provided by the package fam is also an RPC service, and thus depends on portmap.

NFS services are quite important in some networks. If that is the case for you, then you will need to find a balance of security and usability for your network (you can read more about NFS security in the NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz)).

5.13.1 Disabling RPC services completely

Disabling portmap is quite simple. There are several different methods. The simplest one in a Debian 3.0 system and later releases is to uninstall the portmap package. If you are running an older Debian version you will have to disable the service as seen in Disabling daemon services, Section 3.6.1, because the program is part of the netbase package (which cannot be de-installed without breaking the system).

Notice that some desktop environments (notably, GNOME) use RPC services and need the portmapper for some of the file management features. If this is your case, you can limit the access to RPC services as described below.

5.13.2 Limiting access to RPC services

Unfortunately, in some cases removing RPC services from the system is not an option. Some local desktop services (notably SGI's fam) are RPC based and thus need a local portmapper. This means that under some situations, users installing a desktop environment (like GNOME) will install the portmapper too.

There are several ways to limit access to the portmapper and to RPC services:

5.14 Adding firewall capabilities

The Debian GNU/Linux operating system has the built-in capabilities provided by the Linux kernel . If you install a recent Debian release (default kernel installed is 2.6) you will have iptables (netfilter) firewalling available[46].

5.14.1 Firewalling the local system

You can use firewall rules as a way to secure the access to your local system and, even, to limit the outbound communications made by it. Firewall rules can also be used to protect processes that cannot be properly configured not to provide services to some networks, IP addresses, etc.

However, this step is presented last in this manual basically because it is much better not to depend solely on firewalling capabilities in order to protect a given system. Security in a system is made up of layers, firewalling should be the last to include, once all services have been hardened. You can easily imagine a setup in which the system is solely protected by a built-in firewall and an administrator blissfully removes the firewall rules for whatever reason (problems with the setup, annoyance, human error...), this system would be wide open to an attack if there were no other hardening in the system to protect from it.

On the other hand, having firewall rules on the local system also prevents some bad things from happening. Even if the services provided are configured securely, a firewall can protect from misconfigurations or from fresh installed services that have not yet been properly configured. Also, a tight configuration will prevent trojans calling home from working unless the firewalling code is removed. Note that an intruder does not need superuser access to install a trojan locally that could be remotely controlled (since binding on ports is allowed if they are not priviledged ports and capabilities have not been removed).

Thus, a proper firewall setup would be one with a default deny policy, that is:

5.14.2 Using a firewall to protect other systems

A Debian firewall can also be installed in order to protect, with filtering rules, access to systems behind it, limiting their exposure to the Internet. A firewall can be configured to prevent access from systems outside of the local network to internal services (ports) that are not public. For example, on a mail server, only port 25 (where the mail service is being given) needs to be accessible from the outside. A firewall can be configured to, even if there are other network services besides the public ones running in the mail server, throw away packets (this is known as filtering) directed towards them.

You can even set up a Debian GNU/Linux box as a bridge firewall, i.e. a filtering firewall completely transparent to the network that lacks an IP address and thus cannot be attacked directly. Depending on the kernel you have installed, you might need to install the bridge firewall patch and then go to 802.1d Ethernet Bridging when configuring the kernel and a new option netfilter ( firewalling ) support. See the Setting up a bridge firewall, Appendix D for more information on how to set this up in a Debian GNU/Linux system.

5.14.3 Setting up a firewall

The default Debian installation, unlike other Linux distributions, does not yet provide a way for the administrator to setup a firewall configuration throughout the default installation but you can install a number of firewall configuration packages (see Using firewall packages, Section 5.14.3.1).

Of course, the configuration of the firewall is always system and network dependant. An administrator must know beforehand what is the network layout and the systems he wants to protect, the services that need to be accessed, and whether or not other network considerations (like NAT or routing) need to be taken into account. Be careful when configuring your firewall, as Laurence J. Lane says in the iptables package:

The tools can easily be misused, causing enormous amounts of grief by completely crippling network access to a system. It is not terribly uncommon for a remote system administrator to accidentally lock himself out of a system hundreds or thousands of miles away. One can even manage to lock himself out of a computer who's keyboard is under his fingers. Please, use due caution.

Remember this: just installing the iptables (or the older firewalling code) does not give you any protection, just provides the software. In order to have a firewall you need to configure it!

If you do not have a clue on how to set up your firewall rules manually consult the Packet Filtering HOWTO and NAT HOWTO provided by iptables for offline reading at /usr/share/doc/iptables/html/.

If you do not know much about firewalling you should start by reading the Firewalling and Proxy Server HOWTO, install the doc-linux-text package if you want to read it offline. If you want to ask questions or need help setting up a firewall you can use the debian-firewall mailing list, see http://lists.debian.org/debian-firewall. Also see Be aware of general security problems, Section 2.2 for more (general) pointers on firewalls. Another good iptables tutorial is http://iptables-tutorial.frozentux.net/iptables-tutorial.html.

5.14.3.1 Using firewall packages

Setting up manually a firewall can be complicated for novice (and sometimes even expert) administrators. However, the free software community has created a number of tools that can be used to easily configure a local firewall. Be forewarned that some of these tools are oriented more towards local-only protection (also known as personal firewall) and some are more versatile and can be used to configure complex rules to protect whole networks.

Some software that can be used to set up firewall rules in a Debian system is:

Lots of other iptables frontends come with Debian; an extensive list comparing the different packages in Debian is maintained at the Firewalls page on the Debian wiki.

Notice that some of the packages outlined previously will introduce firewalling scripts to be run when the system boots. Test them extensively before rebooting or you might find yourself locked from the box. If you mix different firewalling packages you can have undesired effects, usually, the firewalling script that runs last will be the one that configures the system (which might not be what you intend). Consult the package documentation and use either one of these setups.

As mentioned before, some programs, like firestarter, guarddog and knetfilter, are administration GUIs using either GNOME or KDE (last two). These applications are much more user-oriented (i.e. for home users) than some of the other packages in the list which might be more administrator-oriented. Some of the programs mentioned before (like bastille) are focused at setting up firewall rules to protect the host they run in but are not necessarily designed to setup firewall rules for firewall hosts that protect a network (like shorewall or fwbuilder).

There is yet another type of firewall application: application proxies. If you are looking into setting up an enterprise-level firewall that does packet filtering and provides a number of transparent proxies that can do fine-grain traffic analysis you should consider using zorp, which provides this in a single program. You can also manually setup this type of firewall host using the proxies available in Debian for different services like for DNS using bind (properly configured), dnsmasq, pdnsd or totd for FTP using frox or ftp-proxy, for X11 using xfwp, for IMAP using imapproxy, for mail using smtpd, or for POP3 using p3scan. For other protocols you can either use a generic TCP proxy like simpleproxy or a generic SOCKS proxy like dante-server, tsocks or socks4-server. Typically, you will also use a web caching system (like squid) and a web filtering system (like squidguard or dansguardian).

5.14.3.2 Manual init.d configuration

Another possibility is to manually configure your firewall rules through an init.d script that will run all the iptables commands. Take the following steps:

This is the sample firewall script: 

     #!/bin/sh
     # Simple example firewall configuration.
     #
     # Caveats:
     # - This configuration applies to all network interfaces
     #   if you want to restrict this to only a given interface use
     #   '-i INTERFACE' in the iptables calls.
     # - Remote access for TCP/UDP services is granted to any host, 
     #   you probably will want to restrict this using '--source'.
     #
     # chkconfig: 2345 9 91
     # description: Activates/Deactivates the firewall at boot time
     #
     # You can test this script before applying with the following shell
     # snippet, if you do not type anything in 10 seconds the firewall
     # rules will be cleared.
     #---------------------------------------------------------------
     #  while true; do test=""; read  -t 20 -p "OK? " test ; \
     #  [ -z "$test" ] && /etc/init.d/myfirewall clear ; done
     #---------------------------------------------------------------
     
     PATH=/bin:/sbin:/usr/bin:/usr/sbin
     
     # Services that the system will offer to the network
     TCP_SERVICES="22" # SSH only
     UDP_SERVICES=""
     # Services the system will use from the network
     REMOTE_TCP_SERVICES="80" # web browsing
     REMOTE_UDP_SERVICES="53" # DNS
     # Network that will be used for remote mgmt
     # (if undefined, no rules will be setup)
     # NETWORK_MGMT=192.168.0.0/24
     # Port used for the SSH service, define this is you have setup a
     # management network but remove it from TCP_SERVICES
     # SSH_PORT="22"
     
     if ! [ -x /sbin/iptables ]; then  
         exit 0
     fi
     
     fw_start () {
     
       # Input traffic:
       /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
       # Services
       if [ -n "$TCP_SERVICES" ] ; then
       for PORT in $TCP_SERVICES; do
         /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
       done
       fi
       if [ -n "$UDP_SERVICES" ] ; then
       for PORT in $UDP_SERVICES; do
         /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
       done
       fi
       # Remote management
       if [ -n "$NETWORK_MGMT" ] ; then
         /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT
       else 
         /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT}  -j ACCEPT
       fi
       # Remote testing
       /sbin/iptables -A INPUT -p icmp -j ACCEPT
       /sbin/iptables -A INPUT -i lo -j ACCEPT
       /sbin/iptables -P INPUT DROP
       /sbin/iptables -A INPUT -j LOG
     
       # Output:
       /sbin/iptables -A OUTPUT -j ACCEPT -o lo 
       /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
       # ICMP is permitted:
       /sbin/iptables -A OUTPUT -p icmp -j ACCEPT
       # So are security package updates:
       # Note: You can hardcode the IP address here to prevent DNS spoofing
       # and to setup the rules even if DNS does not work but then you 
       # will not "see" IP changes for this service:
       /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
       # As well as the services we have defined:
       if [ -n "$REMOTE_TCP_SERVICES" ] ; then
       for PORT in $REMOTE_TCP_SERVICES; do
         /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT
       done
       fi
       if [ -n "$REMOTE_UDP_SERVICES" ] ; then
       for PORT in $REMOTE_UDP_SERVICES; do
         /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT
       done
       fi
       # All other connections are registered in syslog
       /sbin/iptables -A OUTPUT -j LOG
       /sbin/iptables -A OUTPUT -j REJECT 
       /sbin/iptables -P OUTPUT DROP
       # Other network protections
       # (some will only work with some kernel versions)
       echo 1 > /proc/sys/net/ipv4/tcp_syncookies
       echo 0 > /proc/sys/net/ipv4/ip_forward 
       echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
       echo 1 > /proc/sys/net/ipv4/conf/all/log_martians 
       echo 1 > /proc/sys/net/ipv4/ip_always_defrag
       echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
       echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
       echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
       echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
     
     }
     
     fw_stop () {
       /sbin/iptables -F
       /sbin/iptables -t nat -F
       /sbin/iptables -t mangle -F
       /sbin/iptables -P INPUT DROP
       /sbin/iptables -P FORWARD DROP
       /sbin/iptables -P OUTPUT ACCEPT
     }
     
     fw_clear () {
       /sbin/iptables -F
       /sbin/iptables -t nat -F
       /sbin/iptables -t mangle -F
       /sbin/iptables -P INPUT ACCEPT
       /sbin/iptables -P FORWARD ACCEPT
       /sbin/iptables -P OUTPUT ACCEPT
     }
     
     
     case "$1" in
       start|restart)
         echo -n "Starting firewall.."
         fw_stop 
         fw_start
         echo "done."
         ;;
       stop)
         echo -n "Stopping firewall.."
         fw_stop
         echo "done."
         ;;
       clear)
         echo -n "Clearing firewall rules.."
         fw_clear
         echo "done."
         ;;
       *)
         echo "Usage: $0 {start|stop|restart|clear}"
         exit 1
         ;;
       esac
     exit 0

Instead of including all of the iptables rules in the init.d script you can use the iptables-restore program to restore the rules saved using iptables-save. In order to do this you need to setup your rules, save the ruleset under a static location (such as /etc/default/firewall)

5.14.3.3 Configuring firewall rules through ifup

You can use also the network configuration in /etc/network/interfaces to setup your firewall rules. For this you will need to:

You can optionally also setup a set of rules to be applied when the network interface is down creating a set of rules, saving it in /etc/iptables.down.rules and adding this directive to the interface configuration: 

         post-down iptables-restore < /etc/iptables.down.rules

For more advanced firewall configuration scripts through ifupdown you can use the hooks available to each interface as in the *.d/ directories called with run-parts (see run-parts(8)).

5.14.3.4 Testing your firewall configuration

Testing your firewall configuration is as easy, and as dangerous, as just running your firewall script (or enabling the configuration you defined in your firewall configuration application). However, if you are not careful enough and you are configuring your firewall remotely (like through an SSH connection) you could lock yourself out.

There are several ways to prevent this. One is running a script in a separate terminal that will remove the firewall configuration if you don't feed it input. An example of this is: 

     $  while true; do test=""; read  -t 20 -p "OK? " test ; \
       [ -z "$test" ] && /etc/init.d/firewall clear ; done

Another one is to introduce a backdoor in your system through an alternate mechanism that allows you to either clear the firewall system or punch a hole in it if something goes awry. For this you can use knockd and configure it so that a certain port connection attempt sequence will clear the firewall (or add a temporary rule). Even though the packets will be dropped by the firewall, since knockd binds to the interface and sees you will be able to work around the problem.

Testing a firewall that is protecting an internal network is a different issue, you will want to look at some of the tools used for remote vulnerability assessment (see Remote vulnerability assessment tools, Section 8.1) to probe the network from the outside in (or from any other direction) to test the effectiveness of the firewall configuation.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]

Securing Debian Manual


Version: 3.12, Mon, 07 Jan 2008 19:32:39 +0100

Javier Fernández-Sanguino Peña [email protected]
Authors, Section 1.1