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