На главную | Поиск
Вы находитесь в Хранилище файлов Белорусской цифровой библиотеки

Securing RedHat 5.X Part VII - Securing specific services

By Kurt Seifried Rev 0.1


Securing specific services - Preamble (S07.C0P)


Services in Linux typically share several common methods for securing them. Denying access to them for all but trusted hosts generally helps, as well encrypting the network traffic will prevent sniffing/etc. One of the main problems with encrypting traffic is that it (currently) is done at the application level, or requires modifications to the application to work right (point in case: kerberoes). Kerberoes is quite good however try getting the server software setup properly, and all the client software, this can be a major challenge. I personally don't bother, simply have one account for admin, use ssh, and have other accounts with mail only/etc access. Until we get proper IPSec support (you listening redhat?) like OpenBSD (OpenBSD ships with IPSec) encrypting network data will be a greater hassle then it should be.

I will cover various encryption options available for services, however sniffing tends to be overrated IMNHO. There are definately environments where sniffing is a problem (university labs, etc) but accross major network links (typically fiberoptic, etc) sniffing is not an issue. This is why I do not place to to much importance on it. Besides, if they can watch your traffic, they can intercept it, deny it, mangle it, etc.

One of the major advances (IMNHO) of the 2.1 and future 2.2 kernels for Linux is the ability to set reserved ports (<1024) for non root users. Ie you will be able to assign port 22 to sshduser, port 25 to smtpuser, port 119 to nntpuser, etc. This will decrease enormously the number of network daemons that need anything to run as root, really the only network related things running as root need to be sendmail (mbox delivery), login for remote access, and that's really about it. Expect this page and most network daemons for Linux to change a lot when 2.2 hits the streets.


Contact Kurt Seifried, All rights reserved Kurt Seifried 1998, content and information may not be reposted physically or electronically without the express permission of the author, this includes but is not limited to www mirror sites, email, usenet news, etc.