Недавно (но это также повторяющийся вопрос) мы увидели 3 интересные темы о взломе и безопасности:

Как мне работать с взломанным сервером? ,
Обнаружение того, как взломал сервер был взломан
правами доступа к файлам вопрос

Последний не имеет прямого отношения, но он показывает, насколько легко запутаться в администрировании веб-сервера.

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

Это не только вопрос защиты сервера и кода, но также аудита, регистрации и контрмер.

Есть ли у вас какие-либо рекомендации, или вы предпочитаете полагаться на программное обеспечение или экспертов, которые постоянно анализируют ваш веб-сервер (ы) (или вообще ничего)?

Если да, можете ли вы поделиться своим списком и вашими идеями / мнениями?

ОБНОВИТЬ

Я получил несколько хороших и интересных отзывов.

Я хотел бы иметь простой список, который может быть полезен для администраторов ИТ-безопасности, а также для мастеров веб- фактотума .

Даже если бы все давали хорошие и правильные ответы, в данный момент я предпочитаю тот, что Роберт, так как он самый простой, понятный и лаконичный, и тот, что sysadmin1138, поскольку он самый полный и точный.

Но никто не учитывает точку зрения и восприятие пользователя, я думаю, что это первое, что нужно учитывать.

Что подумает пользователь, когда посетит мой взломанный сайт, гораздо больше, если вы располагаете разумными данными о них. Дело не только в том, где хранить данные, но и в том, как успокоить злых пользователей.

А как насчет данных, СМИ, органов власти и конкурентов?

Есть две большие области, чтобы сосредоточиться на:

1. Делая это трудно войти.
2. Создание политик и процедур, позволяющих спокойно и эффективно обрабатывать события, когда кто-то попадает в точку 1.

Делая это трудно войти

Это очень сложная тема, и во многом она сводится к тому, чтобы убедиться, что у вас достаточно информации, чтобы выяснить, произошел ли WTF после свершившегося факта. Абстрактная маркировка указывает на простоту:

• Вести журналы (см. Также раздел «Управление информацией о безопасности»)
  • Любые попытки авторизации, как успешные, так и неудачные, предпочтительно с сохранением исходной информации.
  • Журналы доступа к брандмауэру (возможно, должны включать брандмауэры для каждого сервера, если они используются).
  • Журналы доступа к веб-серверу
  • Журналы аутентификации сервера базы данных
  • Журналы использования для конкретного приложения
  • Если возможно, SIEM может выдавать предупреждения о подозрительных шаблонах.
• Обеспечить надлежащий контроль доступа
  • Убедитесь, что права установлены правильно везде, и избегайте «ленивых прав» («о, просто дайте всем прочитать»), где это возможно.
  • Периодические проверки ACL, чтобы убедиться, что процедуры действительно выполняются, и временные шаги по устранению неполадок («прочитайте все, посмотрите, работает ли он тогда») были правильно удалены после завершения устранения неполадок.
  • Все правила сквозного межсетевого экрана должны быть обоснованы и периодически проверяться.
  • Контроль доступа к веб-серверу также должен подвергаться аудиту, как ACL для веб-сервера, так и для файловой системы.
• Обеспечить управление изменениями
  • Любые изменения в среде безопасности должны централизованно отслеживаться и проверяться более чем одним человеком.
  • Патчи должны быть включены в этот процесс.
  • Наличие общей сборки ОС (шаблона) упростит среду и упростит отслеживание и применение изменений.
• Отключить гостевые учетные записи.
• Убедитесь, что все пароли не установлены по умолчанию.
  • Готовые приложения могут настраивать пользователей с предопределенными паролями. Поменяй их.
  • Многие IT-устройства поставляются с очень хорошо известными парами пользователь / пароль. Измените их, даже если вы входите в эту штуку только один раз в год.
• Практика наименьших привилегий. Предоставьте пользователям доступ, который им действительно нужен.
  • Для пользователей с правами администратора целесообразно использовать две учетные записи. Одна обычная учетная запись используется для работы с электронной почтой и другими офисными задачами, а вторая - для работы с повышенными привилегиями. Виртуальные машины облегчают жизнь.
  • НЕ поощряйте регулярное использование общих учетных записей администратора / root, сложно отследить, кто что делал и когда.

Создание политик и процедур, позволяющих спокойно и эффективно обрабатывать случай попадания кого-либо

Политика безопасности событий является обязательной для всех организаций. Это значительно уменьшает фазу реагирования «бегать с отрубленными головами», поскольку люди, как правило, становятся иррациональными, когда сталкиваются с такими событиями. Вторжения большие, страшные дела. Стыд от перенесенного вторжения может привести к тому, что сглаженные системные администраторы начнут неправильно реагировать.

Все уровни организации должны быть осведомлены о политике. Чем больше инцидент, тем более вероятно, что высшее руководство будет каким-то образом вовлечено, и установление процедур для обработки вещей очень поможет в отражении «помощи» с высоты. Он также обеспечивает уровень покрытия для техников, непосредственно участвующих в реагировании на инциденты, в форме процедур для среднего звена по взаимодействию с остальной частью организации.

В идеале ваша политика аварийного восстановления уже определила, как долго определенные службы могут быть недоступны до того, как политика DR вступит в силу. Это поможет реагированию на инциденты, поскольку такого рода события являются бедствиями. Если событие относится к типу, в котором окно восстановления НЕ будет выполнено (например, сайт аварийного резервного копирования DR получает в реальном времени поток измененных данных, а злоумышленники удалили кучу данных, которые были реплицированы на сайт DR до того, как они были Таким образом, необходимо будет использовать процедуры холодного восстановления), тогда высшее руководство должно будет участвовать в переговорах по оценке риска.

Некоторые компоненты любого плана реагирования на инциденты:

• Определите скомпрометированные системы и раскрытые данные.
• Заблаговременно определите, нужно ли сохранять юридические доказательства для возможного судебного преследования.
  • Если необходимо сохранить доказательства , не трогайте ничего об этой системе, если только это не требуется . Не входите в него. Не просеивать лог-файлы. Делать. Не. Нажмите.
  • Если необходимо сохранить доказательства, скомпрометированные системы должны быть оставлены в сети, но отключены до тех пор, пока сертифицированный эксперт по компьютерной криминалистике не сможет анализировать систему способом, совместимым с правилами обработки доказательств.
    • Выключение скомпрометированной системы может испортить данные.
    • Если ваша система хранения разрешает этот (дискретное устройство SAN) снимок соответствующих LUN перед отключением и помечает их как доступные только для чтения.
  • Правила обработки доказательств сложны и, о, так легко облажаться. Не делайте этого, если вы не прошли обучение по ним. Большинство общих SysAdmins НЕ имеют такого рода обучения.
  • Если доказательства сохраняются, рассматривайте потерю обслуживания как аварию с потерей оборудования и начинайте процедуры восстановления с новым оборудованием.
• Заранее установленные правила для того, какие виды бедствий требуют каких уведомлений. Законы и правила варьируются в зависимости от местности.
  • Правила, касающиеся «разоблачения» и «доказанного компромисса», различаются.
  • Правила уведомления потребуют участия отдела связи.
  • Если требуемое уведомление достаточно велико, должно быть задействовано руководство высшего уровня.
• Используя данные DR, определите, сколько времени «WTF только что произошло» может быть потрачено, прежде чем возвращение услуги в оперативный режим станет более высоким приоритетом.
  • Время восстановления сервиса может потребовать работы по выяснению того, что произошло в подчинении. Если это так, то возьмите образ диска поврежденного устройства для вскрытия после восстановления служб (это не доказательная копия, а технический специалист, который должен провести обратный инжиниринг).
  • Запланируйте свои задачи по восстановлению службы, чтобы включить полную перестройку уязвимой системы, а не только очистку системы.
  • В некоторых случаях время восстановления службы достаточно ограничено, поэтому образы дисков должны быть сняты сразу же после выявления компрометации, и правовые доказательства не должны храниться. Как только сервис перестроен, может начаться работа по выяснению того, что произошло.
• Просматривайте файлы журналов для получения информации о том, как злоумышленник вошел и что они могли сделать однажды.
• Просматривайте измененные файлы для получения информации о том, как они вошли, и что они сделали, когда они вошли.
• Просматривайте журналы брандмауэра для получения информации о том, откуда они пришли, куда они могли отправлять данные и сколько их могло быть отправлено.

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

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

Как правильные процедуры службы поддержки могут помочь

Здесь мы должны рассмотреть, как обращаться с клиентами (это касается как внутренних, так и внешних клиентов, обращающихся в службу поддержки).

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

На этом этапе служба поддержки и управление ИТ-отделом должны выступать в роли «зонтика», укрывая людей, выполняющих работу, для определения степени вторжения и восстановления сервисов из бесчисленных запросов, которые нарушают эту работу.

1. Попробуйте публиковать реалистичные обновления для клиентов и работайте с ними, чтобы определить срочность возобновления работы сервиса. Важно осознавать потребности клиентов, но в то же время не позволяйте им диктовать вам нерабочий график.
2. Убедитесь, что ваша группа поддержки знает, какая информация может и не может быть раскрыта, и что она не должна поощрять слухи и спекуляции (и абсолютно не должна обсуждать что-либо, что может нанести ущерб любым юридическим действиям, которые ваша организация может предпринять или столкнуться).
3. Одна положительная вещь, которую должна сделать служба поддержки, - это запись всех вызовов, относящихся к вторжению - это может помочь измерить нарушение, вызванное как самим вторжением, так и процессами, которые последовали за его устранением. Вложение как временных, так и финансовых затрат на вторжение и смягчение последствий может быть очень полезным как для уточнения будущих стратегий, так и, очевидно, может оказаться полезным при любых юридических действиях. Здесь могут помочь записи об инцидентах и ​​проблемах ITIL - и само вторжение, и смягчение могут быть записаны как отдельные проблемы, и каждый вызывающий абонент отслеживается как инцидент одной или обеих проблем.

Как стандарты развертывания могут помочь

Развертывание в заданном шаблоне (или, по крайней мере, в контрольном списке) также помогает, наряду с практикой контроля / управления изменениями в любых настройках / обновлениях шаблона развертывания. Вы можете иметь несколько шаблонов для учета серверов, выполняющих различные задания (например, шаблон почтового сервера, шаблон веб-сервера и т. Д.).

Шаблон должен работать как для ОС, так и для приложений, и включать в себя не только безопасность, но и все используемые вами настройки, и в идеале должен быть написан по сценарию (например, шаблон), а не применен вручную (например, контрольный список), чтобы максимально устранить человеческую ошибку.

Это помогает несколькими способами:

• Позволяет быстрее восстанавливать / восстанавливать в случае вторжения (обратите внимание, что не следует развертывать из этого шаблона «как есть», поскольку вы знаете, что он уязвим, но он позволяет вам вернуться к «последней известной исправной конфигурации»). " который должен подвергнуться дальнейшему усилению перед развертыванием в режиме реального времени ... и не забудьте обновить шаблон развертывания, если вы уверены, что он также правильно заблокирован)
• Дает вам «базовый уровень» для сравнения взломанного сервера с
• Уменьшает ненужные ошибки, которые могут привести к вторжению в первую очередь
• Помогает с управлением изменениями и исправлениями, потому что, когда становится очевидно, что для безопасности требуется исправление / обновление или процедурное изменение (или любые другие причины в этом отношении), становится проще увидеть, какие системы нуждаются в изменении, легче писать тесты. чтобы увидеть, правильно ли применены изменения и т. д.).
• Если все настолько непротиворечиво, насколько это возможно и разумно, это помогает заставить необычные и подозрительные события продвигаться дальше.

Для большинства наших серверов в большинстве случаев мы используем хост-компьютеры и сетевые брандмауэры, антивирусное и шпионское ПО, сетевые IDS и ID хоста. Это наряду со всеми общими рекомендациями, такими как минимальные права доступа, удаленные несущественные программы, обновления и т. Д. Оттуда мы используем такие продукты, как Nagios, Cacti и решение SIEM для различного базового уровня и уведомлений о том, когда происходят события. Наш HIDS (OSSEC) также делает много записей типа SIEM, что приятно. В основном мы стараемся максимально блокировать вещи, но затем ведем централизованный журнал, чтобы в случае чего мы могли проанализировать и сопоставить это.

То, что вы действительно хотите, может быть разделено на 3 основных области:

1. Стандартная конфигурация системы
2. Мониторинг системы / приложений
3. Реакция на инцидент

Если у вас есть информация (обеспечение | безопасность) сотрудников, то вам обязательно нужно поговорить с ними. Хотя реагирование на инциденты часто является единственной компетенцией указанного офиса, остальное должно быть совместным усилием по разработке для всех затронутых сторон.

В ответ на риск, связанный с самоутверждением, этот ответ на связанный вопрос должен проиндексировать множество полезных для вас ресурсов: Советы по защите сервера LAMP.

В идеале у вас должно быть наименьшее количество поддерживаемых ОС, и вы должны собрать каждую из них, используя базовый образ. Вы должны отклоняться от базы только настолько, насколько это необходимо для предоставления любых услуг, которые предоставляет сервер. Отклонения должны быть задокументированы или могут потребоваться, если вы должны соответствовать PCI / HIPAA / и т. Д. или другие соответствия. Использование систем управления развертыванием и конфигурацией может очень помочь в этом отношении. Специфика будет во многом зависеть от вашей ОС, сапожника / puppet / Altiris / DeployStudio / SCCM и т. Д.

Вы должны определенно выполнять какую-то регулярную проверку журнала. Учитывая этот вариант, SIEM может быть очень полезным, но у него также есть недостаток: он дорогой как по цене покупки, так и по затратам на строительство. Ознакомьтесь с этим вопросом на сайте IT Security SE, чтобы получить некоторые комментарии по анализу журналов: как вы справляетесь с анализом журналов? Если это все еще слишком тяжело, даже общие инструменты, такие как LogWatch, могут предоставить хороший контекст для того, что происходит. Важная часть, тем не менее, просто не торопится, чтобы посмотреть журналы вообще. Это поможет вам узнать, что представляет собой нормальное поведение, чтобы вы могли распознать ненормальное.

В дополнение к просмотру журналов также важен мониторинг состояния сервера. Знание того, когда происходят изменения, запланированные или нет, имеет решающее значение. Использование локального инструмента мониторинга, такого как Tripwire, может предупредить администратора об изменениях. К сожалению, так же, как SIEMs и IDS, есть и обратная сторона: они дорогие в настройке и / или покупке. Более того, без хорошей настройки ваши пороги оповещения будут настолько высоки, что любые хорошие сообщения будут потеряны в шуме и станут бесполезными.

Надлежащая политика безопасности информации и управления событиями (SIEM) значительно облегчит вашу жизнь в сфере безопасности.

Я не эксперт по безопасности, поэтому я в основном подчиняюсь им; но начинание с принципала наименьших привилегий почти всегда значительно облегчает их работу. Применение этого метода, как целебного мазка, хорошо работает для многих аспектов безопасности: права доступа к файлам, пользователи времени выполнения, правила брандмауэра и т. Д. KISS также никогда не причиняет вреда.

Большинство упомянутых здесь решений применимы на уровне хоста и сети, но мы часто забываем о небезопасных веб-приложениях. Веб-приложения являются наиболее часто просматриваемой дырой в безопасности. С помощью веб-приложения злоумышленник может получить доступ к вашей базе данных или хосту. Никакой брандмауэр, IDS, брандмауэр не может защитить вас от них. OWASP ведет список 10 самых критических уязвимостей и предлагает исправления для них.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide