Проблемы безопасности UNIX-подобных ОС и Web 0

есть ошибочки :) в тексте.

стр.3, п.5, команда # echo tty1 > /etc/securetty

стр.4, п.7, команда # find / -perm +06000 -ls (кстати, в Debian есть /var/log/setuid.*, в которых приводится список списоктаких файлов и ежедневные изменения оных: .today, .yesterday, .changes.N.gz)

стр.5, п.11, уточнение: в случае logrotate необходимо предварительно всё же снимать атрибут… либо отключать logrotate, и следить за ростом файла самостоятельно. как дополнительная мера, подобные сообщения можно отправлять через ssl-соединение (посредством ssh) на другую машину… (ну и п.12 для этого тоже можно использовать — для отправки уведомлений о наступании на ловушки.)

стр.53, п.88. на самом деле — не так уж и сложно ;) но это действительно не очень удобно получится — если получился root-доступ, то тут не подрыгаешься, а если не столь привелигированный пользователь — то можно и запретить при помощи iptables (расширение owner). правда, долго думать надо, что можно, а что — нельзя..

ps: а вообще, Пособие… :D

Спасибо за ошибки! :))) Исправим.

Где-то через недельку закончу и выложу вторую часть.

Параллельно статьи в html есть на http://adz.void.ru и http://win-lin.h15.ru

Вцелом, писоединяюсь к мнению Genie — это пособие. Однако всё равно есть пара замечаний.

Хм, ну начнём с того, что некоторое количество пунктов, в которых упоминаются размещения логов, аттрибуты на некоторые каталоги (п.2, 35, 61 и, может быть, ещё какие-то, которые я упустил) — это уж очень дистрибутивно зависимое (дайте-ка я угадаю — debian;), хотя в п.53 что-то упоминается про Mandrake. Неужели и к нему прикрутили apt?).

Чем повышает безопасность системы п.11, если взломщик уже с правами root’а, я так и не понял =/ (тоже относится и к 'chattr +i /etc/inetd.conf' в п.87). Так же не ясно, каким образом отключение перезагрузки по ctrl+alt+del (п.23) повышает безопасность системы?

В п.15, действительно, полезные знания по поводу поиска файлов с маской по заданной дате. Но к безопасности это имеет весьма косвенное (я бы даже сказал — сомнительное) отношение. Ничего не мешает задать файлу любую дату создания командой touch.

По поводу п.41. Кто-то ещё пользуется rsh? Если уж говорить о безопасности, то первое (и последнее ;)), что надо сказать про этот rsh, так это совет отказаться от него в пользу ssh.

В п.47 рассказывается о том, как обезопасить FTP-сервер. Но непонятно следующее: «поскольку анонимный FTP позволяет получить доступ любому, всё же нельзя позволять доступ любому хосту. В место этого вы должны выбрать один хост, с которого будет разрешён анонимный доступ» — в чём тогда вообще смысл анонимного доступа у такого сервера? Чтобы те, у кого нет прав на доступ к FTPшнику сначала искали машинку с разрешённым анонимным доступом, а потом стояли в очереди на работу за этой самой машинкой? Интересно, где такая схема будет применяться? А если защищаемый FTP-сервер -это мой домашний компьютер, который находится в домовой сети? Какому хосту там разрешать анонимный доступ? Не, не для того придуман анонимус в FTP… Либо их всех «резать», либо ставить FTP-сервер с хорошим уровнем защиты (тот же vsftpd) и пускать его (сервер) от пользователя с минимальными привелегиями, предварительно грамотно и скурпулёзно его настроив ;).

По п.49 небольшое замечание. «Почему по умолчанию их [демонов] включается так много? Просто многие дистрибутивы Linux пытаются попасть на рынок за счёт большего числа возможностей».

Так и напрашивается: и получить ещё больше вопросов, типа: «почему у меня всё тормозит» и «как мне теперь всё это выключить» ;). Правильная мысль, что разработчики дистрибутивов «пытаются попасть на рынок за счёт большего числа возможностей», но вывод немного некорректен. ИМХО, столько сервисов включается по умолчанию не для того, чтобы пользователи меньше спрашивали, как включить тот или иной сервис, а по той простой причине, что дистрибутив делают для среднестатистического компьютера. Вот и включают туда многое, что для кого-то оно нужно, а для кого-то и лишнее.

П.53 «Файл shells в той же папке [/etc]. Он хранит адрес к shell. Тоже лучше сменить на недостоверную информацию.»

На какую «недостоверную»? В этом файле хранится список шеллов, в которые разрешено логиниться. Боюсь, если изменить в нём пути на «недостоверную информацию», то фиг потом залогинишься. Или я просто недопонял мысли?

В п.71 ссылка на уязвимость в gunzip (http://www.immunitysec.com/GOBBLES/advisores/GOBBLES-01.txt) битая =(. Просто хотелось узнать версию уязвимого gunzip’а. Если она древнючая (пару-тройку лет), то даже как-то нестрашно ;).

В п.77 говорится, что взломщик сначала длолжен сам внести строку в файл /etc/exports:

echo '/ bad_guy_comp(rw,no_root_squash)' >> /etc/exports

а затем говоится, что из этой строки можно получить hostname злоумышленника (!). Ну какой вменяемый злоумышленник внесёт сам имя своей машины в какой бы то ни было файл на атакуемой машине? Скорее он сделает:

echo '/ rw,no_root_squash' >> /etc/exports

А команды 'pc' и 'rpcinfo' он, кстати, тоже изменит ;). Поэтому тут бы уточнить, что эти самые 'pc' с 'rpcinfo' (и другие утилиты, которые могут понадобиться) надо бы скачать с заведомо доверяемой машины.

По п.86 просто придирусь =Р. Там вместо ручного копирования (с помощью всяких scp и cat’ов) своего публичного ключа в authorized_keys можно использовать штатный скрипт ssh-copy-id.

P.S. мои замечания, возможно, из-за незнания или недопонимания чего-либо. Так что не обессудьте, а всего-лишь поправьте. А работа, и вправду, отличная. Жду следующей части ;).

Вот. Поправил ;)

http://win-lin.h15.ru/file/PRE_REI.pdf (488 кБ — .pdf-версия)

http://win-lin.h15.ru/file/PRE_REIMS.zip (90 кБ — .doc-версия)

http://win-lin.h15.ru/file/PRE_REIO.zip (89 кБ — .sxw-версия)

Не, ну а притчу куда дел?! ;)

В п.5 ты опять опечатался. Обрати внимание куда ты поставил треугольную скобку '>' и куда её надо поставить.

Далее.. Не то, чтобы придираюсь, но всё-таки в п.23 даже если запрещена перезагрузка по ctrl_alt_del, то при физическом доступе всегда есть возможность систему перезагрузить =(. Так что, твой способ — не панацея.

В п.41 как-то не по-русски ты выразился: «единственно безопасный путь использовать rhosts — это запретить его использовать в системе». Тогда уж лучше: «Однако для повышения безопасности системы лучше вообще отказаться от использования rhosts в пользу более защищённых аналогов (например, ssh)».

В п.46 ты напечатал лишнее (курсивом) слово и одно пропустил (жирным): «в старых версия, например Sendmail были найдены ошибки кода, позволяющие получать привелегии root неавторизованным пользователям». Видимо, в первом прочтении твоего труда я на это просто не обратил внимания.. =/

Хм, в п.49 ты теперь вовсе убрал «вступительные» строки. А вот зря. Нужно хотя бы объяснить, что чем больше сервисов запущенно, тем больше вероятность уязвимости системы. Поэтому рекомендуется отключать ненужные сервисы. Описание наиболее распространённых сервисов в таблице ниже… <font size=«-2»>ну, и далее по тексту…</font>

Моё замечание к п.53 ты почему-то оставил без внимания. А, ведь, действительно интересно, что именно и на какую «недостоверную» информацию рекомендуется изменить.

Обрати внимание куда ты поставил треугольную скобку '>' и куда её надо поставить.

LOL ! Как еще в первом топике увидел подумал — бе-е как так ошибиться можно. Исправил неглядя.

Фу-ух. Вроде бы все. Даже притчу вернул.

+ начало второй части

http://win-lin.h15.ru/file/PRE_REII.pdf (185 кБ, .pdf-версия)

IST1 Обрати внимание куда ты поставил треугольную скобку '>' и куда её надо поставить.

LOL ! Как еще в первом топике увидел подумал — бе-е как так ошибиться можно. Исправил неглядя.

Фу-ух. Вроде бы все. Даже притчу вернул.

А pdf версию не поправил…

И всё-таки по п.53. «Файл /etc/shells хранит адрес к shell» —- на самом деле, этот файл хранит список «валидных» login shell’ов. Если в нём написать чепуху, то могут возникнуть проблемы с логином локальных пользователей на, например, FTP-сервер, который запрещает доступ пользователей, чьи login shells не перечисленны в /etc/shells. Есть ещё приложения, которые будут неадекватно себя вести при таких фокусах с /etc/shells (кажись, GDM это не понравится).

Ты б объяснил, зачем скрывать данные из этого файла?

А pdf версию не поправил…

Как поправил, сразу и написал сообщение. Просто прокси «отдал» кэшированную версию. Такое часто бывает.

Если в нём написать чепуху, то могут возникнуть проблемы с логином локальных пользователей на, например, FTP-сервер, который запрещает доступ пользователей, чьи login shells не перечисленны в /etc/shells

Этого не знал. Спасибо. Хотя проблем у меня пока не возникало.

Добрался я до твоей второй части.

В п.100 написано: «В файле /etc/login.defs есть параметр umask. Обычно он закоментирован». Напрашивается сразу же: «и что?». Какая-то незаконченная мысль.

В п.102 указал бы, в каком это дистрибутиве, а-то у себя в SuSE я /etc/security/console.apps не нашёл.

В п.119 рассказывается о переполнении буфера в операторе printf. Потом гооврится, что чтобы избежать ошибок переполнения буфера, необходимо всегда проверять длину вводимой строки. Однако почему-то ничего не сказал о более защищённых аналогах sprintf и snprintf, которые часто и рекомендуется использовать.

П.С. pdf версия первой части всё ещё скачаивается старая..=(

Пару часов назад скачал — новая версия (???).

А сейчас даже ping не проходит. Как будто и нет его.

Выложил здесь http://top-security.narod.ru/PRE_REISE.pdf

п.101. файл имеет довольно странное имя. :)

п.106. странное название протокола TVP =)

п.123. где-то это на форуме уже было… И точно: «Linux-уязвимость forkbomb: привет из прошлого» :))