Quoting Cylar Z ([EMAIL PROTECTED]): > 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:;<=>[EMAIL PROTECTED] # \ # 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: [EMAIL PROTECTED] ~ $ 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. _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
