Каков ваш контрольный список / процедура при настройке веб-сервера Linux?
Что посоветуете для достижения максимальной безопасности?
Есть ли какой-либо предпочтительный способ выполнения повторного обслуживания?
Прежде всего, имейте в виду, что любая возможность создания сценариев в Apache (php, cgi, ruby, ...) является потенциальным эквивалентом учетной записи оболочки с привилегиями пользователя, запускающего сценарий.
Если сервер совместно используется несколькими пользователями, вы можете подумать об использовании suexec (- или ИТК МПМ - Предложено Дэвид Шмитт), поэтому не все сценарии запускаются от имени одного и того же пользователя apache.
Виртуализируйте или chroot apache, чтобы любой компромисс хотя бы частично содержался в дополнительном уровне безопасности. Имейте в виду, что при chroot apache обслуживание может стать сложнее, так как вы в конечном итоге переместите библиотеки в тюрьму и т. Д. Если вы используете FreeBSD, вы можете использовать вместо нее тюрьму, что намного проще в обслуживании, так как вы можете просто установить apache из портов и запускайте portaudit изнутри, не беспокоясь о каких-либо зависимостях библиотеки и перемещая файлы вручную, что всегда становится уродливым беспорядком. С тюрьмами BSD вы можете просто продолжать использовать систему управления пакетами (порты). (В GNU / Linux вы также можете использовать VServer для виртуализации. - Предложено Дэвид Шмитт )
(очевидно) Следите за обновлениями и патчами не только для Apache, но и для PHP, ruby, perl и т. д. ... не доверяйте своей ОС, чтобы она также предоставляла вам все обновления. Некоторые дистрибутивы очень медленно выпускают патчи. Максимально ограничьте время воздействия уязвимостями нулевого дня. Прикрепите milw0rm в вашем RSS-ридере, подпишитесь на insecure.org списки рассылки и т. д. Это не только поможет вам узнать об уязвимостях до того, как ваша ОС дойдет до выпуска патча, вы также узнаете об уязвимостях, например, в определенных приложениях php cms, которые могут даже не управляться или исправляться вашим ОС у всех.
Используйте что-нибудь вроде tripwire / aide, audit или mtree (в BSD), чтобы отслеживать изменения в вашей файловой системе. Это действительно важно. Регулярно отправляйте вам любые изменения по почте, проверяйте их вручную каждый день. Если какие-либо изменения в файлах не должны изменяться, выясните, почему. Если какой-то вредоносный javascript каким-то образом будет вставлен на ваши страницы каким-либо методом, вы его поймаете таким образом. Это не только спасает ваш сервер, но и ваших пользователей, так как ваши собственные веб-страницы могут быть использованы для заражения посетителей. (Это очень распространенная тактика, злоумышленники часто даже не заботятся о вашем сервере, они просто хотят заразить как можно больше ваших посетителей, пока их не обнаружат. Эти злоумышленники также обычно даже не пытаются скрыть свои следы. Очень важно как можно быстрее найти такой компромисс.)
Используя такие вещи, как Сухосин для защиты php помогает. Но также научитесь понимать это, настройте его конфигурацию в соответствии с ожидаемыми параметрами вашего приложения.
Использование патча ядра, такого как PaX может помочь защитить вас от многих уязвимостей, связанных с переполнением буфера. Даже если ваше программное обеспечение уязвимо. (Это не делает вас неуязвимым, это просто еще один, второстепенный уровень.)
Не переусердствуйте при использовании какого-либо инструмента безопасности. Разбирайтесь с инструментами, которые вы используете, и руководствуйтесь здравым смыслом. Читайте, учитесь, успевайте как можно больше.
Рассмотрите возможность использования принудительного контроля доступа (например: SELinux). Он позволяет вам подробно указать для каждого приложения, что ему разрешено делать. К каким файлам разрешен доступ. Какие вызовы ядра ему разрешено делать и т. Д. Это очень сложный процесс, требующий большого понимания. Некоторые дистрибутивы предоставляют готовые политики SELinux для своих пакетов (например: Gentoo ). Это предложение является своего рода противоречием приведенному ниже, но, тем не менее, все еще актуально.
Будьте проще. Сложная стратегия безопасности может сработать против вас.
В Apache установите очень строгие правила по умолчанию («Нет», «Запретить от всех» и т. Д.) И при необходимости измените их для конкретных VirtualHosts.
Запретить доступ ко всем точечным файлам (что также немедленно распространяется на файлы .htaccess)
Всегда используйте https везде, где есть какая-либо аутентификация по паролю.
Брандмауэр должен быть политикой запрета по умолчанию. Создайте определенные правила в вашем брандмауэре для регистрации определенного трафика.
Настройте сценарии анализа журналов для сканирования журналов на наличие аномалий. (в прелюдия IDS Suite может это сделать, но, честно говоря, я рекомендую вам со временем создавать свои собственные сценарии, поскольку это поможет вам лучше понять свои собственные инструменты и правила.)
Пусть сервер отправляет вам ежедневные отчеты о последних авторизованных пользователях, активных подключениях, используемой пропускной способности и т. Д.
Выполните сканирование cron на предмет наличия бинарных файлов suid, файлов, доступных для записи, и тому подобного, и отправьте их вам по почте.
Для любого настроенного вами материала, который отправляется вам по почте, вы должны со временем составить список исключений. (папки, чтобы игнорировать изменения файловой системы, 777 файлов, чтобы разрешить, suid двоичные файлы, чтобы разрешить). Важно, чтобы вы получали уведомления только о том, чего не должно происходить. Если вы каждый день будете получать почту с пустяками, вы начнете их игнорировать, и они станут бессмысленными.
Разработайте надежную стратегию многоуровневого резервного копирования. И не думайте, что создание изображения или копии всего работает. Например, если MySQL находится в процессе записи в таблицу во время резервного копирования, ваши двоичные файлы MySQL могут быть повреждены при восстановлении резервной копии. Таким образом, вам понадобится cron, который mysqldump будет размещать ваши базы данных поверх обычных образов или ночных архивов tar, контроля версий или чего-то еще, что вы настроили. Подумайте о своей стратегии резервного копирования. Я имею в виду, ДЕЙСТВИТЕЛЬНО подумайте об этом.
Не полагайтесь на такие списки ради безопасности :) Серьезно! Вы найдете множество таких предложений в Интернете, прочтите их все, изучите каждое предложение и используйте здравый смысл и опыт, чтобы составить собственное мнение. В конце концов, опыт и здравый смысл - единственное, что вас спасет. Ни списков, ни инструментов. Читайте, но не копируйте, не понимая.
Я рекомендую Контрольный список безопасности Linux, из SAN. Я использую это, а также другие внутренние процедуры. Контрольный список может быть немного устаревшим, но многие ключевые моменты остаются верными.
отредактируйте ваш ~ / .ssh / config
permit_root_login no
это делает
ssh root@server
не отвечаю но
ssh user@server
user$ su
будет работать, если вы хотите войти в систему как root.
Всегда будет бесчисленное количество разрешений для проверки, бесчисленные контрольные списки, бесконечное обнаружение новых ошибок / уязвимостей. Безопасность Я бы не подумал, что это то, что вы включаете или выключаете, это то, что вы делаете постоянно.
Учитывая «неизбежный сбой» программного обеспечения, SELinux помогает избавиться от некоторых опасений (опять же, нет серебряной пули для безопасности). предполагая, что приложение пользовательского пространства скомпрометировано, правильная политика SELinux не позволит ему действовать с обычными (т.е. если SELinux был отключен или разрешен) привилегиями. Это, конечно, потребует от вас мониторинга журналов аудита и анализа установленной политики и изменения ее, где это необходимо, чтобы приложения могли работать.
Я не говорю, что политика по умолчанию не поможет, но мне лично хотелось бы знать, что она позволяет.