LINUX.ORG.RU
ФорумAdmin

Как безопасно управлять сервером.

 , ,


1

3

Здравствуйте. В процессе освоения CentOS у меня возникла уйма вопросов, но до сих пор мне удавалось самому находить ответы. Но сейчас я сам не могу разобраться.

Задача следующая, безопасно получать доступ к управлению моего сервера из любой точки мира по ssh при этом используя public wifi. =) Я настроил доступ к серверу по ssh на нестандартном порту, чтобы его не брутили, отключил авторизацию по паролю, настроил авторизацию по ssh ключам.

Поднял OpenVPN (udp, tls-auth, remote-cert-tls server) тоже на нестандартном порту, планирую на 80 порт перенести.

Я подключаюсь через OpenVPN к серверу, в а потом через putty подключаюсь к серверу по ssh server-ip:port. И думал, что ssh пройдет внутри OpenVPN, но

# who am i
root     pts/0        2013-03-17 20:50 (my_ip)
То есть подключение putty идет через открытый канал, а не через VPN.

Хочу узнать, как вообще решаются подобные задачи. Спасибо за внимание.



Последнее исправление: cetjs2 (всего исправлений: 1)

У тебя твой сервер светится во внешние интернеты (видимо с белым IP), но тебе этого мало и ты поверх ещё и VPN поднял??

zolden ★★★★★
()

Выключи сервер - +100 к безопасности.
Если по делу: man ssh

windofchange
()
Ответ на: комментарий от ruzniki

То, что все твои телодвижения с VPN и «альтернативными» портами чистый cargocult и жуткий overkill, скорее понижающий, чем повышающий безопастность.

Правильное решение: SSH на родном порту с запрещённым root-login'ом и авторизацией по ключам.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от beastie

Твое сообщение ты удалил, но я тебе всё равно отвечу:

1. SSH трафик уже шифрованный. Двойное шифрование обычно понижает крипроустойчивость. (И пропускную способность канала.)

2. Хотя бы затем, что root — это default-user и гарантированный вектор атак. (Ну и отучаемся работать под рутом заодно.)

PS: думать иногда бывает вредно.

beastie ★★★★★
()
Ответ на: комментарий от ruzniki

Как тебе тут уже намекнули ты пытаешься делать двойное шифрование.
Если сервер и так доступен из интернетов, то VPN тут лишняя сущность, и тех мер, что ты уже принял должно быть достаточно для безопасности.
Если паранойя совсем не даёт спать, то можно настроить knockd

zolden ★★★★★
()

1. Заведи пользователя со сложным паролем
2. Добавь его в sudoers
3. Настрой авторизацию сертификатами
4. Запрети логиниться рутом по ssh и логиниться по паролю.
5. ???
6. PROFIT

В дополнение можно ещё перевесить ssh на другой порт и вкорячить fail2ban — при таких раскладах затыкается даже моя паранойя.

Skeletal ★★★
()
Последнее исправление: Skeletal (всего исправлений: 1)
Ответ на: комментарий от Skeletal

вкорячить fail2ban

И, если сам накосячишь, себя же забанишь. Достаточная защита от брутфорса - лимитрирование через iptables количества попыток и блокировки на минуту-другую.

AS ★★★★★
()
Ответ на: комментарий от beastie

Правильное решение: SSH на родном порту с запрещённым root-login'ом и авторизацией по ключам.

и iptables recent обязательно: с ключом подбор не страшен, как подбор, но DDoS с него получить можно запросто, как побочный эффект.

AS ★★★★★
()

ад какой.

и это, да, ты же забыл самое главное! запилить OTP.

anonymous
()
Ответ на: комментарий от anton_jugatsu

или хотя бы осиливанием скормить ssh нужный ойпишнег.

anonymous
()

Я подключаюсь через OpenVPN к серверу, в а потом через putty подключаюсь к серверу по ssh server-ip:port. И думал, что ssh пройдет внутри OpenVPN, но подключение putty идет через открытый канал, а не через VPN.

Всё вышесказанное верно + вдогонку вопрос — server-ip хотя бы относящийся к VPN указывал? Или на внешний стучался?

imul ★★★★★
()

9 лет админю, ни разу не слышал, чтобы ломали сервак по ключу. Делай вывод; параноя излишня. + у немцев был игровой сервер со сложным root паролем (11 символов) - за 2 года ни одной проблемы.

anonymous
()
Ответ на: комментарий от anonymous

9 лет админю, ни разу не слышал, чтобы ломали сервак по ключу.

Факап debian'a уже все забыли?

kostian ★★★★☆
()
Ответ на: комментарий от beastie

То, что все твои телодвижения с VPN и «альтернативными» портами чистый cargocult и жуткий overkill, скорее понижающий, чем повышающий безопастность.

Как sshd на альтернативном порту понижает безопасность? :)
От тупой долбежки вполне «помогает».

kostian ★★★★☆
()
Ответ на: комментарий от kostian

От тупой долбёжки помогает fail2ban. Можно выставить 10 попыток и час бана. Если ты волнуешься, что могут подобрать пароль со скоростью 10 паролей в час, то может стоит поменять его на более надёжный? ;)

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Можно выставить 10 попыток и час бана.

И толку, если долбятся постоянно, засырая лог?

Если ты волнуешься, что могут подобрать пароль со скоростью 10 паролей в час, то может стоит поменять его на более надёжный?

Не в этом дело.

kostian ★★★★☆
()
Ответ на: комментарий от kostian

Ну пусть засирают, для этого есть ротация логов.

Можно ведь настроить уведомления о каждом успешном логине по ssh на жаббер или почту, если логин был не из интранета или «белого списка».

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от beastie

(И пропускную способность канала.)

ну это-то понятно... Хотя для ssh широкий канал не особо то и нужен, не так ли? А для передачи файлов вполне можно использовать, например VPN->FTP.

Двойное шифрование обычно понижает крипроустойчивость.

Впервые слышу! Почему? О_о

SSH на родном порту

А зачем обязательно так? По-моему, смена порта в сочетании с:
а) детектором сканирования портов
б) выставлением на стандартный порт правил с REJECT (а не DROP), баном по recent и защитой от флуда (от тупых скан-брут-ботов)
Здорово запутает атакующего. Разве нет? Ведь верный порт еще найти надо, а в при таких мерах это будет непросто.

Liber
()
Ответ на: комментарий от Chaser_Andrey

Ну пусть засирают, для этого есть ротация логов.

На порт 222, например, они просто не полезут.

если логин был не из интранета или «белого списка»

Это как?

kostian ★★★★☆
()
Ответ на: комментарий от Chaser_Andrey

Нас ведь волнует своевременное обнаружение вторжения?

Да лезут они с феерическими логин/пароль. Смысл в fail2ban, если аутентификация по ключам?

kostian ★★★★☆
()
Ответ на: комментарий от AS

И, если сам накосячишь, себя же забанишь.

А вот нечего по пьяни лезть куда не надо.

bhfq ★★★★★
()
Ответ на: комментарий от beastie

Да я не о том, у человека с base знаниями по R&S не возникает таких вопросов в принципе.

anton_jugatsu ★★★★
()
Ответ на: комментарий от AS

лимитрирование через iptables количества попыток и блокировки на минуту-другую.

Тащемта, fail2ban занимается именно этим, время блокировки настраивается в правилах. Зачем пилить свой костыль, если всё уже сделано?

Skeletal ★★★
()
Ответ на: комментарий от kostian

> если логин был не из интранета или «белого списка»

Это как?

в смысле, если IP, с которого залогинились, был не в intranet или белом списке

Chaser_Andrey ★★★★★
()

Я думаю человек просто думает, что его подключение к ssh могут направить куда-то в левое место.
1. Так вот, проверяй fingerprint, если он сменится, то у тебя будет предупреждение.
2. Используй проверенный dns, а не тот что дает тебе чужой wi-fi
3. Подключайся по ip, а не по nameserver

anonymous_sama ★★★★★
()
Ответ на: комментарий от Skeletal

Зачем пилить свой костыль, если всё уже сделано ?

Вообще-то, костыль - это fail2ban. А -m recent - это iptables. ;-)

А fail2ban правила удаляет что ли ? Но, в любом случае, от него много лишних телодвижений, начиная с «парсить логи».

AS ★★★★★
()

root

Первым делом надо было сделать passwd -l root.

anonymous
()
Ответ на: комментарий от AS

А fail2ban правила удаляет что ли ?

Да, удаляет. Его главный плюс проистекает из главного минуса — парсинг логов даёт универсальность и гибкость, сиречь, его можно натравить на пучок сервисов сразу. Впрочем, если ОПу нужен только ssh, то такида, лишняя сущность, но зато расширяемая )

Skeletal ★★★
()
Ответ на: комментарий от beastie

Не соглашусь про смену порта. Пока ssh висел на стандартном порту fail2ban отлавливал десяток попыток подбора пароля в день. Из них около половины попытки вломиться под рутом.

Смена порта уменьшила количество попыток взлома до единичных случаев.

kombrig ★★★
()
Ответ на: комментарий от AS

Ну поставь блокировку после 5-и попыток на часик.

Если сам не смог с 5-и попыток ввести верный пароль - это говорит о том, что не стоит тебе сейчас работать с сервером.

kombrig ★★★
()
Последнее исправление: kombrig (всего исправлений: 1)
Ответ на: комментарий от Liber

Впервые слышу! Почему? О_о

Сильное уменьшение поля ключей. Атака перебором упрощается на несколько магнитуд. На пальцах можно это себе так представить, что ключи не складываются, но вычитаются!

Лень искать все публикации, но вот одна из первых: http://cs.jhu.edu/~sdoshi/crypto/papers/p465-merkle.pdf

смена порта

Является классическим случаем security by obscurity, и как мы знаем, этот метод просто неработает. В интернетах полно «реликтового излучения» и если что-то там долбится в 22-й порт, то кого это чешит? Это просто «фоновое излучение» ботов. fail2ban/iptables решает ситуацию.

Здорово запутает атакующего

Нет. Атакующий тем то и отличается от тупых ботов, что имеет орган для ношения шляп. От него перенос на другой порт не спасает. К тому же я не припомню ни одной атаки на SSH. Этот порт для атакующего просто неинтерессен, неважно 22-й это или 53443-й. Т.ч. все эти переносы — детский лепет.

beastie ★★★★★
()
Ответ на: комментарий от kombrig

fail2ban отлавливал десяток попыток подбора пароля в день

Боты. Это не страшно.

beastie ★★★★★
()
Ответ на: комментарий от kostian

Как sshd на альтернативном порту понижает безопасность? :)

Ну хотя бы тем, что тебе кажится, что ты спрятался, а на самом деле нет. ☺

От тупой долбежки вполне «помогает».

Это никому не мешает. Пусть долбятся. Мешать это может только клиническим школярам-параноикам.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Перенос порта не средство защиты. Это примерно как муха в комнате.
Вроде особо и не мешает, а прибить хочется.

kostian ★★★★☆
()
Последнее исправление: kostian (всего исправлений: 1)
Ответ на: комментарий от kostian

не обязательно. Белый список может подразумевать просто доверенный пул адресов или отдельные адреса, откуда можно пытаться стучать на SSH неограниченно число раз в единицу времени (или лимиты намного мягче), ну и не уведомлять об каждом успешном логине из этих адресов.

Т.е., разделить на белый список, чёрный, и серый (все остальные).

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от kostian

точное сравнение - главное за привычной долбежкой ботов можно и попытку взлома прошляпить

kombrig ★★★
()
Последнее исправление: kombrig (всего исправлений: 1)

Спасибо очень большое, за столь активное участие, не думал, что тут такое живое сообщество. С iptables пока полностью не разобрался, но сделал Input, Forward drop по-умолчанию, разрешил доступ ко всем открытым портам, только со своего ip, так как сервер для dev, то лишние мне пока тут не нужны. Отключил root в ssh, для OpenVPN (chroot jail). Подумав - понял, что постоянная защита очень важна, но backup-ы важнее. Тем более важного на сервере ничего хранится не будет.

ruzniki
() автор топика
Ответ на: комментарий от beastie

Сильное уменьшение поля ключей. Атака перебором упрощается на несколько магнитуд. На пальцах можно это себе так представить, что ключи не складываются, но вычитаются!

Не знал, спасибо! А если алгоритмы шифрования разные при этом? Без разницы? То есть, в том же трукрипта опции двойного-тройного шифрования не только бесполезная трата вычислительных ресурсов, но еще и ущерб стойкости шифрования?

Зачем же их тогда добавили? О_о Мне казалось, что уж разрабы такой софтины как трукрипт в подобных вопросах должны более-менее соображать.

Liber
()
Ответ на: комментарий от Liber

Осторожно! Я не утверждаю, что этот феномен во во всех случаях проявляется, но он есть. Вопрос солжный, в том числе математически. Умные дядьки советуют избегать двойного шифрования. (Я не умный дядька.)

Про Truecrypt ничего не знаю, кроме названия. Не исключаю, что тот, кто впилил эту функцию в глубине вопроса не разбирается, а другие не подумали.

beastie ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.