Shell-серверы

Получение доступа к серверу дистанционно критично для большинства администраторов. Большинство из нас не может сидеть за консолью, и в любом случае удаленный доступ чочень удобен.

Telnet

Telnet - SSL

SSH: клиент и сервер

SSH: клиенты

SRP

NSH

R-сервисы

Telnet

Telnet был одной из первых услуг того, что является теперь Internet, это позволяет Вам регистрироваться на удаленной машине в интерактивном режиме, давать команды и смотреть их результаты. Это все еще основное инструментальное средство для удаленного администрированич в большинстве сред, и оно имеет почти универсальную поддержку (даже NT имеет telnet-клиент и daemon). Это также один из наиболее опасных протоколов, восприимчивых ко всему. Если Вы имеете пользователей использующих telnet для доступа к серверу Вы должны определенно выполнить chroot для их логинов если возможно, также как ограничить доступ telnet на используемые ими хосты с помощью TCP_WRAPPERS. Самое лучшее решение для обеспечения безопасности telnet состоит в том, чтобы отключить его и использовать SSL-telnet или ssh.

Проблемы с telnet:

  • username и пароли открытым текстом.
  • Все команды открытым текстом.
  • Атаки на подбор паролей (правда, остаются следы в файлах протоколов).

Самое лучшее решение состоит в том, чтобы выключить telnet и использовать ssh. Однако, это практично не во всех ситуациях. Если Вы используете telnet, я настоятельно предлагаю применить firewall для разрешения определенным хостам/сетям обращаться к порту 23, а для всех остальных такое обращение запретить. Неплохо применить и TCP_WRAPPERS. Пример правил для firewall:

ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 23
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23

или в ipchains:

ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 23
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 23
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23

Пример использования TCP_WRAPPERS в /etc/hosts.allow:

in.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host

и в /etc/hosts.deny:

in.telnetd: ALL

Имеются несколько шифрованных вариантов telnet: ssh, SSLeay Telnet и другие. По-моему, лучше всего ssh. Для защиты пользователей telnet можно сделать несколько дел. Во-первых, запретите доступ root через telnet, это делается в файле /etc/securetty и по умолчанию в большинстве дистрибутивов root может заходить только с консоли. Во-вторых, чтобы пользователь мог работать его shell должна быть упомянута в файле /etc/shells).

Если Вы хотите чтобы пользователь не имел telnet-доступа, но мог менять свой пароль, сделайте вот что:

В файл /etc/shells добавьте строку:

/usr/bin/passwd

и установите shell для пользователя в /usr/bin/passwd, например так:

username:x:1000:1000::/home/username:/usr/bin/passwd

Теперь при входе с помощью telnet у пользователя система спросит логин и пароль, и если все правильно, предложит пароль сменить. Если новый пароль будет введен правильно, он сменится, и пользователь будет отсоединен от системы (связь прервана). Если новый пароль будет введен как-то не так, то пароль не сменится (останется прежним), а пользователь опять же будет отсоединен (связь прервется). Выглядит такой сеанс примерно так:

Trying 1.2.3.4...
Connected to localhost.
Escape character is '^]'.

Red Hat Linux release 5.2 (Apollo)
Kernel 2.2.5 on an i586
login: tester
Password:
Changing password for tester
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully
Connection closed by foreign host.

Telnet также отображает системное приглашение при любом соелдинении. Оно обычно включает системную информацию, в частности название OS, версию и тому подобные сведения, вплоть до версии ядра. При работе с несколькими OS на разных машинах это удобно, но дает хакерам много ценного. Telnetd отображает содержимое файла /etc/issue.net (обычно он идентичен /etc/issue, который отображается на терминалах), этот обычно пересоздается во время перезагрузки в большинстве дистрибутивов Linux из загрузочного скрипта rc.local. Просто поправьте файл rc.local, чтобы он больше не трогал файлы /etc/issue и /etc/issue.net, затем впишите в них некую постоянную информацию.

Обычно в Linux файл rc.local меняет /etc/issue и /etc/issue.net:

# This will overwrite /etc/issue at every boot. So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
echo "" > /etc/issue
echo "$R" >> /etc/issue
echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue
cp -f /etc/issue /etc/issue.net
echo >> /etc/issue

просто закомментируйте строки или удалите команды uname. Если telnet-доступ юзверям абсолютно необходим, создайте свое приглашение:

This system is for authorized users only. Trespassers will be prosecuted.

или что-то в таком роде.

Telnet - SSL

 

SSLtelnet и MZtelnet

Замена для telnet, SSLtelnet и MZtelnet предоставляют более высокий уровень безопасности, чем telnet, хотя SSLtelnet и MZtelnet не столь гибки как SSH, они полностью свободны (то есть, GNU licensed), а SSH нет (хотя OpenSSH *BSD licensed). Пакеты клиента и сервера доступны как tarballs на ftp://ftp.uni-mainz.de/pub/internet/security/ssl/, а как RPM-пакеты на ftp://ftp.zedz.net/pub/replay/linux/redhat.

Slush

Slush основан на OpenSSL и поддерживает сертификаты X.509. Slush распространяется по GPL, но не закончен (все необходимое поддерживается, но есть досадные ограничения). В конце концов может составить хорошую замену для SSH. Скачать можно с http://violet.ibs.com.au/slush.

SSH: клиент и сервер

SSH безопасный протокол и набор инструментальных средств, чтобы заменить некоторые общие (опасные) средства. Это было разработано из желания предложить максимум защиты и позволить удаленный доступ к серверам безопасным способом. SSH может использоваться, чтобы защитить любое сетевое соединение, устанавливая его как 'канал' (то есть, связывая с некоторым портом на обеих концах). Это хорошо для таких вещей как использование X через Internet. В дополнение к этому компоненты сервера выполняются на большинстве UNIX-систем, и NT, а компоненты клиента выполняются практически на всем и везде. К сожалению SSH больше не свободен; однако, имеется проект создать свободную реализацию протокола SSH. Не имеется проблем с SSH, подобных проблемам с telnet, все данные сеанса шифрованы, и обмен ключами выполняется относительно надежно (альтернатива: Вы можете предзагрузить ключи с обеих концов, чтобы предотвращать атаки посередине канала.

SSH

SSH обычно работает как daemon, и может быть легко заблокирован, используя файл настройки sshd_config. Вы можете также запускать sshd из inetd и таким образом использовать TCP_WRAPPERS, по умолчанию rpm-пакет ssh с ftp://ftp.zedz.net имеет опцию проверки TCP_WRAPPERS компилируемой в них. Таким образом используя TCP_WRAPPERS Вы можете легко ограничивать доступ к ssh. Пожалуйста обратите внимание, что более ранние версии ssh содержат ошибки, и несколько мест были зарублены (обычно с проблемами атак в середине канала или с буферными переполнением в коде ssh), но более поздние версии ssh этих проблем уже не имеют. Основная проблема с ssh: лицензия, это свободно только для некоммерческого использования, однако Вы можете загрузить исходный текст из ряда мест. Если Вы хотите легко установить ssh, имеется скрипт “install-ssh”, загрузит, скомпилирует и установит ssh, скачать его можно с ftp://ftp.yellowdoglinux.com/pub/yellowdog/install-ssh.

Правила firewall для ssh практически идентичны telnet. Имеется конечно TCP_WRAPPERS, проблема с TCP_WRAPPERS когда хакур соединяется с портом, но не получает daemon, но узнает что на этом порте что-то есть, в то время как с firewall он даже до порта не доберется. Ниже приводится пример разрешения доступа к ssh с внутренних машин и некоторой сети класса C в internet.

ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 22
ipfwadm -I -a accept -P tcp -S isp.dial.up.pool/24 -D 0.0.0.0/0 22
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 22

или

ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 22
ipchains -A input -p tcp -j ACCEPT -s isp.dial.up.pool/24 -d 0.0.0.0/0 22
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 22

Или через TCP_WRAPPERS, hosts.allow:

sshd: 10.0.0.0/255.0.0.0, isp.dial.up.pool/255.255.255.0

hosts.deny:

sshd: 0.0.0.0/0.0.0.0

В дополнение к этому, ssh имеет замечательный файл конфигурации /etc/sshd/sshd_config по умолчанию в большинстве инсталляций. Вы можете легко ограничивать, кому позволяется входить в систему, с каких хостов, и какие типы авторизации надлежит использовать. Заданный по умолчанию файл конфигурации относительно безопасен, но ниже приведен более безопасный с объяснениями. Пожалуйста обратите внимание, что вся эта информация может быть получена командой “man sshd”, которая написана очень хорошо. А вот и типичный файл sshd_config:

Port 22
# runs on port 22, the standard
ListenAddress 0.0.0.0
# listens to all interfaces, you might only want to bind a firewall
# internally, etc
HostKey /etc/ssh/ssh_host_key
# where the host key is
RandomSeed /etc/ssh/ssh_random_seed
# where the random seed is
ServerKeyBits 768
# how long the server key is
LoginGraceTime 300
# how long they get to punch their credentials in
KeyRegenerationInterval 3600
# how often the server key gets regenerated 
PermitRootLogin no
# permit root to login? no
IgnoreRhosts yes
# ignore .rhosts files in users dir? yes
StrictModes yes
# ensures users don't do silly things
QuietMode no
# if yes it doesn't log anything. yikes. we want to log logins/etc.
X11Forwarding no
# forward X11? shouldn't have to on a server
FascistLogging no
# maybe we don't want to log too much.
PrintMotd yes
# print the message of the day? always nice
KeepAlive yes
# ensures sessions will be properly disconnected
SyslogFacility DAEMON
# who's doing the logging?
RhostsAuthentication no
# allow rhosts to be used for authentication? the default is no
# but nice to say it anyways
RhostsRSAAuthentication no
# is authentication using rhosts or /etc/hosts.equiv sufficient
# not in my mind. the default is yes so lets turn it off. 
RSAAuthentication yes
# allow pure RSA authentication? this one is pretty safe
PasswordAuthentication yes
# allow users to use their normal login/passwd? why not.
PermitEmptyPasswords no
# permit accounts with empty password to log in? no

Другие интересные директивы sshd_config:

AllowGroups - явно позволяет группам (/etc/group) входить в систему по ssh
DenyGroups - явно запрещает группам (/etc/group) входить в систему по ssh
AllowUsers - явно позволяет пользователям входить в систему по ssh
DenyUsers - явно запрещает пользователям входить в систему по ssh
AllowHosts - разрешает доступ некоторым хостам (остальным будет отказано)
DenyHosts - блокирует некоторые хосты, остальные будут работать
IdleTimeout time - время в minutes/hours/days/etc, после которого
                   производится принудительный выход из системы по получению
                   процессом сигнала SIGHUP.
OpenSSH

OpenSSH проект, начатый OpenBSD project для создания полнофункциональной версии SSH клиент и сервер, лицензируемых свободно (то есть, BSD и GPL). Они очистили код, устранили кучу ошибок и сделали лучшую поддержку PAM, чем в "официальный" SSH клиенте и сервере. Этот проект собирается заменить традиционный SSH полностью. Доступен на http://www.openssh.com. Я лично использую его и никаких проблем нет.

LSH

LSH свободная реализация протокола SSH (клиент и сервер), LSH GNU licensed и создан как альтернатива SSH (который все же не свободен полностью). Скачать можно с http://www.net.lut.ac.uk/psst, но помните, что он еще только разрабатывается.

OSSH

Я так и не смог понять толком, что это за штука, но сложилось впечатление, что это версия SSH с некоторыми расширениями (типа поддержки SecureID). Скачать можно с ftp://ftp.nada.kth.se/pub/krypto/ossh.

SSH: клиенты

Fresh Free FiSSH

Большинство из нас все еще должно сидеть за windows workstations, а найти ssh-клиент для windows трудно. Fresh Free FiSSH является свободным клиентом ssh для Windows 95/NT 4.0. Хотя разработка еще не завершена, я рекомендую присматривать за пакетом повнимательнее: он того стоит. URL: http://www.massconfusion.com/ssh .

Tera Term

Tera Term свободный клиент Telnet для Windows, имеет add-on DLL для поддержки ssh. Tera Term доступен на http://hp.vector.co.jp/authors/VA002416/teraterm.html. А add-on DLL для поддержки SSH можно скачать с http://www.zip.com.au/~roca/ttssh.html.

putty

putty Windows SSH-клиент, очень удобный, свободный и очень маленький (184k всего). Скачать можно с http://www.chiark.greenend.org.uk/~sgtatham/putty.html.

mindterm

mindterm свободный java ssh-клиент, скачать можно с http://www.mindbright.se/mindterm.

Secure CRT

Коммерческий клиент Telnet/SSH от Vandyke software. Скачать/купить можно на http://www.vandyke.com.

Fsh

Fsh (“Fast remote command execution”) подобен rsh/rcp. Он создает шифрованный туннель, используя SSH или LSH и выполняет через него все команды. Скачать можно с http://www.lysator.liu.se/fsh.

SSH Win32 ports

SSH для Win32 можно скачать с http://guardian.htu.tuwien.ac.at/therapy/ssh.

SRP

SRP относительно новая разработка, однако имеет несколько преимуществ над некоторыми из старших программ. SRP свободный и не использует шифрование для обеспечения безопасности сеанса, хотя есть и шифрующая версия. SRP использует довольно шуструю математику, подробно рассмотренную на http://srp.stanford.edu/srp/ndss.html. Недостаток в том, что SRP шифрует только вход в систему (username и пароль), так что любые перемещаемые данные (типа telnet-сеанса или ftp-сайта) уязвимы. Скачать SRP можно с http://srp.stanford.edu/srp. SRP сейчас поддерживает Telnet и FTP (для windows тоже), хотя поддержка SRP других протоколов проста. Клиент для windows с поддержкой SRP доступен на http://www.kermit-project.org/k95.html.

NSH

NSH коммерческий пакет со встроенной поддержкой шифрования. Не знаю, насколько прочное шифрование, поскольку открытых исходников тут нет. Легкость использования высока, Вы cd //computername и начинается регистрация на заданном компьютере, моджно легко упраялть файлами, запустить ps и получить список процессов на компьютере и многое другое. NSH идеален для управления несколькими подобными системами благодаря встроенному модулю Perl для изготовления скриптов. К тому же, NSH доступен для многих платформ (Linux, BSD, Irix), а для Red Hat есть RPM-пакет. NSH доступен на http://www.networkshell.com, там есть 30-дневная версия.

R-сервисы

R-сервисы (rsh, rcp, rexec и подобные) небезопасны. Защитить их трудно, так что лучше не используйте их! Их собственная защита основана на hostname/IP-адресе машины, с которой устанавливается соединение, что легко можно подделать. По умолчанию они не все заблокированы, пожалуйста выключите их немедленно. Поправьте /etc/inetd.conf, найдите в нем rexec, rsh и тому подобное и закомментируйте эти строки, после чего перезапустите inetd: "killall -1 inetd".

Если Вы абсолютно должны использовать эти сервисы, используйте TCP_WRAPPERS, это немного поможет. Также надо использовать firewall, так как от правильно поставленной атаки TCP_WRAPPERS защитит далеко не всегда. Доступ к различным R-сервисам управляется через файлы rhosts, обычно каждый пользователь имеет собственный файл rhosts, к сожалению, это восприимчиво к спуфингу пакетов. Проблема с r-сервисами в том, что есть маленькая дырка в защите системы, которая позволяет править файлы и редактировать данные о пользователях (как root) .rhost-файлы делают систему очень доступной.

Если Вы нуждаетесь в удаленных инструментальных средствах администрирования, которые являются легкими в использовании и подобными rsh, я рекомендую NSH (Network SHell) или SSH: они поддерживают шифрование и намного более высокий уровень защиты. Альтернатива: использование программного обеспечения VPN уменьшит часть риска, поскольку Вы можете блокировать пакеты спуфинга (IPSec-авторизация отправителя и источника, что является в некоторых случаях более важным, чем шифрование данных).

Back

Security Portal

Written by Kurt Seifried



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