Архив

Архив раздела ‘Администрирование’

Меры первой помощи при защите от систем распределённых атак

13 Апрель 2009 Нет комментариев

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

1) Не поддавайтесь панике. Прошлые атаки как правило были направлены на создание панической обстановке в связи с типом целей, на которые они были направлены. Очень важно понять, что только довольно малый список компаний и серверов должны всерьёз вопринимать возможность distributed DoS. В этот список входят популярные сайты, включающие развитые популярные поисковые машины, центры e-Commerce, крупные и популярные IRC-сервера или же новостные ленты. Иначе говоря, если Ваша любимая страница не имеет бболее 10000 посещений в день или же тысячного дневного оборота в случае, если это электронный магазин, Вам можно беспокоиться в меньшей степени.

2) Скоординируйте действия с Вашим Internet-провайдером. Очень важно, чтобы вы имели связь и поддержку со стороны тех, кто предоставляет Вам услуги хостинга. Общая пропускная спокобность каналов, задействованных в распределённой атаке так велика, то Ваша подсеть скорее всего не сможет выдержать нагрузки. Обязательно выясните у Вашего ISP, могут ли они примениьт род контроля, который ограничит суммарный объём входящего к Вам траффика, ссмогут ли они бороться уже на своих роутерах с огромным числом пакетов, имеющих поддельный (spoofed) обратный адрес. В идеальной ситуации, Ваш ISP должен предоставить Вам статистикуу или же дать доступ к роутерам в случае надвигающейся атаки.

3) Оптимизируйте структуру роутинга в вашей сети. Если у вас не один хост, но большая сеть, вам лучше произвести необходимую настройку роутеров чтобы минимизировать последствия DoS-атаки. Чтобы предотвратить SYN-флуд, обеспечьте надлежащую настройку Вашего файлвола (довольно подробную документацию самой компании СISCO, посвящённую этому вы можете так же прочитать на VOID.RU. Обеспечьте фильтрацию, к примеру, UDP, IGMP, ICMP-траффика (то есть тех протоколов, которые не являются необходимыми для нормального функционирования Вашей сети). Запретите ИСходящий ICMP-unreach траффик (таким траффиком Ваши хосты будут отвечать на ICMP-флуд).
Читать далее…

Cоздание отказоустойчивого кластера для биллинговой системы UTM5 на базе FreeBSD

Оригинал: http://www.ctpahhuk.ru/content/view/45/52/

В статье рассматривается создание отказоустойчивого кластера для работы с биллинговой системой NetUP UTM на базе двух физических серверов. В качестве операционной системы используется FreeBSD. База данных mysql. Создание отказоустойчивого кластера для биллинговой системы на базе Gentoo Linux подробно рассматривается в соответствующей статье на сайте компании NetUP. [1]
utm5_cluster

Рисунок 1. Схема кластера.

Поскольку у меня объем трафика довольно большой, для избежания потерь данных о трафике, NetFlow поток передается и принимается в отдельной подсети и выделенных под это отдельных физических интерфейсах. Физические интерфейсы em0,em1 и em2 имеют общие IP-адреса по которым доступен кластер. В случае выходя из строя сервера, либо проблем на любом из этих трех интерфейсах, резервный сервер забирает на себя функции мастера и соответствующие IP-адреса назначаются его интерфейсам.

Данная система построена на базе протокола CARP (Common Address Redundancy Protocol — протокол избыточности общего адреса)[2]

Читать далее…

Борьба с битом DF и черными дырами или как фрагментировать нефрагментируемое.

Оригинал: http://dormestmass.blogspot.com/2007/08/df.html

В заголовке IP пакета имеется один интересный флаг -»don’t
fragment» или сокращенно DF. Назначение сего флага — запретить
разбивку пакета на фрагменты. Честно говоря, ситуации, когда
встречаются пакеты с этим флагом довольно редки, но они таки бывают и
могут надолго испортить настроение администратору/пользователю вот по
какой причине.

Различные технологии канального уровня предусматривают различный
размер MTU. И вполне естественно, что на пути следования трафика между
сервером и клиентом могут попадатся сегменты с разными размерами MTU.

На схеме ниже показана ситуация, когда клиент подключен к сети через
GRE-туннель, у которого размер MTU на 24 байта меньше, чем у
исходящего реального интерфейса. Клиент хочет произвести некий
обмен трафиком с удаленным сервером, а вот сервер выставляет этот
самый флаг на свои исходящие пакеты.
df_packet_fragment
Происходит следующая ситуация. Во время установки TCP-сессии клиент и
сервер анонсируют свои максимальные размеры сегментов (maximum segment
size или MSS), показывая друг другу какие максимальные TCP сегменты
они могут принимать. После получения опций MSS устройства вычисляют
максимальный размер сегмента, который будет посылатся удаленной
стороне (Send Max Segment Size или SMSS). SMSS будет равен размеру
меньшего MSS. Процедура установки TCP MSS описана в RFC 879.
Читать далее…

Выявляем по какой причине произошел сбой в маршрутизаторе CISCO(Identifying Bus Error Crashes)

Ошибки доступа к памяти вызывающие нестабильную работу маршрутизаторов и зачастую приводят к самопроизвольным перезагрузкам роутера. Зачастую ошибки происходят, когда процессор пытается получить доступ к области памяти, которой не существует(программные ошибки — обычно вызваны из-за багов прошивки IOS) или области физической памяти не отвечающие корректно на запросы процессора(аппаратные ошибки) Ошибки шины данных(bus error), могут быть идентифицированы выводом команды show version и show technical−support. Важно чтобы после возникновения ошибки роутер не был перезгружен по питанию или командой reload.

При выполнении команды # show version

Router uptime is 2 days, 21 hours, 30 minutes
System restarted by bus error at PC 0x30EE546, address 0xBB4C4
System image file is «flash:igs−j−l.111−24.bin», booted via flash
………
Мы увидим в какой области памяти была зафиксирована ошибка.
Читать далее…

Модуль ng_netflow и графическая структура трафика на Netflow Analyzer 4

Оригинал: http://it-expert.com.ua/weblog/message/406/

Что же представляет собой netgraph?

Если в двух словах, то netgraph это как высокоуровневый Basic для
сетевых сервисов по сравнению с машинным кодом. Идеология netgraph
позволяет путем создания визуальных графов из «кубиков» протоколов,
портов и сервисов как бы строить взаимодействие сетевых компонентов
простым созданием связей между «кубиками». Читать далее…

Тюнинг TCP стека в Linux

Увеличиваем максимальный размер памяти отводимой для TCP буферов:
(16Мб на порядок больше, чем нужно, следует экспериментальным путем подобрать
оптимальные значения, понеменогу увеличивая параметры заданные по умолчанию)

sysctl -w net.core.rmem_max = 16777216
sysctl -w net.core.wmem_max = 16777216

Увеличиваем лимиты автотюнинга (min, default, max bytes)

sysctl -w net.ipv4.tcp_rmem = «4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem = «4096 65536 16777216″

Увеличиваем размер очереди пакетов на сетевом интерфейсе, особенно полезно для Gigabit Ethernet:

ifconfig eth0 txqueuelen 1000

Особенности Linux ядра 2.4.x:
Для предотвращения особенности при уменьшении размера окна, из-за повторов передеачи пакетов,
для одного соединения, уменьшать на 10 минут размер окна для всех остальных соединений к тому же хосту:

sysctl -w net.ipv4.route.flush=1

Особенности Linux ядра 2.6.x:

Запрещаем кеширование статуса ssthresh (были ретрансмиты) для других соединений

sysctl -w net.ipv4.tcp_no_metrics_save = 1

Рекомендуется увеличить размер backlog до 1000 или выше
(для 10Gb линка можно поставить 30000):

sysctl -w net.core.netdev_max_backlog = 2500

Начиная с ядра 2.6.13 можно менять алгоритм обработки ситуации перегрузки:

sysctl -w net.ipv4.tcp_congestion_control=htcp
reno: традиционный TCP
bic: BIC-TCP (для высокоскоростных сетей, быстрое восстановление после потери)
highspeed: HighSpeed TCP: Sally Floyd’s suggested algorithm
htcp: Hamilton TCP (для высокоскоростных сетей)
hybla: для спутниковых линков
scalable: Scalable TCP
vegas: TCP Vegas
westwood: для сетей с большой потерей пакетов
Когда стандартный reno не устраивает рекомендуется попробовать bic или htcp.

Значения параметров тюнинга подробно описаны в документе ip-sysctl.txt в комплекте ядра:

http://www-didc.lbl.gov/TCP-tuning/ip-sysctl-2.6.txt

Способы защиты от флуда и DDoS атак в FreeBSD

Черные дыры.

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
Это превращает машину в черную дыру при попытке подключиться к портам,
которые не слушают. Nmap по настоящему не любит это.

Защита очереди сокета от SYN атак.

Основной из самых популярных атак остается SYN флуд, при которой
очередь сокета атакуемого хоста переполняется некорректными попытками
соединений. Для защиты от таких атак некоторые из UNIX поддерживают
отдельные очереди для входящих запросов на соединение. Одна очередь
для полуоткрытых сокетов (SYN получен, SYN|ACK послан), другая очередь
для полностью открытых сокетов, ждущих вызова accept() от программы.
Эти две очереди должны быть увеличены, чтобы атаки малой и средней
интенсивности почти не влияли на стабильность и доступность сервера.
kern.ipc.somaxconn=1024

Редиректы (Перенаправления)

Атакующий может использовать IP redirect для изменения таблицы
марщрутизации на удаленном хосте. В хорошо разработанной сети
редиректы на конечные станции не должны требоваться. Оба — отправка и
принятие редиректов должны быть отключены.
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
Читать далее…

Описание некоторых sysctl переменных ядра Linux (sysctl proc linux kernel tune)

Оригинал: http://debian.telenet.ru/doc/sysctl.conf

> net.ipv4.conf.default.forwarding=1

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

> fs.file-max = 64000

Максимальное значение открытых файлов. Что бы его узнать, выполните
команду cat /proc/sys/fs/file-max

> net.ipv4.conf.all.rp_filter = 1

Эта переменная сообщает ядру о необходимости фильтрации пакетов по их исходящему адресу.

> kernel.sysrq = 0

Отключается комбинация клавиш sysrq, которая используется при крахе
системы.

> net.ipv4.conf.default.rp_filter=1

Фильтр обратного пути (когда пакет приходит с одного интерфейса, а
уходит на другой)

> net.ipv4.conf.all.accept_source_route = 0

Маршрутизация от источника (source routing) позволяет отправителю
определить путь, по которому пакет должен пройти по сети Internet, чтобы
достигнуть пункта назначения. Это очень удобно для изучения и отладки
работы сети, но нарушитель получает возможность подмены адресов
компьютеров локальной сети. 0 означает, что маршрутизация отключена, 1 -
наоборот.

> net.ipv4.tcp_syncookies=1

Разрешает/запрещает передачу так называемых syncookies вызывающему хосту
в случае переполнения очереди SYN-пакетов для заданного сокета. Когда в
систему поступает слишком много запросов на соединение, то очередь может
переполниться и тогда запускается передача syncookies в ответ на каждый
SYN-запрос. Эта переменная используется для предотвращения syn-flood
атак. Переменная может принимать два значения 0 (выключено) и 1
(включено). Значение по-умолчанию 0 (выключено). Эта функция будет
работать только в том случае, если ядро собрано с опцией
CONFIG_SYN_COOKIES.
Читать далее…

Оптимизация TCP/IP стэка для AIX, Solaris, Tru64, HP-UX, Irix, Linux и FreeBSD (eng)

UNIX IP Stack Tuning Guide v2.7

http://www.cymru.com/Documents/ip-stack-tuning.html

By Rob Thomas

Introduction

The purpose of this document is to strengthen the UNIX IP stack
against a variety of attack types prevalent on the Internet today.
This document details the settings recommended for UNIX servers
designed to provide network intensive services such as HTTP or routing
(firewall services). This document covers the following UNIX variants:

A. IBM AIX 4.3.X
B. Sun Solaris 7
C. Compaq Tru64 UNIX 5.X
D. HP HP-UX 11.0 (research ongoing)
E. Linux kernel 2.2 (tested both SuSE Linux 7.0 and RedHat 7.0)
F. FreeBSD
G. IRIX 6.5.10

  Читать далее…

Анализ трафика при помощи tcpdump

18 Март 2009 1 комментарий

Автор — Александр Лебедев aka slice (alunix@bk.ru)

Введение

Зачем нужно анализировать трафик? Знание того, как происходит взаимодействие между компьютерами позволяет более быстро обнаружить и решить возможные проблемы, возникшие в работе сети. Приведу простейший пример: один из компьютеров локальной сети перестает отвечать на запросы. Что могло произойти? Были ли он взломан или это ошибки системного администратора? Если в сети присутствует хорошая система управления логами, то можно много информации узнать из этих файлов. Но что если в них нет ничего подозрительного или, что еще хуже, они были скомпрометированы злоумышленником? Тогда на помощь приходит tcpdump. Эта программа, как скрытая камера, которая показывает, что происходит в данный момент в сети. Благодаря ей вы можете создать специальные фильтры, которые будут отображать только нужный вам трафик. Читать далее…