Online video hd

Смотреть жесткое видео

Официальный сайт printclick 24/7/365

Смотреть видео бесплатно

|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: ЖДУ ОТ АУДИТОРИИ.



Жду ваших советов/фич, отзывов и поправок ...


Тэги: security ssh защита
+ 8 -
Похожие Поделиться

xameleon 13.07.2009 14:53 #
+ 1 -
добавте кат.
Kraplax 13.07.2009 15:27 #
+ 0 -
fixed
xT 13.07.2009 15:27 #
+ 0 -
кат и оформление плз
Kraplax 13.07.2009 15:37 #
+ 0 -
ленится народ. совсем ленится :/
Minoru 13.07.2009 15:52 #
+ 3 -
Идея: добавить кнопку «на доработку». Одного нажатия модером или трёх нажатий обычными пользователями будет достаточно, чтобы статья пропала, а автору было отправлено сообщение с требованием привести её к человеческому облику в течении, скажем, недели, иначе она будет удалена вообще. Только предварительно надо реализовать черновики, чтобы было куда такие вот «отвергнутые» статьи отправлять.
Kraplax 13.07.2009 19:36 #
+ 1 -
Интересная идея. Вот только зачем удалять статью даже из черновика пользователя? Пусть и лежит там пока не доделает. И еще тут надо обдумать троллей - если вашу статью будут тут же отправлять "на доработку" без причины, то вам это не понравится. Скорее всего такая кнопка еще потребует второй кнопки - "Принято", чтобы потом кнопка "на доработку" не появлялась вообще, и однажды дописанная статья не могла бы быть отправлена "на доработку" через пару лет пролежав в архиве.
Minoru 13.07.2009 20:11 #
+ 0 -
Вот только зачем удалять статью даже из черновика пользователя? Пусть и лежит там пока не доделает.
Ты меня неправильно понял — я как раз писал о том, что надо сделать черновики, иначе некуда положить статью (её же нужно спрятать от народа, но так, чтобы её видел автор).
И еще тут надо обдумать троллей
Вот вечно они даже своим присутствием всё усложняют… :)
Твоя идея касательно «Принято» мне нравится. Причём желательно, чтобы кнопка эта была доступна только модераторам/администраторам. Можно ещё сделать доступ по рейтингу — то есть если тебе его не хватает, то ты эти кнопки не видишь. Или по уровню доступа (балы же вроде такая фишка на заре welinux'а, не знаю, как сейчас).
Ну и ещё сделать тайм-аут какой-то — например, если статье больше месяца (с момента последней публикации — их же, публикаций, может быть несколько, если статью отправляют на доработку), кпопки просто исчезают.
|xed| 13.07.2009 16:30 #
+ 1 -
спасибо...
_______________
я ленивый,бородатый...уж извиняйте какой есть =)
squ1b3r 13.07.2009 15:02 #
+ 0 -
Доброе такое спасибо! Вроде мелочь, а чего-то не знал, чего-то забыл.
predator 13.07.2009 15:16 #
+ 0 -
Спасибо, по-любому когда-нибудь пригодится.
xT 13.07.2009 15:27 #
+ 0 -
Новичкам полезно +)
n0p 13.07.2009 16:22 #
+ 2 -
Есть еще аутентификация через PAM - по сути, та же аутентификация по паролю. Отключается в sshd_config:
UsePAM no

Про фильтрацию по IP и по MAC могу рассказать, но не вижу смысла в такой фильтрации. Если мне вот срочно нужно что-то сделать с компом удаленно не из дома, а от друзей, например, то как быть? Ключ я могу таскать на флешке, пароль тоже помнить могу, а вот если соха настроена на конкретный адрес (IP или MAC не важно), то придется обломаться. ИМХО, аутентификация по ключу уже довольно хороша сама по себе, зачем еще что-то наворачивать сверх этого?
xT 13.07.2009 16:29 #
+ 2 -
"По ключу только через удаленный сервер"
|xed| 13.07.2009 17:53 #
+ 1 -
смысл есть ...защита - личная забота...и каждый выбирает сам как защитится.
нам нужно показать что можно и так.
n0p 14.07.2009 08:34 #
+ 1 -
Да, согласен. Бывают случаи, когда ставится защита IP+MAC+RSA keys.. Я как-то однобоко рассматривал вопрос с т.з. обычного человека, а, например, про крупные организации с огромным парком машин и защиту серверов от своих же сотрудников как-то не подумал.. :)
yuretsz 14.07.2009 01:52 #
+ 1 -
Я ломлюсь на свой домашний комп, который всегда включен, и захожу на нужный хост.
polatov 14.07.2009 07:18 #
+ 0 -
Не понял следующее:
помощью iptables можно фильтровать соединения по ip и по mac`y
советую по mac`y так как в Linux`e сменить мак на сетевом интерфейсе не проблема.
n0p 14.07.2009 08:31 #
+ 1 -
Вот есть у нас машина с линуксом на борту. Есть удаленная машина, доступ к которой нужно ограничить.
В случае ограничения по IP-адресу становится возможным подключение только с указанных IP-адресов. Но если наша машина имеет IP не из этого списка, доступ мы получить никак не сможем (без использования промежуточного сервера с IP из списка доверия).
В случае ограничения по MAC мы можем сменить MAC-адрес сетевого интерфейса на нужный и получить доступ. Способ достаточно надежный, ибо злоумышленник не может знать какой MAC-адрес разрешен. Хотя, кому надо - тот пролезет :)
|xed| 14.07.2009 15:36 #
+ 0 -
еще одна забава хакеру...
перебирать маки =)
Subcreator 14.07.2009 16:13 #
+ 0 -
Было бы неплохо отсортировать список по степени опасности/полезности.
Например, пункт 2 легко пробивается сканом по портам выше 1024,
пункты 3, 5, 6 - классика, во многих дистрах это идет по умолчанию
n0p 14.07.2009 16:56 #
+ 2 -
По поводу фильтрации через iptables.

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-адресу нужно еще какой-то модуль скомпилить в ядре, щас уже не вспомню.
k4m454k 26.03.2010 10:48 #
+ 0 -
Я сейчас на сервере сделал так:
Прописал все диапазоны возможных 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 порт следующим правилом. после этого в логах одни жалкие попытки перебора...
ИМХО этого достаточно
dimqua 26.03.2010 10:54 #
+ 0 -
Если ssh наружу не смотрит, то пофигу, можно и руту доступ дать и авторизацию по паролю и ключам отключить, верно?

Смотреть онлайн бесплатно

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн