Комментарии 18
картинки - огонь! порадовали)))
Блин, так не смешно же!
М? Касательно чего?)
ну с Хентай - смешно)
Расстраиваете меня вместе с @Najtan
Классика же как и про сапожищи хреновые :)
Штош, в принципе не плохо. Посмеяться от души в принципе получилось.
Касательно советов саглы, вроде элементарные истины (почти всё, в список изврат в виде блока boot раздела нужно уже на ИБшников спихивать), а многие забывают про них и плюются потом, что данные увели или сайт лагал неделю из-за нагрузок, а это майнер. Для начинающих сойдёт как вводная инфа, для прохаванных как шпаргалка, когда начинается очередной тупняк) .
Но имхо, так сказать, с высоты своего опыта категорически заявляю: "Юзеры" даже с 2я высшими образованиями воспользоваться статьёй не смогут. У них бывает что интернет не работает, а причина тому выключенный монитор, что уж так говорить о консольке?
В общем, деду нравится (V)_0o_(V)
Про LastPass - это Вы конечно сильно пошутили
Ну таки есть такое. Я бы предпочёл что-то крутящиеся у себя локально, нежели в облаке. Аля teampass. Правда для рядового юзера - это запретные технологии анненербэ, так что, только свои собственные методы сохранения пароля - велком. Я когда проходил сертификацию в одной конторке, так там самая примитивная схема:
Все работают по ключам.
Пароль как последнее средство, хранился в конверте в сейфе.
Но это что-то мы уже в степь для взрослых переползаем)
Про антивирь огромное спасибо! Всё руки не доходили заняться этой темой, а тут оказывается поднимается всё в "два клика". Так держать автор! Статью в закладки.
А вот LastPass всё таки в шахту! И все остальные менеджеры паролей - в топку! Буквально сегодня видел топик о то что очередной популярный менеджер взломали. Шляпа это всё. Проще зашифрованного текстового файла и ручной копипасты паролей ничего не придумано. SSH-ключам тоже не доверяю, угнать при желании - возможно.
пароль должен включать в себя минимум 12 символов и состоять из цифр, букв разного регистра и спецсимволов
Популярный мем, который приживается в недостаточно развитых мозгах.
Количество символов, их тип не играют роли по отдельности. Важна энтропия, или другими словами, число вариантов. Пароль, в котором лишь один символ (например 1111111...), при достаточной длине ничем не хуже aeF6mei6. Пароль — это всего лишь число, которое недалёкие админы и программисты требуют записывать в определённой системе исчисления.
Пароль из единиц - это всего лишь число, хеши которого, например, присутствуют в радужных таблицах и для одного символа, и для 8, и для 12, и для 20 символьной версии, а вот для числа aeF6mei6 ответа в радужной таблице не нашлось. Чем вы можете это объяснить? )
Достаточностью длины? Именно это и имел ввиду автор того комментария. Так да, для 8, 12 и 20 нашлось. А для 53? А если этих единиц еще больше (несколько десятков все еще валидный для ввода человеком пароль)? Именно энтропия. И только.
Прикол в том что, внезапно, и для 53 единиц ответ есть и для 100 (серьезно), есть дырки, но все промежуточные я не проверял. Поэтому предложение использовать пароли из одинаковых символов длинной в несколько десятков я не буду считать таким же полезным, как совет от автора. Пусть мозг недостаточно развит, зато пальцы сберегу на коротких паролях. )
Базара 0, братан, но имхо статья то для самых маленьких по сути. И что, сразу заставить молодняк с двухног влетать вот в это вот всё? Мы так без джунов останемся вовсе.
Но комент твой норм, не спорю.
ssh-keygen -t rsa
Интересно, в каком современном дистрибутиве не RSA по умолчанию? Уж если на то пошло, стоит советовать использовать современный ed25519, например.
Для того, чтобы определить, какие порты слушаются локально, воспользуемся утилитой
netstat.Для портов, доступных извне, применим утилитуnmap.
sudo netstat –ntulp
В современных дистрибутивах запросто может отсутствовать. Учитывая, что net-tools давно считается устаревшим, не понятно почему не привести пример с использованием iproute2: ss работает тут с теми же ключами, что и netstat.
nmap localhost
А если сокет открыт только на localhost? А если наоборот - слушается только внешний адрес?
Теперь зная, какие порты используются, мы можем закрыть ненужные с помощью утилиты
iptables. Пример синтаксиса для закрытия порта:
sudo iptables -A INPUT -p tcp --dport <номер порта> -j DROP
Почему бы не подойти с позиции "запрещено всё, что не разрешено" и не сделать правило по умолчанию -P INPUT DROP, предварительно рассказав как разрешить ответный для исходящего трафик?
После того, как вы завершите настройку портов, нужно сохранить все созданные правила, чтобы они остались активными даже после перезагрузки. Для этого выполните:
sudo iptables-save
И вы увидите текущие правила по всем цепочкам всех таблиц на своём экране. Чтобы правила сохранились после перезагрузки, потребуется поставить пакет iptables-persistent, а сохранить, например, так: sudo iptables-save | sudo tee /etc/iptables/rules.v4
Теперь можно посмотреть активные правила:
sudo iptables -L -n -v
Вот как раз посмотреть все правила разом удобно через sudo iptables-save, а эта команда покажет их лишь для таблицы filter - для любых других надо будет воспользоваться ключиком -t
Чтобы предотвратить несанкционированное изменение загрузочных файлов, которые имеют решающее значение для бесперебойной работы вашего сервера, рекомендуется изменить уровень доступа на «read only».
Для этого просто отредактируем файл:
/etc/fstabВ конец файла добавляем строку:
LABEL=/boot /boot ext2 defaults, ro 1 2
Чтобы туда писать, надо иметь права root. Но если они уже есть, то и перемонтировать на запись будет не проблема - хост скомпрометирован полностью. Зато всякий раз обновление системы будет ругаться, что не может записать свежее ядро - надо вспомнить что сначала надо перемонтировать раздел. Кроме того, а если у меня /boot не в ext2 и раздел с другим лейблом или вовсе без него? В общем, это какая-то изящная схема доставить себе боль и страдания и только.
Также при взломе бесплатного сертификата ответственность лежит только на владельце сервиса, в то время как за взлом платного сертификата вы уже точно будете знать, в кого кидать тапки и даже что-то потяжелее.
Что имеется ввиду под "взломом сертификата"? Допустить утечку приватного ключа одинаково просто как для платного, так и для бесплатного сертификата. И тут бесплатный от Let's Encrypt выглядит даже более безопасным: если утечка осталась незамеченной, есть шанс что поменяют с новым приватным ключом через три месяца. В случае купленного сертификата это может произойти куда позже.
По ssh дополню:
Включить Protokol 2
Отключить вход по паролю и БЕЗ пароля
Поставить таймаут на сессию
Если меняем порт ssh, то неплохо его открыть в фаерволе.
Перед установкой file2ban обязательно сделать резервную копию ;)
Параноидальная защита: ввести белый список ip для доступа по ssh, отключать ssh в панели хостинга и включать по мере необходимости, использовать google authenticator для ssh (да, да это возможно), порт кнокинг.
Защищайся! Простые и не очень правила настройки безопасности для VPS/VDS на Linux