[vox-tech] DNS and security

[Rick Moen]

Quoting Cylar Z (cylarz at yahoo.com):

> I'm a fairly new Linux admin, running Fedora Core from
> Redhat. 

Hi, Matt.  For a good overview, please see Linux Journal editor Don
Marti's overview, which I just saw him mention on a different Linux
mailing list:  http://zgp.org/~dmarti/blosxom/tips/new-server.html

> 1. Outgoing DNS isn't working properly on my server.  The box will
> respond properly to incoming http requests (and even allowed me to
> host 2 virtual domains, which also respond properly). However, it does
> NOT surf the web from the console or ping by domain name. It WILL ping
> by IP so I know the issue is DNS and not my actual connection per se.
> How do I put in the DNS info in Fedora Core? I tried logging on as
> root, typing "setup" and entering the IP's in the designated spaces,
> but no luck. Is there another way?

The IP-address locations of the DNS servers your box will be consulting
are always recorded in /etc/resolv.conf, the configuration file of your
host's DNS resolver library (i.e., of the DNS client software your box
uses to deal with DNS questions that must be referred to a DNS daemon
running somewhere).

Here's my own server's /etc/resolv.conf:

  search linuxmafia.com deirdre.org
  nameserver 198.144.192.2
  nameserver 198.144.192.4
  nameserver 198.144.195.186

Distributions differ in what tools they prefer you to use, in editing
your system configuration files.  Of course, you can always ignore those
intentions and use $MY_FAVOURITE_TEXT_EDITOR -- which is what I
personally tend to do -- but your Fedora documentation may well have
something to say about that.


> 2. In the interest of system security, I want to run the absolute
> minimum number of daemons/services. Which ones do I really, really
> need?

That's an excellent and really important question.

Many people approach this question from a functional perspective.  That
is, they say, if you want to determine which daemons you need, try
switching each of them off, in turn, and find out if anything you care
about breaks.  Of course, in a strict sense, nobody but you can tell you
what your box needs to run, anyway, because only you know what roles
your box needs to fulfill.

> So far I've established that I need httpd, sshd, sendmail, xinetd, and
> possibly cron.

Please note that "xinetd" is an example of what is called a
"superserver", i.e., a server whose purpose is to load and launch other
servers (daemons) under its control and supervision, in part so that
those servers don't need to be loaded into RAM all the time, but instead
can be loaded only when there's an incoming request for them.

One consequence of this is that xinetd has its own configuration file,
/etc/xinetd.conf, and a directory of configuration files for each
supervised server, /etc/xinetd.d/ .  The files in /etc/xinetd.d/
specify, among other things, whether xinetd shall be willing to launch
this daemon at all, if there's an incoming request.

Here, for example, is /etc/xinetd.d/chargen , with the option
"disable=yes":

  # default: off
  # description: An xinetd internal service which generate characters. \
  # The xinetd internal service which continuously generates characters \
  # until the connection is dropped.  The characters look something like
  # this: \
  #   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg
  #   \
  # This is the tcp version.
  service chargen
  {
          disable = yes
          type            = INTERNAL
          id              = chargen-stream
          socket_type     = stream
          protocol        = tcp
          user            = root
          wait            = no
  }

Given that you've elected to leave xinetd running, it's in your interest
to go through each of the files in /etc/xinetd.d/ individually, and
decide for each one whether you can imagine any reason why you want to
offer up that daemon as an available service to remote machines.

I picked "chargen" (a character-stream generator that, if running, spews
out a stream of ASCII on TCP or UDP port 19; really, that's _all_ it
does) as an example because it examplifies pretty well the point that
many xinetd services are leftover antiques of no real use to most people
-- and who knows what mischief someone might carry out using them?  The
paranoiac's view would be:  If you don't know why you need a running
daemon, shut it off until and unless you determine otherwise.

By the way, your system almost certainly needs to run cron because it
supervises periodic housekeeping scripts that need to be run at specific
regular times.  Fortunately, it is not network-accessible from
elsewhere.

>  Are there any others that are suggested that I be running? 

And the answer to that depends entirely on what the machine needs to do.

> This server responds to web requests and lets me SSH in remotely. (I
> don't use Telnet.) That's about all it needs to do.

This begs the question of why you say it also needs to run xinetd.  
You might, or you might not.  It depends on whether you have any use for
any of the couple-dozen minor services xinetd is capable of offering.
You decided.
 
> Also, is FTP a security risk, or is it safe to leave this port open?

This is a controversial question.

Many people feel that ftp is redundant in an era of pervasive http
implementations.  (Note that http is a simpler protocol and doesn't have
the slightly problematic feature of using a control TCP port as well 
as a data-transmission TCP port.  That feature of ftp tends to make it
slightly difficult to control at IP-filtering firewalls, and you end up
having to adopt palliative measures like running all ftp sessions in 
what is called "passive ftp mode".)

I personally got a little tired of hearing that stated as a blanket
truth, some years ago, and so collected this list of reasons why in some
cases running an ftp daemon might have distinctive advantages:

"FTP Justification" on http://linuxmafia.com/kb/Network_Other

There is bad security history behind the two most (historically) popular
ftp daemons on *ix, namely wu-ftpd[1] and Proftpd.  The entire concept of
ftp daemons has accordingly become somewhat tarred by that unfortunate 
record -- unnecessarily.  I have my own view about some ftp daemons that
are, unlike those two, well designed and written:

"FTP Daemons" on http://linuxmafia.com/kb/Network_Other

You will note in the latter file a key distinction.  There are two
distinct classes of ftp service:

o  anonymous ftp
o  ftp for regular users

"Anonymous" ftp is public, regular-http-like access, in which the user 
logs in as username "anonymous" or "ftp", and the password can be set to
anything at all and is ignored (though, by convention, the anonymous
user's password should be set to his/her e-mail address).  If you have
used "ftp://somehost.somedomain/somepath/" URLs in your Web browser,
you've used anonymous ftp (probably) without realising it.

ftp for regular users is the general case, in which the remote user
specifies his/her username and password.  In classic (non-encrypted)
ftpd implementations, this username/password pair was the user's 
login (shell) authentication tokens, and those were transmitted in
cleartext across the open network -- undesirable for the same reasons
why it is with telnet or (regular) POP3.

I'm personally a big fan of anonymous ftp, and always run a _carefully
chosen_ ftpd in anonymous-only mode on my servers.  I always choose to
_avoid_ running ftp for regular users:  When I or my users wish to move
files on/off my server, the standard method recommended is scp.


There are two other wrinkles you should be aware of: 

1.  tcp wrappers:

Traditionally, most *ix daemons have been compiled with a dynamic
library dependency on Wiese Venema's extremely useful "TCP Wrappers" 
library, libwrap, e.g. see this list of dependencies for my MySQL
daemon:

[rick at linuxmafia]
~ $ ldd /usr/sbin/mysqld
        librt.so.1 => /lib/librt.so.1 (0x4001e000)
        libwrap.so.0 => /lib/libwrap.so.0 (0x40030000)
        libdl.so.2 => /lib/libdl.so.2 (0x40039000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4003d000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4008e000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x400a0000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x400cd000)
        libm.so.6 => /lib/libm.so.6 (0x400e2000)
        libc.so.6 => /lib/libc.so.6 (0x40104000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

("ldd" is a utility to List Dynamic Dependencies for any binary
executable or lib.)

The hook to libwrap means that you can control what remote hosts are
allowed to connect through to the "wrapped" daemon.  The configuration
files for that facility are the "hostaccess" files /etc/hosts.allow and
/etc/hosts.deny .

I vaguely recall that systems with the xinetd superserver do not use
libwrap, probably because TCP Wrappers is a companion piece to the
_other_ (and older, and simpler) common superserver, "inetd".
Basically, if memory serves, xinetd aims to replicate the functionality
of both TCP Wrappers (libwrap) and inetd, plus make available some extra
optional tricks not possible with that combination.  You will have to 
look up docs if you want to learn more -- but, of a certainty, xinetd's 
configuration files can do TCP Wrappers's tricks.

Anyhow, I'm describing TCP Wrappers to help my answer be useful for
Linux-administering readers generally, and not just to people running
Fedora Core or other xinetd-using distributions.

2.  "Firewalling" (IP filtering) scripts.  These act at the ingress,
egress, and forwarding (if any) points of your kernel's networking code, 
and allow you to minutely specify what sort of connections shall be 
allowed in and out of your machine, thus forming an exterior-layer 
control over what individual daemons are allowed to do, irrespective 
of those daemons' own configuration.


This is obviously a large topic, but perhaps the above will help you for
starters.

[1] For many years, Red Hat's distributions furnished wu-ftpd as their
only (and recommended) ftp daemon.  I and others kept sending in
suggestions that this was a very bad idea, and in recent releases
they've taken our advice and switched to vs-ftpd, which I happen to
recommend highly.