|xed| 13.07.2009 14:50
Я рекомендую — Защищаем ssh
тут наткнулся на статейку http://www.opennet.ru/opennews/art.shtml?num=22511 , которая заставила задуматься о защите ssh.В интернете есть много советов как защитить ssh,но мне бы хотелось все советы объединить в одну статейку которая послужила бы неким комплексом по защите ssh.
начну...
у мну debian так что у кого-то что-то может не сходится.
также обращю внимание новичков что ssh_config и sshd_config две разные вещи, первый конфиг для клиента второй для сервера.
1.Сделать авторизацию по ключам.
обычно ключи(публичный и секретный) генерируются автоматически при установке ssh клиента/сервера.
на сервере в /etc/ssh/sshd_config надо добавить/изменить
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
публичный ключ клиента отправить в .ssh/authorized_keys (который находится на сервере)
если настроена аутентификация по ключам, советую отключить аутентификацию по паролю.
в /etc/ssh/sshd_config
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM no
но для не которых не всегда удобно использовать авторизацию по ключам.
2.Запуск sshd на не стандартном порту.
в /etc/ssh/sshd_config надо изменить
#Port 22
Port 2222
ПыСы не забудьте при подключении указать порт.
example: ssh -p 2222 [email protected]
3.Использовать только Protocol 2.
в /etc/ssh/sshd_config надо изменить
#Protocol 2,1
Protocol 2
4.Использовать denyhosts.
Демон просматривает логи и в случае нескольких неправильных попыток ввода пароля блокирует доступ для ssh с атакующего ip адреса.
apt-get install denyhosts
/etc/init.d/denyhosts start
ПыСы: можно еще использовать Fail2ban
5.Запретить авторизацию root-пользователю
в /etc/ssh/sshd_config надо изменить
PermitRootLogin no
6.Запретить авторизацию по пустому паролю...
в /etc/ssh/sshd_config надо проверить!
PermitEmptyPasswords no
7.Установть пользователей/группу пользователей, которые могут входить в систему.
по пользователям:
AllowUsers user user1 user2 weuser
по группе пользователей:
AllowGroups groupuser
А также можно указать с каких адресов пользователь может входить в систему.
AllowUsers [email protected]
8.Использовать iptables.
A.с помощью iptables можно фильтровать соединения по ip и по mac`y
советую по mac`y так как в Linux`e сменить мак на сетевом интерфейсе не проблема.
example: ЖДУ ОТ АУДИТОРИИ.
B.также можно рубить ботов которые ломятся ежесекундно на порт.
example:
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
9.Можно использовать port knocking.
К примеру: KNOCKD - Простой "port knocking" сервер. Осуществляет запуск указанной в конфигурации команды, если в пределах заданного таймаута было произведено соединение к заданной последовательности сетевых портов.
ПыСы: ставил год назад knockd...не стабильно работал!
можно выкрутится с помощью iptables и модулем recent
example: ЖДУ ОТ АУДИТОРИИ.
Жду ваших советов/фич, отзывов и поправок ...
xameleon 13.07.2009 14:53 #
+ 1 -
добавте кат.
Идея: добавить кнопку «на доработку». Одного нажатия модером или трёх нажатий обычными пользователями будет достаточно, чтобы статья пропала, а автору было отправлено сообщение с требованием привести её к человеческому облику в течении, скажем, недели, иначе она будет удалена вообще. Только предварительно надо реализовать черновики, чтобы было куда такие вот «отвергнутые» статьи отправлять.
Интересная идея. Вот только зачем удалять статью даже из черновика пользователя? Пусть и лежит там пока не доделает. И еще тут надо обдумать троллей - если вашу статью будут тут же отправлять "на доработку" без причины, то вам это не понравится. Скорее всего такая кнопка еще потребует второй кнопки - "Принято", чтобы потом кнопка "на доработку" не появлялась вообще, и однажды дописанная статья не могла бы быть отправлена "на доработку" через пару лет пролежав в архиве.
Вот только зачем удалять статью даже из черновика пользователя? Пусть и лежит там пока не доделает.
Ты меня неправильно понял — я как раз писал о том, что надо сделать черновики, иначе некуда положить статью (её же нужно спрятать от народа, но так, чтобы её видел автор).
И еще тут надо обдумать троллей
Вот вечно они даже своим присутствием всё усложняют… :)Твоя идея касательно «Принято» мне нравится. Причём желательно, чтобы кнопка эта была доступна только модераторам/администраторам. Можно ещё сделать доступ по рейтингу — то есть если тебе его не хватает, то ты эти кнопки не видишь. Или по уровню доступа (балы же вроде такая фишка на заре welinux'а, не знаю, как сейчас).
Ну и ещё сделать тайм-аут какой-то — например, если статье больше месяца (с момента последней публикации — их же, публикаций, может быть несколько, если статью отправляют на доработку), кпопки просто исчезают.
спасибо...
_______________
я ленивый,бородатый...уж извиняйте какой есть =)
_______________
я ленивый,бородатый...уж извиняйте какой есть =)
Доброе такое спасибо! Вроде мелочь, а чего-то не знал, чего-то забыл.
Есть еще аутентификация через PAM - по сути, та же аутентификация по паролю. Отключается в sshd_config:
Про фильтрацию по IP и по MAC могу рассказать, но не вижу смысла в такой фильтрации. Если мне вот срочно нужно что-то сделать с компом удаленно не из дома, а от друзей, например, то как быть? Ключ я могу таскать на флешке, пароль тоже помнить могу, а вот если соха настроена на конкретный адрес (IP или MAC не важно), то придется обломаться. ИМХО, аутентификация по ключу уже довольно хороша сама по себе, зачем еще что-то наворачивать сверх этого?
UsePAM no
Про фильтрацию по IP и по MAC могу рассказать, но не вижу смысла в такой фильтрации. Если мне вот срочно нужно что-то сделать с компом удаленно не из дома, а от друзей, например, то как быть? Ключ я могу таскать на флешке, пароль тоже помнить могу, а вот если соха настроена на конкретный адрес (IP или MAC не важно), то придется обломаться. ИМХО, аутентификация по ключу уже довольно хороша сама по себе, зачем еще что-то наворачивать сверх этого?
смысл есть ...защита - личная забота...и каждый выбирает сам как защитится.
нам нужно показать что можно и так.
нам нужно показать что можно и так.
Да, согласен. Бывают случаи, когда ставится защита IP+MAC+RSA keys.. Я как-то однобоко рассматривал вопрос с т.з. обычного человека, а, например, про крупные организации с огромным парком машин и защиту серверов от своих же сотрудников как-то не подумал.. :)
Я ломлюсь на свой домашний комп, который всегда включен, и захожу на нужный хост.
Не понял следующее:
помощью iptables можно фильтровать соединения по ip и по mac`y
советую по mac`y так как в Linux`e сменить мак на сетевом интерфейсе не проблема.
советую по mac`y так как в Linux`e сменить мак на сетевом интерфейсе не проблема.
Вот есть у нас машина с линуксом на борту. Есть удаленная машина, доступ к которой нужно ограничить.
В случае ограничения по IP-адресу становится возможным подключение только с указанных IP-адресов. Но если наша машина имеет IP не из этого списка, доступ мы получить никак не сможем (без использования промежуточного сервера с IP из списка доверия).
В случае ограничения по MAC мы можем сменить MAC-адрес сетевого интерфейса на нужный и получить доступ. Способ достаточно надежный, ибо злоумышленник не может знать какой MAC-адрес разрешен. Хотя, кому надо - тот пролезет :)
В случае ограничения по IP-адресу становится возможным подключение только с указанных IP-адресов. Но если наша машина имеет IP не из этого списка, доступ мы получить никак не сможем (без использования промежуточного сервера с IP из списка доверия).
В случае ограничения по MAC мы можем сменить MAC-адрес сетевого интерфейса на нужный и получить доступ. Способ достаточно надежный, ибо злоумышленник не может знать какой MAC-адрес разрешен. Хотя, кому надо - тот пролезет :)
Было бы неплохо отсортировать список по степени опасности/полезности.
Например, пункт 2 легко пробивается сканом по портам выше 1024,
пункты 3, 5, 6 - классика, во многих дистрах это идет по умолчанию
Например, пункт 2 легко пробивается сканом по портам выше 1024,
пункты 3, 5, 6 - классика, во многих дистрах это идет по умолчанию
По поводу фильтрации через iptables.
Можно и без отдельной таблицы, но так как-то правильнее и нагляднее, я считаю.
Для фильтрации по MAC-адресу нужно еще какой-то модуль скомпилить в ядре, щас уже не вспомню.
iptables -N ssh_filter
iptables -A INPUT -p tcp --sport 22 -j ssh_filter
iptables -A ssh_filter -s XXX.XXX.XXX.XXX -j ACCEPT
iptables -A ssh_filter -m mac --mac-source 00:11:22:33:44:55 -j ACCEPT
iptables -A ssh_filter -j DROP
Можно и без отдельной таблицы, но так как-то правильнее и нагляднее, я считаю.
Для фильтрации по MAC-адресу нужно еще какой-то модуль скомпилить в ядре, щас уже не вспомню.
Я сейчас на сервере сделал так:
Прописал все диапазоны возможных ip выданных мне провайдером (всего 8 диапазонов)
и сделал это:
ну и есессно дропаю новые соединения на 22 порт следующим правилом. после этого в логах одни жалкие попытки перебора...
ИМХО этого достаточно
Прописал все диапазоны возможных ip выданных мне провайдером (всего 8 диапазонов)
и сделал это:
-A INPUT -p tcp -m tcp -m state -m hashlimit --dport 22 --state NEW -j ACCEPT --hashlimit 1/hour --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name SSH hashlimit-htable-expire 60000
ну и есессно дропаю новые соединения на 22 порт следующим правилом. после этого в логах одни жалкие попытки перебора...
ИМХО этого достаточно