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-ного "— " на два минуса подряд.
Все эти советы ну совсем для чайников. Был случай ещё в начале 2000-х, вломили нам сервер, пролезли через дыру в ssh, как потом выяснилось. Сервак был тестовым и за него как-то забыли, но суть не в этом. Обнаружился взлом случайно, тк через него повалил подозрительный трафик. Когда зашли на него, ничего подозрительного не обнаружили, netstat, lsof, ps ничего не показали. Однако nmap c другой малины роказал несколько "левых" открытых портов. Короче, на машину установили руткит, который прятал всю активность. Заменили libps и ещё кучу утилит — сейчас уже подробностей не помню. К чему я это всё рассказываю? Если сервер взломан, и сделал это опытный хакер, то на самой машине вы так просто ничего не обнаружите.
Чтобы что-то обнаружить есть http://rkhunter.sf.net/ и http://www.chkrootkit.org/.
Как-то больше ожидалось увидеть информацию не по съему информации об открытых портах, правах на каталоги и список установленных пакетов. Это скорее общерекомендательные для серверов на базе linux. Название статьи не соответствует содержимому, т.к. все то что описали прекрасно подойдёт и для samba, ftp, ssh, etc.
Было бы поучительно рассмотреть защищённость от атак определенного вида свежеустановленной системы с типичными настройками. И действия в процессе эксплуатации, которые эту защищённость уменьшают. Или наоборот.
А то защита сферического веб-сервера с помощью chmod это как-то не очень.
Из собственных (ну и нетолько) практик: 0) вход по SSH только по ключу, никаких паролей, 1) перенос порта ssh на какой-нибудь малоизвестный, чтоб не обстукивали так рьяно. 2) fail2ban.
Если посмотреть, что делает DigitalOcean на своих готовых дроплетах (например, wordpress) — они по умолчанию гасят все порты, кроме 80-ого, 443-ого и ssh.
Сам бы хотел бы узнать, как правильно организовывать учётные записи на общем линукс сервере (например, какой-то production сервер). Сколько учётных записей должно быть? Один на каждого разработчика? Или общий на всех? root / не root? Стоит ли заморачиваться с запиливанием ACL? Как организовывать группы?
Все зависит от решаемых задач, количества учётных записей, количества серверов, числа администраторов… Все способы правильные, но некоторые более удобные.
Чтобы обстукивали меньше? Уменьшить энтропию вселенной или что?
Или это такая защита от zero-day багов, которых за кучу лет проекта уже просто нет?
Каждый должен заниматься своим делом: разработчики — разрабатывать, админы — админить.
LAMP? а не слишком ли устарела данная книга?
А что, разве php уже похоронили? ;)
Раздел «Изоляция процессов в контейнерах» можно вообще выкинуть (или перенести в отдельную тему и там развёрнуто раскрыть), тут он совершенно ни о чем. Совет упаковать базу данных в контейнер, я бы вообще отнёс к вредным, никогда бы не стал так делать.
В разделе «Сканирование портов» рассказывается только о сканировании изнутри, и ни слова нет про сканирование снаружи.
В разделе «Проверяем наличие опасных значений пользовательского ID» очень скудно описывается команда sudo. Все обозначенные автором проверки сводятся к нулю, если предварительно не проверить конфиг самого sudo.
Ваше 1 издание уже невозможно купить: самое время начать перевод второго.
www.manning.com/books/dependency-injection-in-dot-net-second-edition
Защищаем веб-сервер на Linux