В случай на използване на отдалечени връзки е необходимо да се замеслем за безопасността на предаваните данни. Стандартните средства rlogin, rcp, telnet и др. не обезпечават необходимото ниво на криптоустойчивост. При използване на по-горе поместените програми паролите се предават в незашрован вид и могат да бъдат прихванати от всеки анализатор на трафика, например snort. Най-разпространеното средство за защита на отдалечени връзки е OpenSSH, шифриращ целия трафик (включително и паролите). С това се обезпечава ефективно противодействието на атаки от типа прихващане на връзки или прослушване.     OpenSSH включва в себе си ssh (заменя rlogin и telnet), scp (заменя rcp и ftp). На страната на сървъра се пуска демон sshd. Също в пакета влиза генератор на ключове ключей ssh_keygen. OpenSSH използва алгоритъм за шифромане 3DES (троен DES) и BlowFish (бързо блоково шифриране) процесът на шифриране се стартира преди началото на идентификацията. Заедно с трафика конзолите на шифрирането подлагат данните, ппредавани от отдалечения дисплей Х11. Сървърът установява DISPLAY и предава които и да е връзки Х11 по безопасен канал.
   
Методиката за идентификация на OpenSSH е доста сложна: на основата на .rhosts и RSA, симетричния ключ, а също и Kerberos. За обмен на ключовете по време на сеанса на работната станция се пуска агент. Отдалеченият ползвател получава ключовете при установяване на връзката със сървъра, като по този начин отпада необходимостта от съхранение на ключовете на отдалечената машина.
 
OpenSSH поддържа протоколи с определени версии в зависимост от неговата версия и позволява да се организират защитене канали за всички търговски версии ssh под UNIX, Windows и др. Протоколът вместо алгоритъм RSA използва по-устойчивият - DSA. Следва да отбележим, че преди шифроването се осъществява компресия на предаваните данни, като повишава скоростта на предаване на данни на бавни комутируеми линии.

Безопасност в WWW

FTP

    FTP-сървърът представлява сам по себе си потенциална дупка в системта на безопасност на мрежата. Затова ако не се планира организация на архивите, библиотеките, т.е. съхранение на данни, достъпни за широко ползване, по-добре въобще да не се пуска FTP-сървър. Поради широкато разпространеност на тази служба следва да се отдели особено внимание. Трябва веднага да се отбележи, че всички FTP-сървъри са уязвими в една или друга степен. Но различията в реализацията и конфигурацията се осъществяват в едни случаи в отказ от обслужване, а в други - в пълен контрол над хоста. При това поради особеностите на протокола FTP могат да бъдат поразени както сървърите, така и клиентите. За начало трябва да се махне tftpd. Даденият демон позволява да се организира предаването на файловете без контрол на правата на достъп. За организация на FTP-архивите трябва да се използват стандартни сървъри wu-ftpd или ftpd от дистрибутивите Linux. Въобще най-подходящият е ftpd-BSD.
FTP-сървърите са достатъчно неустойчиви към DoS атаки. Например ProFTPD и wu-ftpdможе да се "......", като се опита да създаде 10-20 каталога с дължина на имената 100 символа.
    Един от проблемите на FTP-сървърите се явява отсъствието на проверка........... на източниците на пакетите. Работата е в следното: при установяване на връзка сървърът прослушва един от ТСР порторвете, съобщава номерът му на клиента, след това клиентът открива указания порт и започва предаването на данните. Това се нарича пасивен режим. При активния режим ТСР портът назначава клиент, а сървърът открива връзка от порт 20 на порт, назначен от клиента. Тъй като в процеса на сеанс............. не се проверява, то е възможна атака от следния вид: на открития порт периодически се отправят запитвания за ТСР връзка. След като връзката е установена, произтича промяна на клиента. Уязвимост към дадената атака демонстрират всички ftpd-сървъри.

WWW

    Безбройни са статиите за безопасност на WWW-сървърите. Реализацията на най-популярния от тях - Apache - под Linux не се отличава от версията под другите видове Unix-системи, затова приведените примери практически са за всичките ОС.     Примерите са дадени за Apache на платформа RedHat. По подразбиране Apache се стартира под root и прослушва 80 ТСР порт. При постъпване на запитване за връзка с помощта на fork() се поражда нов процес и сървърът се възвръща към прослушване на порта. Новият процес изменя ID'то на ползвателя на nobody.     Всички действия свързани с обработката на запитванията, такива като изпълнение на CGI- сценария или SSH се изпълняват под nobody.
    За удобство на администрирането по-добре е да се създаде за пускането на httpd ползвател www (и група www) и да му се назначи личен каталог и коренов каталог на дървото с документите. По-долу е приведен пример на дървото с документите и указаните права на достъп:
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/
drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/
-rwx------ 1 www www 109674 May 8 23:58 httpd
drwxr-xr-x 2 www www 1024 Aug 8 00:01 htdocs/
drwxr-xr-x 2 www www 1024 Jun 3 21:15 icons/
drwxr-x--- 2 www www 1024 May 4 22:23 logs/
В каталога htdocs всички файлове трябва да имат атрибути "само четене".
Достатъчно ефективно се явява изпълнението на командата chroot, изменяща кореновия каталог. Затова е необходимо да се създаде отделен каталог или цяла файлова система, например с помощта на mke2fs, в които да поместите всички необходими share-библиотеки, Perl, а също и дървото с документите. В скрипта за пускане на httpd добавете реда:
chroot /path/to/new/root /server_root/httpd
сега при пускането на сървъра става смяна на кореновия каталог и Apache започва да работи напълно изолиран от останалата файлова система. Този метод е достатъчно достатъчно труден и сложен, но въпреки всичко е оправдан.
    WWW сървърът е длъжен да предоставя достъп до определени каталози и файлове с използване на процедури за идентификация. Да се направи такъв достъп в Apache е просто. Може да се направи на основата на проверка на IP-адрес, а също и чрез създаване на отчетен запис на ползвателите. Добавете в access.conf нещо подобно:
<Directory /пълен/пьт/към/каталога>
<Limit GET POST>
order mutual-failure
deny from all
allow from 215.100.2.76
allow from .com
</Limit>
</Directory>
Това ще обезпечи достъпа само от домейна .сом или от хоста 215.100.2.76.
Добавете ползвателя и въведете неговата парола.
www> htpasswd /пут/към/файла/парола име_ползовател
В access.conf добавете нещо подобно на
<Directory /полен/пут/към/защитения/каталог>
AuthName име.вашия.сървър
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/passwd # като вариант
<Limit GET POST>
require valid-user
</Limit>
</Directory>
А сега отностно въпроса за разделяне на дървото на документи httpd и ftpd. Никога не приравнявайте кореновите каталози на тези два сервиза. Не съблюдаването на това правило може да доведе до пекални последствия (пример: взлома над Apache.org). FTP каталога е бил приравнен към WWW. Накрая сървърът MySQL е бил пуснат от root (пример: в PostgreSQL такъв номер не минава). Действията на взлоджията са били очевидни: копиране на ftp скрипт, изпълнието му под Apache и получаването на root права.

Дистрибутиви

    Днес основни дистрибутиви на Linux се явяват RedHat, Debian и Slackware. Всички останали са производни на тези трите. По отношение на безопасността единно правило при избор на дистрибутив не съществува. Най-безопасният ще бъде този, който най-добре ви подхожда именно на вас. Едно от най-добрите решения е може би изграждане на Linux с ядро събрано за решаване на конкретна задача, позволяващо на администратора безопасна работа в мражата. Един малко поостарял пример: Gentus Linux 2.0 (на база на RedHat 6.1), kernel 2.2.13. съществуват дистрибутиви, създадени да облекчат живота на администратора, например, Nexus Linux, достатъчно сложен при установяването и настройките, той обезпечава висока степен на безопасност. Root правата могат да бъдат разпределени между няколко администратора като същевременно изключват изключват твърде високите привилегии на супер user.
    От гледна точка на анализа на безопасност интерес представлява Trinux (Security ToolKit). Съществува огромно количество tools под Trinux - от детектори за ОС до скенери за портове.

Заключение

    Грамотното администриране решава практически всичките проблеми на безопасността. Възможно е много от верките да ви струват твърде сурови, но при орагнизиране на работата на администратора на първо място трябва да бъде принципът "най-сдобрият ползвател е този, който следва политиката, която следвате".