| Каталог документации / Раздел "Документация для Linux" / Оглавление документа |
| |
|
Получение доступа к серверу дистанционно критично для большинства администраторов. Большинство из нас не может сидеть за консолью, и в любом случае удаленный доступ чочень удобен.
Telnet был одной из первых услуг того, что является теперь Internet, это позволяет Вам регистрироваться на удаленной машине в интерактивном режиме, давать команды и смотреть их результаты. Это все еще основное инструментальное средство для удаленного администрированич в большинстве сред, и оно имеет почти универсальную поддержку (даже NT имеет telnet-клиент и daemon). Это также один из наиболее опасных протоколов, восприимчивых ко всему. Если Вы имеете пользователей использующих telnet для доступа к серверу Вы должны определенно выполнить chroot для их логинов если возможно, также как ограничить доступ telnet на используемые ими хосты с помощью TCP_WRAPPERS. Самое лучшее решение для обеспечения безопасности telnet состоит в том, чтобы отключить его и использовать SSL-telnet или ssh.
Проблемы с telnet:
Самое лучшее решение состоит в том, чтобы выключить 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-авторизация отправителя и источника, что является в некоторых случаях более важным, чем шифрование данных).
Written by Kurt Seifried |
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |