Каталог тематических статей
- Избранные статьи из русскоязычных и англоязычных конференций, анонсов
нового программного обеспечения и списков рассылки по компьютерной безопасности.
Статьи объединены в разделы в зависимости от тематики. Существует три вида
представления статей: разбивка
на страницы по 30 статей на страницу + сортировка по дате, разбивка на
страницы по 30 статей на страницу + cсортировка по имени, все статьи на
одной странице + сортировка по имени.
Архив документации
- Документация на русском и английском языках. Книги, HOWTO, FAQ, руководства, etc. В раздел документации помещаются статьи содержащие графические изображения или имеющие более одной страницы, в противном случае, статья размещается в тематическом каталоге.
MAN Системные руководства
- Интерактивная система просмотра системных руководств (man'ов) на русском и английском
языках (man'ы от linux, freebsd, solaris).
Советы и заметки - небольшие практические советы,
примеры из практики, вещи которые нелишне всегда иметь под рукой, то что не
особо хочется запоминать до автоматизма.
МИНИ-ПОРТАЛЫ - тематические индексные страницы,
набор информационных блоков, охватывающих выборку материалов и заголовков
подразделов строго определенной тематики, собранных со всех разделов сайта в
одно место. Если раньше разделы сайта были обособлены и имели каждый свой рубрикатор,
то чуть позже через систему ключевых слов была предпринята попытка объединения материалов разделов,
а теперь плюс к этому реализована система мини-порталов, обеспечивающая
общий скелет разделов представленных на сайте.
Ключи задаются в виде списка терминов желаемой тематики, на английском языке.
Список возможных ключей приведен на странице "Дерево ключевых слов" в трех возможных представлениях:
Дерево с оглавлением - дерево более узкое, но присутствует оглавление с перечнем разделов.
Широкое дерево - более компактное представление дерева.
Алфавитный список - список по алфавиту.
В дереве при клике на ^ рядом с именем раздела - переход к вершине дерева, клик на число в скобках (число статей в тематическом каталоге для данного ключа) - копирование текущего ключа в строку запроса
Указывая ключи "на глаз" имейте в виду, что для всех существующих в дереве ключей, дополнительно присутствует список синонимов.
При повторении в запросе одного ключа N раз, вес этого ключа при поиске возрастает в N-раз.
Тип запроса указанный через поля "Тип" и "Тема" имеет в двое меньший вес, чем у ключей приведенных в строке запроса.
Старайтесь в запросе указывать как можно больше ключевых слов имеющих отношение к искомой теме, наиболее близкие ключи дублируйте.
Карта сервера в графическом представлении (устарела).
Развернутый индекс - полное оглавление каталогов на одной странице (устарел).
Взаимодействие с посетителями
Виртуальная конференция
- Раздел предназначен для обсуждения любых тем, связанных с UNIX'ом. Задавайте
и отвечайте на вопросы, делитесь новостями и т.д.
Был раздел "Персональные настройки", где можно было самостоятельно определить
видимые на индексных и новостных страницах блоки, но текущая политика сайта - разумный дефолт,
максимальная простота, никаких лишних усложнений.
Книга отзывов и предложений
- Страница предназначена для внесения комментариев, предложений, пожеланий,
новых URL и т.д.
Стараюсь не помещать пустых и бессодержательных новостей. Как правило, в
OpenNews проходят обзоры новых статей , программ, патчей, особых событий.
Размещаются анонсы статей, вышедших на русском или английском языках.
Еженедельно просматривается около сотни сайтов, действует специальная
автоматизированная система отбора нового материала. При выборе, к статьям
на русском языке отношение более либеральное, анонсы статей на английском -
как правило только самое интересное)
Раз в несколько недель выходит блок "Статьи за неделю не попавшие в ленту новостей",
представляющий собой краткий обзор статей заслуживающих упоминания,
но по каким либо-причинам не удостоенным отдельного анонса;
Новости выходят в расчете на аудиторию от начинающих пользователей, до профессионалов и гуру.
Лаконичный стиль изложения новостей, задача поместить как можно больше
информации в как можно меньшем объеме текста. В двух словах: резюмирование, отсутствие лишних слов,
борьба с употреблением жаргона и просторечий, пропаганда научного, трезвого подхода и
неприемлемость неаргументиованных высказываний, дилетантства и невежества.
Свежий софт - Последние версии
наиболее интересных программ, заполняется как вручную, так и по результатам работы автоматической
системы определения последних версий программ.
Проблемы безопасности - Наиболее
опасные ошибки в ОС FreeBSD, OpenBSD, NetBSD и Linux. Обновляется ежедневно.
Сводная страница новостей с других сайтов.
Последние новости с более, чем 80 русскоязычных и англоязычных сайтов, отображение как
в смешанной ленте новостей (по дате поступления и тематике), так и архив новостей по
каждому новостному сайту.
Общий список новостей за день.
Просмотр новостей со всех сайтах за выбранный день, все на одной странице с
разбивкой по сайтам.
Общая сводка новостей проекта
На странице в одном месте собрано все новое появившееся последнее время на сайте:
новые записи в каталогах, новые документы, заметки, анонсы и т.д.
RSS каналы - почти все новостные потоки сайта доступны в виде RSS.
На RSS с сообщениями отдельных нитей можно подписаться на странице с полным раскрытием нити (режим "смотреть все").
RSS новостей привязанных к мини-порталам доступны на стрнаницах мини-порталов.
Управление проектом
ЦУП - Центр Управления Проектом
OpenNET (планы на будущее, последние реализованные вещи, состояние БД, даты обновления и т.д.)
Добавление записей в каталоги - Служит для организации пользовательского интерфейса по
управлению информацией хранимой на SQL сервере (добавление новой ссылки
или новой программ).
Проект разработан и поддерживается Максимом Юрьевичем Чирковым.
Задачи: структурирование и типизация как хобби и область реализации идей, популяризация открытых технологий.
Проект постоянно развивается,
сегодняшний opennet всегда лучше вчерашнего, завтрашний будет лучше сегодняшнего.
Реклама на сайте является стимулом для
рождения и воплощения новых идей. После каждого размещения рекламы создается что-то новое или
переделывается старое. Я не ставлю перед собой задачи получения какой-либо
коммерческой выгоды, но не исключаю появление рекламы, как индикатора,
что делаешь что-то полезное, двигаешься в правильном направлении, получаешь подтверждение, что следует идти вперед и вперед, к новым горизонтам,
к воплощению новых идей и старых планов.
В настоящее время практикуется система распределения получаемых от рекламы средств между авторами новостей.
Для организации системы грантов авторам открытых программ и документации, нужны средства
другого порядка (не CD-ROM'ы же с дистрибутивами и книжки вручать),
чем деньги получаемые вследствие рекламы на OpenNet.
Человеческие факторы лежащие в основе развития OpenNet:
Работоспособность. Хоть маленькими шагами, но двигаться и двигаться, невозможно все
сделать сразу, но останавливаться нельзя.
Планирование и проектирование, организация работы, избавление от рутины.
Четкое формулирование планов, перед началом реализации, идея должна полностью созреть и оформиться.
Энтузиазм. Первостепенный стимул - интерес, любознательность, увлеченность, целеустремленность.
Настоящий интерес, не подгоняемый стремлением к наживе, тщеславию или каким-то выгодам, интерес
ради интереса, интерес ради познания.
Что осуждается:
Невежество. Как писал Гёте: "Нет ничего страшнее деятельного невежества".
Условные обозначения:
[+] - Ссылка на страницу с исчерпывающей
информацией о ресурсе, имеющейся в базе данных
[отзыв] - Ссылка на страницу где можно оставить свое мнение о данном элементе каталога, если написано "есть мнение" - значит в базе уже есть мнения по данной записи и их можно просмотреть или обсудить
БД для быстрого постоянного хранения данных: MemcacheDB
FTP-сервер: vsftpd
MTA: Postfix
Поиск на сайте
используется htdig - для объема индексируемого материала примерно 1.5 Гб htdig пока остается оптимальной системой (с хранением индексов в btree Berkeley DB файлах), главные минусы - нет предкеширования типовых запросов (можно реализовать внешним wrapper'ом или через mod_accel), не оптимальная работа при выводе результата поиска по часто встречающемуся в индексируемых документах словам (например, если ищем по слову которое встречается десятки тыс. раз - поиск будет занимать несколько минут).
OpenFTS - слишком медленный и ресурсоемкий конечный поиск для клиента, не хочется создавать лишнюю нагрузку на PostgreSQL сервер, который обслуживает первичные БД сайта.
Aspseek и mnogosearch - требуют слишком много памяти для расчета коэффициентов релевантности (не меньше 1 Гб ОЗУ), требуют MySQL для обеспечения более или менее высокой скорости операций поиска (не хочется поднимать MySQL на сервере).
Бэкап: fsbackup
Мониторинг: alertmon3
Заметки по технологии и оптимизации
Все что можно - преобразовывать в статику. Предгенерация контента.
Когда предгенерация не подходит - кэшируем динамику "на лету". Первый
уровень - самые популярные и часто обновляемые блоки кешиурем в
памяти (memcached). Второй уровень - редко запрашиваемые блоки кэшируем на диск.
Кэшируем на уровне приложений. Чистим запись в кэше в момент изменения данных связанных с
прокэшированными данными.
Буферизируем вывод apache через nginx. На уровне nginx реализуем базовые
"url rewrite" правила, сжатие контента, перекодировку, средства борьбы с флудом,
ограничения числа одновременных потоков. Возможна организация целостного кэширвоания страниц, через
связку nginx+memcached с предварительным формированием кэша на
уровне приложений.
Периодически парсим лог и выявляем пики дублирующих друг друга
запросов к динамике (например, флуд через один и тот же сложный
запрос к поисковой подсистеме), автоматически кэшируем результат
таких запросов в статику и, пока не прекратится флуд, перенаправляем в
статику. Также выявляем аномально больше число запросов динамики с одного IP,
если при этом превышен допустимый Load Average, временно блокируем IP.
Со временем убедился, что персональные настройки на сайте - лишнее усложнение,
почти всегда достаточно разумного дефолта. Стремлюсь к простоте в оформлении и лаконизму в изложении.
В динамике - поиск (возможно кэширование индексов популярных
ключей через memcached), динамическая часть форума (возможно
кэширование последних БД файлов, сессий и индексов в memcached.
Перевод списочных страниц в статику, путем выставления new и флагов
привязанных к пользователю через JavaScript), контент который не
выгодно хранить или отдавать в статике:
когда контент слишком часто изменяется;
когда необходимо обеспечить большую гибкость запроса;
когда объем контента в статике слишком велик;
когда запрашивается только "верхушка айсберга" (например - вывод текста новостей, интенсивно запрашиваются только последние новости, которые и можно предкэшировать "на лету", но не предгенерировать);
когда предгенерация требует значительных ресурсов, несопоставимых с ресурсами затрачиваемыми при отдаче того-же динамикой (например, когда много вариантов представления - выгоднее предкэшировать отдельные блоки, а не всю страницу сразу).
Все что нельзя превратить в статику (предгенерировать) - кэшировать через статику. Предкэширование типовых запросов и промежуточное сохранение часто используемых выборок в кэше. Например, можно прокэшировать только наиболее часто встречающиеся запросы.
Ту динамику, что невозможно прокэшировать - снабжать средствами защиты от перегрузок.
защитой от DoS/flood потоков запросов;
ограничить число одновременных потоков на клиента;
ограничить число запросов на клиента в ед. времени (средства ipfw, mod_limitconn или mod_throttle);
квоты на дисковое пространство (не переусердствовать, отделить первичные области диска (например, хранилище БД, данные форума - не восстановимы), от вторичных (например, предгенирированный контент, кэши - влияют на отображение, но восстановимы из первичных областей) и третичных (например, логи - потеря не так страшна));
квоты на процессорное время
квоты на размер процесса;
квоты на число процессов;
Практические рекомендации по тюнингу Apache:
FreeBSD ядро собираем с "options ACCEPT_FILTER_HTTP" (или "kldload accf_http"),
в конфигурацию Apache добавляем "AcceptFilter on", перезапускаем Apache;
Убираем лишние модули;
"KeepAlive Off", а картинки отдаем через отдельный мини-http сервер для отдачи статики (mathopd, thttpd, Nginx, lighttpd);
В "Options" должно быть "FollowSymLinks", но не нужно "SymLinksIfOwnerMatch" (приводит к лишней lstat() проверке при каждой отдаче файла).
Не используем .htaccess (AllowOverride None), все настройки, включая авторизацию, в httpd.conf (apache тратит ресурсы на попытки открыть .htaccess в каждой родительской директории);
Ограничиваем число одновременных запросов с одного IP через "ipfw add allow tcp from any to $IP 80 via fxp0 setup limit src-addr 15" или "iptables -A INPUT-p tcp --dport 80 -m iplimit --iplimit-above 10 -j REJECT", но не через модули apache (mod_throttle, mod_bandwidth, mod_limitconn);
Использовать FastCGI/mod_perl для динамики (устраивает использование FastCGI). Наиболее выгодно использовать для небольших скриптов, время загрузки и парсинга которых сравнимо с временем выполнения скрипта, либо если промежуточные данные можно держать в памяти (пример, скрипт "хинтов" в opennet). Выгода почти не ощутима для тяжелых скриптов, требующих значительного времени для выполнения и не использующих одни и те же области данных (например - скрипты поиска).
Использовать mod_accel - для буферизации клиентских запросов и создания внешнего кэша запросов к динамике. Увеличение sendbuffer в apache и send/recv буферов на уровне ОС. Написание скриптов с учетов кэширования. (в opennet mod_accel не используется)
Использовать mod_deflate для сжатия отдаваемого пользователям контента (трафика меньше и клиенту быстрее информация отдается, нагрузка на CPU от сжатия - почти незаметна);
Если статики очень много (например отдаются картинки) - не тратим на нее силы apache, а отдаем через nginx. Окажет помощь балансировка данных на несколько дисков, особенно если на сервере используются SCSI накопители. Или выдача статики прямо из memcached или ram-диска.
Надежность
Для обеспечения надежности системы важными составляющими являются системы
мониторинга и резервного копирования.
Мониторинг.
Слежение за возникновением проблем
Попытки автономно решить проблему
Оперативное сообщение о возникновении проблемы.
Сохранение информации о факте проблемы и дампа состояния системы в момент проблемы.
Визуализация текущего состояния.
Визуализация динамики изменения состояния (наглядное представление на графиках):
Мониторинг инфраструктуры (группы серверов и оборудования)
Карта сети, в которой отображено состояние точек и связей
Удаленный мониторинг
Достижимость ресурса
Работоспособность сервисов ресурса
Локальный мониторинг
Контроль наличия запущенных процессов
Контроль за состоянием процессов (число процессов, расход ресурсов CPU, ОЗУ)
Контроль за состоянием сетевых соединений (определение флуда)
Контроль расхода дискового пространства.
Периодическая оценка логов на предмет наличия фатальных или предупреждающих сообщений.
Контроль общего состояния системы, нагрузки, расхода памяти, сетевого трафика и т.д.
Резервное копирование.
Территориальный вынос бэкапа (пожар, форс-мажор)
Инкрементальное накопление изменений
Несколько уровней отката.
Несколько уровней детализации и полноты бэкапа.
Безопасность и конфиденциальность бэкапа (бэкап с важными данными должен быть зашифрован)
Экономия дискового пространства за счет сжатия бэкапа.
Легкость восстановления без необходимости доп. ПО, кроме архива бэкапа (открытый формат архива)
Автономность, автоматическая работа без участия оператора
Гибкость формирования бэкапа (маски файлов/директорий для помещения в бэкап и исключения из него)
Схема и планирование бэкапа.
На критичные к времени простоя или содержащие ценные данные сервера,
ставим RAID. Обязательно, hi-end SCSI диски,
хороший SCSI RAID контроллер (сейчас используем LSI Logic SCSI 320-2 MegaRAID, RAID5 + hot-spare).
Не стоит экономить при выборе контроллера, лучше без RAID, чем чувство ложной
безопасности). Наличие BBU (аккумулятор для сохранения содержимого кеша в течении нескольких суток) крайне желательно, иначе при пропадании питания вероятен серьезный сбой (ОС считает что данные записались, а реально нет). Крайне рекомендуется иметь запасной hot-spare диск для автоматической горячей замены.
Восстановление после сбоя производится автоматически (время простоя нулевое).
Если бюджет не позволяет установить хороший RAID контроллер,
следует добавить на сервер IDE диск большого размера и еженощно
зеркалировать туда всю информацию.
Рекомендуется, использовать двойное зеркало, каждое из которых обновляется
через день. Подобная перестраховка необходима для предотвращения потери данных
в ситуации краха во время бэкапа и защиты от синхронизации в бэкап не фатальных
повреждений ФС ведущих к пропаданию файлов (сбой, fsck, случайное удаление)
или их обнулению (следствие переполнения раздела).
Для восстановления необходимо загрузить систему с бэкап диска (несколько минут)
Ежедневное инкрементальное резервное копирование уникальных для данного хоста данных и файлов конфигурации на
территориально удаленный бэкап сервер (например, используя fsbackup).
Для восстановления следует установить операционную систему и восстановить конфигурацию и данные из бэкапа (простой - несколько часов).
Обязательным звеном бэкапа является проведение эксперимента по
восстановлению системы. В ходе такого эксперимента всплывают
не помещенные в бэкап важные файлы, отсутствие сведений о
конфигурации системы (например, параметры дисковых разделов).
Кроме того, благодаря четкому представлению шагов и уверенности
в действиях, увеличивается скорость восстановления после
реального сбоя, уменьшается вероятность человеческой ошибки.
Дополнительные системы отказоустойчивости: разбалансировка на несколько серверов (самое простое - балансировка по DNS) или БД, использование RAID, системы бесперебойного питания, резервные сетевые линки, промежуточное оборудование повышенной надежности (маршрутизаторы, коммутаторы), размещение в спец. помещении (неприкосновенность оборудование, вентиляция, фильтрование пыли, температурный режим, защита от пожара и протечки систем водоснабжения).
Дополнительные системы увеличения производительности
Кэширование контента.
Кэширование SQL запросов.
Кэширование промежуточных данных
Кэширование результата.
Предкешированные объекты.
Использование оптимальных алгоритмов.
Оборудование - SCSI диски, машины с SMP.
Тюнинг ОС.
Разделение нагрузки на несколько серверов, вынос сервисов на отдельные машины.
Функциональное разделение (по IP) и равномерное разделение (SQL)
Субъективное разделение (разделение функций и операций, DNS-балансирование, IP-балансирование и т.д.)
Разделение процессов (кластер, 2 SQL сервера для балансировки SELECT запросов.)
Безопасность
Ежедневное слежение за отчетами с описанием новых проблем с безопасностью
в рассылках и на специализированных сайтах.
Не дожидаться обнаружения ошибок, попытаться предотвратить их
проявление. Всегда считать, что в программе есть ошибки,
обдумать что можно сделать чтобы система не пострадала от их
проявления. Система должна быть неприступна, невзирая на
вероятные проблемы с безопасностью в программах.
Избыточные, параноидальные проверки в своем коде.
Проверки на каждом этапе использования полученных от пользователя
или иного внешнего источника данных.
Понижение привилегий и запуск в chroot.
Использование библиотек-врапперов подменяющих потенциально опасные
библиотечные вызовы или сборка спец компиляторами с
средствами защиты от переполнения буфера.
Сниффинг. Особое внимание следует уделить внутренней безопасности,
для предотвращения появления злоумышленника в доверительной сети.
Сниффер в доверительной сети, не меньшая угроза, чем открытая
брешь в ПО. Средства защиты от злоумышленника в локальной сети:
Шифрование трафика, особенно актуально для сервисов в которых
присутствует передача паролей в открытом виде. Но, на одно шифрование
тоже нельзя полагаться, об этом ярко говорят ошибки в реализации ssh1,
openssl, mod_ssl приводящие к возможности анализа перехваченного шифрованного
трафика.
(Примеры, замены: http => SSL+http, ftp => sftp, telnet, ssh1 => ssh2,
pop3 => apop или pop over TLS/SSL).
Жесткая политика доступа к ресурсам управления (ssh, snmp).
Разграничение доступа внутренними средствами: ACL программы
или tcp wrapper (/etc/hosts.allow). Желательно, чтобы доступ
разграничивался как по имени пользователя совместно с ограничением
по IP (каким пользователям какие действия можно производить с каких IP).
Дублирующее ограничение средствами фаервола, можно как на локальном сервере,
так и на пограничном маршрутизаторе.
Мониторинг переполнения ARP таблиц. Использование коммутаторов (свичей),
не избавляет от возможности сниффинга. Проброс каждого клиента
используя VLAN через маршрутизатор или привязка MAC адреса к порту
коммутатора - дорогое удовольствие, особенно в больших сетях.
Частично проблему помогают решить программные средства слежения за
изменением MAC адресов (чтобы пользователи самовольно не меняли IP
адреса и не выставляли IP соседа) и мониторинга за переполнением
ARP таблиц. Другой способ борьбы с arp-спуффингом - использование специальных патчей на шлюзовой машине или жесткая привязка MAC адресов к IP.
Использование временных паролей
(One-Time Passwords - OTP, opie, s/key).
Например, генерируется список паролей и при каждом входе используется
следующий пароль из списка, использованные пароли блокируются.
Применение средств автоматического обнаружения вторжения (IDS)
под вопросом, так как в таких средствах часто находят критичные ошибки
способствующие взлому (пример: snort, tcpdump).
Закрытая система для решения спец. задач, без публичных сервисов (например, рутер, фаервол)
Полное отсутствие сетевых сервисов.
SSH доступ только с IP администратора и резервного trusted сервера.
Закрытые сервисы доступны только непосредственным потребителям.
Двойное или тройное блокирование, пакетный фильтр, libwrap/tcpwrapper и настройки самой программы.
Если система не в trusted сети - шифрование всех потоков данных.
Закрытая система с сетевыми сервисами.
SSH доступ только с IP администратора и резервного trusted сервера.
Открыты только реально необходимые сервисы.
Для открытых сервисов используется только доверительное ПО, в котором ранее не замечали проблем безопасности и прошедшее беглый аудит.
Все остальное, если невозможно обойтись без него или заменить в CHROOT.
Доверяю ПО: postfix, qmail, popa3d, vsftpd (практика прецедента - не доверять ПО
в котором хоть раз найдена критическая ошибка безопасности или
программа разработана без использования жесткой политики безопасности
(в документации и коде это сразу заметно)).
Запускаю в CHROOT: bind/named, apache, ftpd (BSD), inn. Доступ к OpenSSH
только с доверительных хостов.
Не запускаю в public никогда: все реализации IMAP, samba, sendmail, proftpd, wuftpd, mysql, postgresql, dhcpd, ntpd.
Пример особенно безграмотных с точки зрения безопасности систем - proftpd, qpop.
Не использовать антивирусы для проверки почты, как правило это
закрытые проекты в которых не проводится аудит исходного кода.
Вместо антивирусов, можно практиковать полную блокировку пересылки выполняемых файлов,
или отключить проверку в архивах и запускать в chroot.
Подобному решению способствуют прецеденты DoS атак (переполнение диска) через вложенные,
специально скомпонованные, сжатые файлы или возможность выполнения
кода на сервере через специальным образом скомпонованные заголовки
письма.
Открытая система с локальными пользователями (например пользователи могут запускать CGI-скрипты)
Разделение привилегий, запретить доступ к другим пользователям и системным файлам по возможности
Желательно noexec /tmp и патч для noexec stack.
Если можно то в chroot jail.
Не давать исходящих коннектов, если не требуют условия.
Убрать все suid программы которые можно убрать, использовать
TCB для хранения паролей, вместо /etc/shadow
Не оставлять бэкапы в открытом месте, иногда злоумышленник может
взломать систему используя старую suid программу из бэкапа или
обнаружив общедоступный файл с паролями.
Вести подробные логи, включая аккаунтинг выполняемых
процессов. syslog логи дублировать по сети на соседнюю
машину.
Применять программное обеспечения для слежения за
целостностью участков файловой системы и поиска root-китов.
Дополнительные ограничения для скриптов пользователей системы хостинга (apache в chroot):
Запрещение connect(2), невозможность установки исходящих соединений
пользовательскими скриптами (используя библиотеку враппер, подгружаемую через LD_PRELOAD в suexec, принудительно меняем для listen и connect IP на 127.0.0.1).
Запрещение listen(2), предотвращение приема соединений на сетевой порт. Борьба с процессами демонами, через мониторинг.
Ограничение возможности использования группы exec вызовов,
предусмотреть использование относительных путей и список
исключений (текущая cgi-bin, /bin и т.д.);
Запретить для cgi-скриптов возможность создания и перезаписи файлов
в директориях с исполняемыми скриптами (cgi-bin).
Квоты на дисковое пространство, время выполнения скрипта и объем используемой
одним скрптом памяти.
Права доступа к диреткории пользователя "drwx--x--- user hosting",
где user - id пользователя, hosting - группа из под которой запущен
apache (для раздачи статики). Таким образом скрипт пользователя не
имеет доступа к диреториям других пользователей.
Использование mod_php в режиме safe_mode (php_admin_flag safe_mode on),
запретить использование URL в open (php_admin_flag allow_url_fopen off),
ограничить обем ОЗУ (php_admin_value memory_limit 2M),
ограничить время выполнения (php_admin_value max_execution_time 10).
Мониторинг in/out трафика через mod_watch.
Раньше получал полные данные о трафике используя "per user ip accounting",
но он учитывал также mysql и прочий локальный трафик, после введения блокировки
на listen() и connect(), использование mod_watch вполне оправдано.
Предотвращение использование ftp аккаунта для файлового обмена, через
дополнительный мониторинг.
Аспекты безопасности при написании CGI-скриптов
Применение suexec и жесткое разграничение прав доступа
(пользователь не должен видеть системных файлов и логов,
не должен иметь возможность получить доступ к данным
другого пользователя)
Полностью исключить использование типовых бесплатных скриптов. Лучше
все писать самостоятельно, если написание затруднено - обязателен
полный аудит кода чужих скриптов.
Паранойя при написании кода - дублирующие проверки всех параметров
получаемых в диалоге скрипта с пользователем (как минимум проверка
валидности с выводом сообщения об ошибке на этапе инициализации
переменных с данными пользователя и жесткое вырезание недопустимых
символов (s/[^\w\d_\-.]//g) перед опасными функциями (open, system)),
обязательное экранирование переменных при использование в regex выражении
(/\Q$var\E/, иначе $var может содержать "?{код}").
Perl пишем на Perl: никаких `` и вызовов shell функций, скрипт
с perl -w и в strict режиме;
Перед написанием кода - обязательное планирование, перед
кодированием скрипт должен уже иметь четкую структуру.
После написание - отладка и crash тест.
Доступ к системе web-управления, только с "trusted" хостов,
желательно по HTTPS.
Защита обслуживаемой сети c пользователями.
Оборудование и рабочее место администратора не должны быть
подключены в рамках одной физической сети (см. выше пункт "сниффинг").
Желательно разделить сеть по отделам (директора и бухгалтерию подключить
отдельно).
Не допустить доступ к оборудованию посторонним (охрана, дети сотрудников).
Обязательная парольная аутентификация на каждой машине и жесткие
административные правила пользования сетью.
Машины сети снабдить IP адресами из интранет блока. Выход во вне
только через прокси или транслятор адресов. Фаерволом закрыть все
кроме необходимых сервисов.
Установка локального ПО для борьбы с вирусами, постоянное обновление
пользовательских систем (установка service pack) и программ для работы в сети (IE, Opera, The Bat, Outlook).
Повышение грамотности пользователей.
Мониторинг уязвимостей в локальной сети, средства сканирования
пользовательских машин на предмет известных уязвимостей.
Защита от DoS и DDoS.
Тюнинг системы и установка лимитов, недопускающих полного исчерпания
системных буферов и уход в своппинг, при исчерпании ОЗУ. Лимиты httpd и скриптов
должны быть всегда чуть ниже реальных возможностей системы.
На готове должен быть скрипт для составления черных
списков IP, на основе выявленной аномалии, присущей текущей
атаке (запрос одинаковой страницы; запрос только
контентообразующих страниц, без сопутствующих css, js и
картинок; аномально высокое число запросв с одного IP; невыполнение
javascript вставок; невосприятие cookie).
Списки IP адресов подключаем не через отдельные правила пакетного
фильтра, а через функциональность работы с таблицами
адресов. В особо тяжелых случаях можно блокировать на
вышестоящем маршрутизаторе блоки адресов, оставив только
адреса стран, составляющих костяк посетителей сайта.
Если бот не умеет парсить JavaScript, хорошо помогает
использование промежуточной javascript страницы минимального размера.
На все запросы отдаем сперва простейшую страницу (только скрипт с document.location='http://www.site.ru/real/page.html')
с редиректом на реальную страницу (определяем через rewrite и if в nginx).
Плюсы: страница отдается из кэша, без обращения к диску; страница минимизирует трафик, влазит
в 1 tcp пакет; если был запрос фиктивной страницы, но не было последующего запроса реальной,
можно помещать IP в список блокировки.
Расчет лимитов предусматривающих возможность удаленного
входа администратора при любой нагрузке. Например, каков бы
ни был лимит на число соединений, ограничение пропускной
способности сети и ограничение числа запросов через
пакетный фильтр, администратор всегда должен иметь
возможность удаленно попасть на машину. Для IP администратора делаем
отдельные разрешающие правила и выделяем небольшую гарантированную
полосу пропускания.
- Обычный ресурс на английском языке
- Ресурс заслуживающий особого внимания
- Обычный ресурс на русском языке
- Ссылка помещенная на коммерческой основе.
