Pull to refresh

Comments 34

Приветствую инициативу — переводить отрывки из только что вышедших или еще не вышедших книг, молодцы.
В данном отрывке сразу например упал глаз на:
$ chmod 770 datafile.txt
и дальнейший текст в общем соответствует. Может это отрывок из первой, вводной главы для самых маленьких? Тогда автор (книги) выбрал странный способ рекламы.
В общем переводчики молодцы, а насчет книги у меня сомнения.

Желательно еще чтобы автор статьи проверял сам, что он публикует, вне зависимости от того, проверяли ли оригинальне авторы. Например
# systemctl list-unit-files — type=service — state=enabled
копируйте в консоль и выполните — получится «0 unit files listed.» на работающей системе.
Вместо такого надо исполнять
systemctl list-unit-files --type=service --state=enabled
Ну я-то, с опытом, догадался, что надо делать, а начинающие врядли догадаются до замены стоящего в странице html-ного "— " на два минуса подряд.
UFO just landed and posted this here
netstat вместе со всем бандлом net-tools уже лет 6 как deprecated. В Debian Buster из широко используемого софта от него зависят только установщик Openstack, Bind и Cloud-init.
очень классно говорить deprecated и не говорить в пользу чего )
В пользу ss. Однако я, например, терпеть его не могу.
Он просто неудобный и часто не применяет те фильтры, которые указаны в командной строке по каким-то свои синтаксическим соображениям. В результате получается проще вывести всё, а потом отгрепать.

Все эти советы ну совсем для чайников. Был случай ещё в начале 2000-х, вломили нам сервер, пролезли через дыру в ssh, как потом выяснилось. Сервак был тестовым и за него как-то забыли, но суть не в этом. Обнаружился взлом случайно, тк через него повалил подозрительный трафик. Когда зашли на него, ничего подозрительного не обнаружили, netstat, lsof, ps ничего не показали. Однако nmap c другой малины роказал несколько "левых" открытых портов. Короче, на машину установили руткит, который прятал всю активность. Заменили libps и ещё кучу утилит — сейчас уже подробностей не помню. К чему я это всё рассказываю? Если сервер взломан, и сделал это опытный хакер, то на самой машине вы так просто ничего не обнаружите.

Как-то больше ожидалось увидеть информацию не по съему информации об открытых портах, правах на каталоги и список установленных пакетов. Это скорее общерекомендательные для серверов на базе linux. Название статьи не соответствует содержимому, т.к. все то что описали прекрасно подойдёт и для samba, ftp, ssh, etc.

Было бы поучительно рассмотреть защищённость от атак определенного вида свежеустановленной системы с типичными настройками. И действия в процессе эксплуатации, которые эту защищённость уменьшают. Или наоборот.
А то защита сферического веб-сервера с помощью chmod это как-то не очень.

Странно, что в статье нет ничего ни про ufw, ни про iptables (т.е сеть)
Из собственных (ну и нетолько) практик: 0) вход по SSH только по ключу, никаких паролей, 1) перенос порта ssh на какой-нибудь малоизвестный, чтоб не обстукивали так рьяно. 2) fail2ban.
Если посмотреть, что делает DigitalOcean на своих готовых дроплетах (например, wordpress) — они по умолчанию гасят все порты, кроме 80-ого, 443-ого и ssh.

Сам бы хотел бы узнать, как правильно организовывать учётные записи на общем линукс сервере (например, какой-то production сервер). Сколько учётных записей должно быть? Один на каждого разработчика? Или общий на всех? root / не root? Стоит ли заморачиваться с запиливанием ACL? Как организовывать группы?
А есть какие-то альтернативы по одному на разработчика? Или после каждого ухода будете менять пароль от пользователя?
… пароль, как минимум, а если ходят беспарольно, т.е. по ssh-ключам, то еще и новые ключи всем раздавать — то еще гемор.
У нас был один общий юзер. К нему (в authorized_keys) просто дописывали (или удаляли) ssh ключи с машин разработчиков.
Думаю по учетке на каждого дев-а наилучшая практика. Если кто-то начнет беспределить в проде — будет легче вычислить и предпринять меры. Вообще если под одной учеткой работают более одного человека — уже нехорошо. Проще будет с раздачей root/не-root. ACL? Вы про setfacl? Штука в принципе годная, если с самого начала сделать всё по уму (где-то читал, что максимально надо выжать всё из chmod/chown/сhgrp, а если не получается — идти уже в ACL) — т.е. в setfacl «вешать» только группы, а не учетки отдельных пользователей. Кстати на всех виндовых файловых серваках делаю именно так, никаких отдельных пользователей в «security» на директории — проще изменять/отслеживать.
Да, наверно про setfacl. Я на самом деле с этой штукой не игрался — она по дефолту в убунте не доступна, да и нужды в такой гранулярности вроде не было.

Все зависит от решаемых задач, количества учётных записей, количества серверов, числа администраторов… Все способы правильные, но некоторые более удобные.

Вот объяснит кто-то зачем переносить ssh на другой порт?
Чтобы обстукивали меньше? Уменьшить энтропию вселенной или что?
Или это такая защита от zero-day багов, которых за кучу лет проекта уже просто нет?
Защита от замусоривания auth.log
unabl4, как сисадмин могу сказать, что идеально, когда НА ПРОДЕ количество учётных записей разработчиков равно НУЛЮ.
Каждый должен заниматься своим делом: разработчики — разрабатывать, админы — админить.
Статью однозначно в закладки. Присоединюсь к предыдущим коментаторам — сделайте аналогичную «выжимку-памятку» по iptables.

LAMP? а не слишком ли устарела данная книга?

А что, разве php уже похоронили? ;)

Зная разницу в скорости между apache и nginx сложно уже пользоваться первым.

В контексте защиты сервера есть принципиальная разница, apache внутре или nginx?

Да, они по-разному работают и по-разному оказывается запущен PHP. В статье советы как будто щас 90ые, только джэйлы заменили контейнерами.

Так безопасность на 99.9% это администрирование. В этом отношении за 20 лет что-то поменялось, но статья не об этом.

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

Раздел «Изоляция процессов в контейнерах» можно вообще выкинуть (или перенести в отдельную тему и там развёрнуто раскрыть), тут он совершенно ни о чем. Совет упаковать базу данных в контейнер, я бы вообще отнёс к вредным, никогда бы не стал так делать.

В разделе «Сканирование портов» рассказывается только о сканировании изнутри, и ни слова нет про сканирование снаружи.

В разделе «Проверяем наличие опасных значений пользовательского ID» очень скудно описывается команда sudo. Все обозначенные автором проверки сводятся к нулю, если предварительно не проверить конфиг самого sudo.
Вы совершенно правы, переводить необходимо и переводить будем: контракт уже получен, ждем финальную версию текста
Sign up to leave a comment.