[ назад ] [ Содержание ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ вперед ]

Securing Debian HOWTO
Глава 4 - Securing services running on your system


4.1 Securing ssh

If you are still running telnet instead of ssh, you should take a break from th is 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 no w. 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 суперпользователь and use alternative methods to become суперпользователь instead, like su or sudo. Finally, the sshd_config file, /etc/ssh, should be modified to increase security as well: PermitRootLogin No Try not to permit Root Login wherever possible. If anyone wants to become суперпользователь via ssh, now two logins are needed and the суперпользователь password cannot be brute forced via SSH. Listen 666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs. PermitEmptyPasswords no 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". PasswordAuthentication yes 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.


4.2 Realize the insecurity of X over network

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. Of course, even this can be disabled from /etc/ssh/ssh_config. For best security, if you do not need X access from other machines, is to switc h off the binding on tcp port 6000 simply by typing: startx -- -nolisten tcp


4.3 The lpd and lprng issue

Imagine, you arrive at work, and the printer is spitting out endless amounts of paper because someone is DoS'ing your line printer daemon. Nasty, isn't it? So keep your printer servers specially secure. FIXME. Content missing. (No lpr experience)


4.4 Защита почты

Чтение/прием почты - это наиболее распространенный вид соединений с открытыми паролями. Если для приема почты вы используете POP3 или IMAP, то ваши пароли идут по сети в открытом виде, и почти любой может их перехватить. Лучше использовать для приема почты SSL (Secure Socket Layer). Другая альтернатива - это ssh, если у вас есть доступ к оболочке на вашей машине. Вот базовый 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'

Строка preconnect - важная строка. Она запускает ssh-сессию и создает необходимый туннель, который автоматически перенаправляет уже зашифрованные соединения в localhost порт 1236 на почтовый сервер imap. Также можно использовать fetchmail с ssl.

Если вы хотите работать с шифрованными почтовыми сервисами наподобие POP и IMAP, то запустите команду apt-get install stunnel и запускайте ваши демоны вот так: stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd Эта команда запускает из себя указанный демон (-l) на порту (-d) и использует сертификацию ssl (-p).


4.5 Защита BIND

В стандартной установке Debian демон доменных имен, BIND, запускается от имени суперпользователя и группы суперпользователя. Можно легко запустить BIND от ID (UID) другого пользователя. Однако, если BIND будет запущен от другого пользователя, то BIND не сможет определить новые интерфейсы автоматически. Например, если вы вставляете PCMCIA-карточку в свой ноутбук. Подробнее этот вопрос описан в файле README.Debian в каталоге документации named. Есть и другие проблемы безопасности, связанные с BIND, потому переключиться при возможности на другого пользователя крайне полезно.

Чтобы запустить BIND от другого пользователя, сначала создайте отдельную группу и пользователя для него (запускать от nobody и nogroup сервисы, который нежелательно запускать от суперпользователя, - не очень хорошая идея). В данном примере были использованы пользователь и группа 'named'. Создаем их:

     # addgroup named
     # adduser --system --ingroup named named

Теперь редактируем /etc/init.d/bind вашим любимым редактором и заменяем строку, начинающуюся с

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

Остается только перезапустить bind командой '/etc/init.d/bind restart', и затем убедиться, что в вашем файле syslog есть записи типа:

     Sep  4 15:11:08 nexus named[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

Вуаля! Ваш named теперь работает не от суперпользователя. Чтобы еще больше защитить BIND, сделайте для этого демона chroot (См. 3.13). # I'm not sure about this, shouldn't bind files be chown'ed to # the groups created. This should be stated. jfs


[ назад ] [ Содержание ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ вперед ]

Securing Debian HOWTO

v1.1 14 February 2003Thu, 7 Dec 2000 19:10:13 +0100
Alexander Reelsen ar@rhwd.net
Перевод: Ильгиз Кальметьев, ilgiz@mail.rb.ru



Наш баннер
Вы можете установить наш баннер на своем сайте или блоге, скопировав этот код:
RSS новости