LASG - Shell servers
Shell-серверы
Получение доступа к серверу дистанционно критично для большинства
администраторов. Большинство из нас не может сидеть за консолью, и в любом
случае удаленный доступ чочень удобен.
Telnet
Telnet - SSL
SSH: клиент и сервер
SSH: клиенты
SRP
NSH
R-сервисы
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, 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 основан на OpenSSL и поддерживает сертификаты X.509. Slush
распространяется по GPL, но не закончен (все необходимое поддерживается, но
есть досадные ограничения). В конце концов может составить хорошую замену
для SSH. Скачать можно с
http://violet.ibs.com.au/slush.
SSH безопасный протокол и набор инструментальных средств, чтобы заменить
некоторые общие (опасные) средства. Это было разработано из желания
предложить максимум защиты и позволить удаленный доступ к серверам безопасным
способом. SSH может использоваться, чтобы защитить любое сетевое соединение,
устанавливая его как 'канал' (то есть, связывая с некоторым портом на обеих
концах). Это хорошо для таких вещей как использование X через Internet. В
дополнение к этому компоненты сервера выполняются на большинстве UNIX-систем,
и NT, а компоненты клиента выполняются практически на всем и везде. К
сожалению SSH больше не свободен; однако, имеется проект создать свободную
реализацию протокола SSH. Не имеется проблем с SSH, подобных проблемам с
telnet, все данные сеанса шифрованы, и обмен ключами выполняется относительно
надежно (альтернатива: Вы можете предзагрузить ключи с обеих концов, чтобы
предотвращать атаки посередине канала.
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 проект, начатый OpenBSD project для создания полнофункциональной
версии SSH клиент и сервер, лицензируемых свободно (то есть, BSD и GPL). Они
очистили код, устранили кучу ошибок и сделали лучшую поддержку PAM, чем в
"официальный" SSH клиенте и сервере. Этот проект собирается заменить
традиционный SSH полностью. Доступен на
http://www.openssh.com. Я лично использую его и никаких проблем нет.
LSH свободная реализация протокола SSH (клиент и сервер), LSH GNU
licensed и создан как альтернатива SSH (который все же не свободен
полностью). Скачать можно с
http://www.net.lut.ac.uk/psst,
но помните, что он еще только разрабатывается.
Я так и не смог понять толком, что это за штука, но сложилось впечатление,
что это версия SSH с некоторыми расширениями (типа поддержки SecureID).
Скачать можно с
ftp://ftp.nada.kth.se/pub/krypto/ossh.
Большинство из нас все еще должно сидеть за windows workstations, а найти
ssh-клиент для windows трудно. Fresh Free FiSSH является свободным клиентом
ssh для Windows 95/NT 4.0. Хотя разработка еще не завершена, я рекомендую
присматривать за пакетом повнимательнее: он того стоит. URL:
http://www.massconfusion.com/ssh
.
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 Windows SSH-клиент, очень удобный, свободный и очень маленький (184k
всего). Скачать можно с
http://www.chiark.greenend.org.uk/~sgtatham/putty.html.
mindterm свободный java ssh-клиент, скачать можно с
http://www.mindbright.se/mindterm.
Коммерческий клиент Telnet/SSH от Vandyke software. Скачать/купить можно
на http://www.vandyke.com.
Fsh (“Fast remote command execution”) подобен rsh/rcp. Он
создает шифрованный туннель, используя SSH или LSH и выполняет через него
все команды. Скачать можно с
http://www.lysator.liu.se/fsh.
SSH для Win32 можно скачать с
http://guardian.htu.tuwien.ac.at/therapy/ssh.
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 коммерческий пакет со встроенной поддержкой шифрования. Не знаю,
насколько прочное шифрование, поскольку открытых исходников тут нет. Легкость
использования высока, Вы cd //computername и начинается регистрация на
заданном компьютере, моджно легко упраялть файлами, запустить ps и получить
список процессов на компьютере и многое другое. NSH идеален для управления
несколькими подобными системами благодаря встроенному модулю Perl для
изготовления скриптов. К тому же, NSH доступен для многих платформ (Linux,
BSD, Irix), а для Red Hat есть RPM-пакет. NSH доступен на
http://www.networkshell.com, там
есть 30-дневная версия.
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
| 
