######################################################################
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
#
# A "#" character in the very first column makes the rest of the line
# be ignored. Blank lines are ignored. Lines may be indented freely.
# A "\" character at the very end of the line indicates the next line
# should be treated as a continuation of the current one.
#
# The "pre-up", "up", "down" and "post-down" options are valid for all
# interfaces, and may be specified multiple times. All other options
# may only be specified once.
#
# See the interfaces(5) manpage for information on what options are
# available.
######################################################################
# We always want the loopback interface.
#
# auto lo
# iface lo inet loopback
# An example ethernet card setup: (broadcast and gateway are optional)
#
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# A more complicated ethernet setup, with a less common netmask, and a downright
# weird broadcast address: (the "up" lines are executed verbatim when the
# interface is brought up, the "down" lines when it's brought down)
#
# auto eth0
# iface eth0 inet static
# address 192.168.1.42
# network 192.168.1.0
# netmask 255.255.255.128
# broadcast 192.168.1.0
# up route add -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# up route add default gw 192.168.1.200
# down route del default gw 192.168.1.200
# down route del -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# A more complicated ethernet setup with a single ethernet card with
# two interfaces.
# Note: This happens to work since ifconfig handles it that way, not because
# ifup/down handles the ':' any differently.
# Warning: There is a known bug if you do this, since the state will not
# be properly defined if you try to 'ifdown eth0' when both interfaces
# are up. The ifconfig program will not remove eth0 but it will be
# removed from the interfaces state so you will see it up until you execute:
# 'ifdown eth0:1 ; ifup eth0; ifdown eth0'
# BTW, this is "bug" #193679 (it's not really a bug, it's more of a
# limitation)
#
# auto eth0 eth0:1
# iface eth0 inet static
# address 192.168.0.100
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# iface eth0:1 inet static
# address 192.168.0.200
# network 192.168.0.0
# netmask 255.255.255.0
# "pre-up" and "post-down" commands are also available. In addition, the
# exit status of these commands are checked, and if any fail, configuration
# (or deconfiguration) is aborted. So:
#
# auto eth0
# iface eth0 inet dhcp
# pre-up [ -f /etc/network/local-network-ok ]
#
# will allow you to only have eth0 brought up when the file
# /etc/network/local-network-ok exists.
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet. If their MAC addresses get swapped (because an
# updated kernel uses a different order when probing for network cards,
# say), then they don't get brought up at all.
#
# auto eth0 eth1
# iface eth0 inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66
# pre-up /usr/local/sbin/enable-masq
# iface eth1 inet dhcp
# pre-up /path/to/check-mac-address.sh eth1 AA:BB:CC:DD:EE:FF
# pre-up /usr/local/sbin/firewall
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet, identified by MAC address rather than interface
# name:
#
# auto eth0 eth1
# mapping eth0 eth1
# script /path/to/get-mac-address.sh
# map 11:22:33:44:55:66 lan
# map AA:BB:CC:DD:EE:FF internet
# iface lan inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /usr/local/sbin/enable-masq $IFACE
# iface internet inet dhcp
# pre-up /usr/local/sbin/firewall $IFACE
# A PCMCIA interface for a laptop that is used in different locations:
# (note the lack of an "auto" line for any of these)
#
# mapping eth0
# script /path/to/pcmcia-compat.sh
# map home,*,*,* home
# map work,*,*,00:11:22:33:44:55 work-wireless
# map work,*,*,01:12:23:34:45:50 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note, this won't work unless you specifically change the file
# /etc/pcmcia/network to look more like:
#
# if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi
# get_info $DEVICE
# case "$ACTION" in
# 'start')
# /sbin/ifup $DEVICE
# ;;
# 'stop')
# /sbin/ifdown $DEVICE
# ;;
# esac
# exit 0
# An alternate way of doing the same thing: (in this case identifying
# where the laptop is is done by configuring the interface as various
# options, and seeing if a computer that is known to be on each particular
# network will respond to pings. The various numbers here need to be chosen
# with a great deal of care.)
#
# mapping eth0
# script /path/to/ping-places.sh
# map 192.168.42.254/24 192.168.42.1 home
# map 10.15.43.254/24 10.15.43.1 work-wireless
# map 10.15.43.23/24 10.15.43.1 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note that the ping-places script requires the iproute package installed,
# and the same changes to /etc/pcmcia/network are required for this as for
# the previous example.
# Set up an interface to read all the traffic on the network. This
# configuration can be useful to setup Network Intrusion Detection
# sensors in 'stealth'-type configuration. This prevents the NIDS
# system to be a direct target in a hostile network since they have
# no IP address on the network. Notice, however, that there have been
# known bugs over time in sensors part of NIDS (for example see
# DSA-297 related to Snort) and remote buffer overflows might even be
# triggered by network packet processing.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up ip link set $IFACE promisc on
# down ip link set $IFACE promisc off
# down ifconfig $IFACE down
# Set up an interface which will not be allocated an IP address by
# ifupdown but will be configured through external programs. This
# can be useful to setup interfaces configured through other programs,
# like, for example, PPPOE scripts.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up /usr/local/bin/myconfigscript
# down ifconfig $IFACE down
Джерело: http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/
четвер, 4 червня 2009 р.
субота, 2 травня 2009 р.
Мониторинг сети с помощью tcpdump
Довольно часто встает проблема, когда ему нужно узнать как работает сеть. Или просто для учебных-исследовательских целей узнать как взаимодействуют между собой объекты сети. Для этих целей в UNIX-мире написано целая куча инструментов. В данном материале будет рассматриваться один из них: tcpdump.
Итак, tcpdump.
$ man tcpdump, нам гласит
Tcpdump выводит заголовки пакетов проходящих через сетевой интерфейс, которые совпадают с булевым выражением. Он может также быть запущен с ключем -w, который заставляет сохранять данные пактов в файл для дальнейшего исследования, и/или с ключем -r, который заставляет читать сохраненные пакеты из файла, вместо чтения пакетов из сетевого интерфейса. В любом случае, tcpdump будут обработаны только те пакеты, которые совпадают с выражением.
Tcpdump будет, если не запущен с ключем -c, продолжать собирать пакеты до тех пор, пока не будет прерван сигналом SIGINT (генерируемым, для примера, вводом Вашего символа прерывания, обычно CTRL+C) или сигналом SIGTERM (обычно генерируемого командой kill). Если запуск был с ключем -c, то сбор пакетов будет продолжаться до тех пор, пока не произойдет прерывание сигналом SIGINT или SIGTERM или пока не будет обработано определенное количество пакетов.
Когда tcpdump закончит сбор пакетов, то будет сообщено об количестве:
пакетов "полученных фильтром" (received by filter) (значение зависит от той ОС, на какой Вы запускаете tcpdump, и, возможно, от способа, котрым ОС была сконфигурирована - если фильтр был определен в командной строке, на некоторых ОС будут сосчитаны пакеты независимо от фильтрующего выражения, а в других ОС будут сосчитаны только те пакеты, которые попадают под фильтрующее и выражение, и были обработаны tcpdump);
пакетов "отброшенных ядром" (dropped by kernel) (это число пакетов, которые были отброшены, в зависимости от механизма сбора пакетов (недостаточного объема буферов) на той ОС, где запускается tcpdump, ОС предоставит эту инофрмацию приложению или нет, и тогда будет выведено число 0)
Это был перевод - исправления приветствуются.
Дальше идет описание ключей. Вот некоторые из них:
-c count Выйти после получения определенного количества пакетов.
-C file_size Перед записью "сырого" пакета в файл, происходит проверка на превышение размером файла лимита, указанного в file_size. Если размер файла больше, то файл закрывается и открывается новый. Новый файл будет иметь имя определенное в ключе -w, со стоящим в конце числом 2, которое будет увеличиваться в следующих именах файлов. file_size определяет размер в миллионах байт (1,000,000), а не мегабайтах (1,048,576).
-F file Использовать file для ввода фильтрующего выражения. Выражение, указанное в командной строке, будет игнорироваться.
-i interface Собирать пакеты только на определенном интерфейсе. Если не указан - берется минимальный по номеру интерфейс (исключая loopback). Для Linux-ядер 2.2 и более новых, возможно указать 'any', тогда будет происходить сбор на всех интерфейсах, но они не будут переведены в режим promiscuous.
-n Не преобразовывать адрес хоста в имя. Может быть использовано, если необходимо избегать DNS-запросов.
-nn Не преобразовывать протокол и номер порта в их имена.
-N Не выводить доменную часть имени хоста. Например, при данном ключе будет выводится "nic" вместо "nic.ddn.mil"
-p Не переводить интерфейс в режим promiscuous. Следует заметить, что интерфейс может быть в режиме promiscuous по другим причинам.
-r file Читать пакеты из file (который, был создан с ключем -w). Если file указан как "-", то используется стандартный ввод.
-t Не выводить временной штамп (timestamp) в каждой строке дампа (dump).
-tt Выводит не форматированный временной штамп в каждой строке дампа.
-ttt Выводить разницу (в микросекундах) между текущей и предыдущей строками дампа.
-tttt Выводить временной штамп вместе с датой в формате по-умолчанию в каждой строке дампа.
-v (Чуть более) подробный вывод. Для еще более подробного вывода используются: -vv и -vvv.
-w file Писать "сырые" пакеты в file перед тем как произвести их разбор и вывести. Они могут быть позднее выведены с ключем -r. Если file указан как "-", то используется стандартный вывод.
-x Печатать каждый пакет (без заголовков уровня соединения) в шестнадцатиричном виде.
-X Помимо шестнадцатиричного вида выводить их ASCII-значения.
Теперь, рассмотрим фильтрующее выражение.
Оно выбирает какие пакеты будут выбираться из общего потока. Если оно не указано, то будут выбираться и выводится все пакеты идущие через интерфейс. Иначе, будут обработаны только те пакеты, для которых проверка с выражением выдаст значение "истина" (true).
Выражение состоит из одного или более примитивов. Примитивы обычно состоят из ID (имя или номер) следующего за одним или более классификаторами. Различают три вида классификаторов:
type Говорят к какому виду относить ID. Возможный значения host, net или port. Пример: 'host foo', 'net 128.3', 'port 20'. Если классификатор type не указан, то подразумевается host.
dir Определяет конкретное направление передачи "к" и/или "от" ID. Возможны значения src, dst, src or dst and src and dst. Пример, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'. Если не указан, то подразумевается src or dst. Для соединений нулевого ('null') уровня (к примеру, протокол точка-точка, такой как slip) указанием направления могут быть классификаторы inbound и outbound.
proto Ограничивает совпадение конкретным протоколом. Возможные протоколы: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp и udp. Пример, 'ether src foo', 'arp net 128.3', 'tcp port 21'. Если классификатор proto не указан, то подразумеваются все перечисленные типы протоколов. Например, 'src foo означает '(ip or arp or rarp) src foo', 'net bar' означает '(ip or arp or rarp) net bar', а 'port 53' означает '(tcp or udp) port 53'.
В добавок, существует несколько специальных примитивов - ключевых слов: gateway, broadcast, less, greater и арифметические выражения.
Более сложные фильтрующие выражения могут быть построены с помощью слов and, or и not, объединяющих примитивы. Пример, 'host foo and not port ftp and not port ftp-data'. Чтобы уменьшить количество вводимой информации, идентичные списки классификаторов могут быть опущены. Пример, 'tcp dst port ftp or ftp-data or domain' это тоже самое, что и 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'
Перечислим некоторые из допустимых примитивов (за более полным списком в man tcpdump):
dst host host
Истина, если поле "назначение" пакета -это host, который может быть адресом или именем
src host host
Истина, если поле "источник" пакета - это host.
host host
Истина, если или поле "назначение", или поле "источник" пакета - это host. Любое из описанный выше выражений может быть приписано к ключевому слову ip, arp, rarp, или ip6, как в 'ip host host', что эквивалентно 'ether proto \ip and host host'. Если host - это имя с несколькими IP адресам, то проверяется совпадение по каждому адресу.
net net mask netmask
Истина, если IP адрес входит в сеть с указанной сетевой маской. Может быть классифицировано с dst или src.
net net/len
Истина, если IP адрес входит в сеть с указанной сетевой маской, заданной количеством бит. Может быть классифицировано с dst или src.
dst port port
Истина, если пакет протоколов ip/tcp, ip/udp, ip6/tcp или ip6/udp, и порт-назначения имеет значение указанное в port. Порт может быть числом или именем, используемым в /etc/services. Если используется число или неоднозначное имя, то проверяется только номер порта (пример, 'dst port 513' будет выводить трафик и для tcp/login и для udp/who, а 'port domain' будет выводить трафик и для tcp/domain и для udp/domain).
src port port
Истина, если пакет имеет порт-источник - port
port port
Истина, если или порт-назначение, или порт-источник в пакете - port. Любое из описанных выше выражений может быть приписано к ключевому слову tcp или udp, как в 'tcp src port port', проверяющее совпадения только для TCP-пакетов.
less length
Истина, если пакет имеет длину меньше или равную length. Это эквивалентно len <= length.
greater length
Истина, если пакет имеет длину больше или равную length. Это эквивалентно len >= length.
ip proto protocol
Истина, если пакет - это IP-пакет протокола, указанного в protocol. Протокол может быть числом или одним из имен icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, или tcp. Заметим, что идентификаторы tcp, udp и icmp - ключевые слова и должны быть "заэкскейпены" через обратный слэш (\).
Прежде чем переходит к примерам рассмотрим, что может нам выдать tcpdump при выполнении.
Типичные результаты работы tcpdump -ttt:
1. 000107 192.168.2.13 > 192.168.2.254: icmp: 192.168.2.13 udp port 3631 unreachable
2. 000313 192.168.2.254.53 > 192.168.2.13.3656: 4 ServFail 0/0/0 (22) (DF)
3. 000287 192.168.2.254 > 192.168.2.100: icmp: net 205.188.179.233 unreachable [tos 0xc0]
4. 010956 192.168.2.254.139 > 192.168.2.13.3661: P 1:5(4) ack 73 win 5840 NBT Packet (DF)
5. 276274 192.168.2.150.3053 > 192.168.2.254.53: 7+ A? Tatyana.karavay-shops.ru. (42)
6. 001162 192.168.2.100.32772 > 192.168.2.254.16007: . ack 73 win 5840 (DF)
Первое поле - поле времени, т. к. запуск осуществлялся с ключом "-ttt", то это разница в микросекундах между этим пакетом и предыдущим.
Потом идет IP-адрес (или имя) отправителя пакета, через точку может указываться порт. После знака ">", указывается получатель пакета (или его имя) и также порт. Затем будет идти либо сразу служебная информация идущая в пакете, либо протокол (у нас это icmp). В служебной информации может быть указано либо состояние флагов в пакете, либо расшифрованная информация ("192.168.2.13 udp port 3631 unreachable" или DNS-запрос об хосте "Tatyana.karavay-shops.ru").
Ну а теперь пора взяться за конкретные примеры.
1. Ловим весь входящий трафик из локальной сети на сервер. Здесь все просто.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt dst host 192.168.2.254
Если вы запускаете его в SSH сессии, то подготовьтесь - польется очень много и очень быстро...
2. Ловим весь входящий трафик, исключая трафик генерируемый нашей SSH-сессией.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'dst host 192.168.2.254 and not ( src host 192.168.2.100 and dst port 22 )'
Вот теперь в потоке пакетов можно разобраться.
3. Нужна информация об DNS-общении между сервером и каким-нибудь узлом сети.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and ip proto \udp'
Здесь, кстати будет бегать не только DNS-трафик. А вообще весь, который идет по UDP. Исправить это можно следующим:
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and port 53'
4. Отлавливаем исключительно icmp пакеты.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'ip proto \icmp'
Вот. Теперь все.
Не забывайте, что более подробную информацию можно получить из man tcpdump. Там же можно прочитать об структуре пакетов основных протоколов, что позволит еще глубже исследовать Ваши сети.
Итак, tcpdump.
$ man tcpdump, нам гласит
Tcpdump выводит заголовки пакетов проходящих через сетевой интерфейс, которые совпадают с булевым выражением. Он может также быть запущен с ключем -w, который заставляет сохранять данные пактов в файл для дальнейшего исследования, и/или с ключем -r, который заставляет читать сохраненные пакеты из файла, вместо чтения пакетов из сетевого интерфейса. В любом случае, tcpdump будут обработаны только те пакеты, которые совпадают с выражением.
Tcpdump будет, если не запущен с ключем -c, продолжать собирать пакеты до тех пор, пока не будет прерван сигналом SIGINT (генерируемым, для примера, вводом Вашего символа прерывания, обычно CTRL+C) или сигналом SIGTERM (обычно генерируемого командой kill). Если запуск был с ключем -c, то сбор пакетов будет продолжаться до тех пор, пока не произойдет прерывание сигналом SIGINT или SIGTERM или пока не будет обработано определенное количество пакетов.
Когда tcpdump закончит сбор пакетов, то будет сообщено об количестве:
пакетов "полученных фильтром" (received by filter) (значение зависит от той ОС, на какой Вы запускаете tcpdump, и, возможно, от способа, котрым ОС была сконфигурирована - если фильтр был определен в командной строке, на некоторых ОС будут сосчитаны пакеты независимо от фильтрующего выражения, а в других ОС будут сосчитаны только те пакеты, которые попадают под фильтрующее и выражение, и были обработаны tcpdump);
пакетов "отброшенных ядром" (dropped by kernel) (это число пакетов, которые были отброшены, в зависимости от механизма сбора пакетов (недостаточного объема буферов) на той ОС, где запускается tcpdump, ОС предоставит эту инофрмацию приложению или нет, и тогда будет выведено число 0)
Это был перевод - исправления приветствуются.
Дальше идет описание ключей. Вот некоторые из них:
-c count Выйти после получения определенного количества пакетов.
-C file_size Перед записью "сырого" пакета в файл, происходит проверка на превышение размером файла лимита, указанного в file_size. Если размер файла больше, то файл закрывается и открывается новый. Новый файл будет иметь имя определенное в ключе -w, со стоящим в конце числом 2, которое будет увеличиваться в следующих именах файлов. file_size определяет размер в миллионах байт (1,000,000), а не мегабайтах (1,048,576).
-F file Использовать file для ввода фильтрующего выражения. Выражение, указанное в командной строке, будет игнорироваться.
-i interface Собирать пакеты только на определенном интерфейсе. Если не указан - берется минимальный по номеру интерфейс (исключая loopback). Для Linux-ядер 2.2 и более новых, возможно указать 'any', тогда будет происходить сбор на всех интерфейсах, но они не будут переведены в режим promiscuous.
-n Не преобразовывать адрес хоста в имя. Может быть использовано, если необходимо избегать DNS-запросов.
-nn Не преобразовывать протокол и номер порта в их имена.
-N Не выводить доменную часть имени хоста. Например, при данном ключе будет выводится "nic" вместо "nic.ddn.mil"
-p Не переводить интерфейс в режим promiscuous. Следует заметить, что интерфейс может быть в режиме promiscuous по другим причинам.
-r file Читать пакеты из file (который, был создан с ключем -w). Если file указан как "-", то используется стандартный ввод.
-t Не выводить временной штамп (timestamp) в каждой строке дампа (dump).
-tt Выводит не форматированный временной штамп в каждой строке дампа.
-ttt Выводить разницу (в микросекундах) между текущей и предыдущей строками дампа.
-tttt Выводить временной штамп вместе с датой в формате по-умолчанию в каждой строке дампа.
-v (Чуть более) подробный вывод. Для еще более подробного вывода используются: -vv и -vvv.
-w file Писать "сырые" пакеты в file перед тем как произвести их разбор и вывести. Они могут быть позднее выведены с ключем -r. Если file указан как "-", то используется стандартный вывод.
-x Печатать каждый пакет (без заголовков уровня соединения) в шестнадцатиричном виде.
-X Помимо шестнадцатиричного вида выводить их ASCII-значения.
Теперь, рассмотрим фильтрующее выражение.
Оно выбирает какие пакеты будут выбираться из общего потока. Если оно не указано, то будут выбираться и выводится все пакеты идущие через интерфейс. Иначе, будут обработаны только те пакеты, для которых проверка с выражением выдаст значение "истина" (true).
Выражение состоит из одного или более примитивов. Примитивы обычно состоят из ID (имя или номер) следующего за одним или более классификаторами. Различают три вида классификаторов:
type Говорят к какому виду относить ID. Возможный значения host, net или port. Пример: 'host foo', 'net 128.3', 'port 20'. Если классификатор type не указан, то подразумевается host.
dir Определяет конкретное направление передачи "к" и/или "от" ID. Возможны значения src, dst, src or dst and src and dst. Пример, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'. Если не указан, то подразумевается src or dst. Для соединений нулевого ('null') уровня (к примеру, протокол точка-точка, такой как slip) указанием направления могут быть классификаторы inbound и outbound.
proto Ограничивает совпадение конкретным протоколом. Возможные протоколы: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp и udp. Пример, 'ether src foo', 'arp net 128.3', 'tcp port 21'. Если классификатор proto не указан, то подразумеваются все перечисленные типы протоколов. Например, 'src foo означает '(ip or arp or rarp) src foo', 'net bar' означает '(ip or arp or rarp) net bar', а 'port 53' означает '(tcp or udp) port 53'.
В добавок, существует несколько специальных примитивов - ключевых слов: gateway, broadcast, less, greater и арифметические выражения.
Более сложные фильтрующие выражения могут быть построены с помощью слов and, or и not, объединяющих примитивы. Пример, 'host foo and not port ftp and not port ftp-data'. Чтобы уменьшить количество вводимой информации, идентичные списки классификаторов могут быть опущены. Пример, 'tcp dst port ftp or ftp-data or domain' это тоже самое, что и 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'
Перечислим некоторые из допустимых примитивов (за более полным списком в man tcpdump):
dst host host
Истина, если поле "назначение" пакета -это host, который может быть адресом или именем
src host host
Истина, если поле "источник" пакета - это host.
host host
Истина, если или поле "назначение", или поле "источник" пакета - это host. Любое из описанный выше выражений может быть приписано к ключевому слову ip, arp, rarp, или ip6, как в 'ip host host', что эквивалентно 'ether proto \ip and host host'. Если host - это имя с несколькими IP адресам, то проверяется совпадение по каждому адресу.
net net mask netmask
Истина, если IP адрес входит в сеть с указанной сетевой маской. Может быть классифицировано с dst или src.
net net/len
Истина, если IP адрес входит в сеть с указанной сетевой маской, заданной количеством бит. Может быть классифицировано с dst или src.
dst port port
Истина, если пакет протоколов ip/tcp, ip/udp, ip6/tcp или ip6/udp, и порт-назначения имеет значение указанное в port. Порт может быть числом или именем, используемым в /etc/services. Если используется число или неоднозначное имя, то проверяется только номер порта (пример, 'dst port 513' будет выводить трафик и для tcp/login и для udp/who, а 'port domain' будет выводить трафик и для tcp/domain и для udp/domain).
src port port
Истина, если пакет имеет порт-источник - port
port port
Истина, если или порт-назначение, или порт-источник в пакете - port. Любое из описанных выше выражений может быть приписано к ключевому слову tcp или udp, как в 'tcp src port port', проверяющее совпадения только для TCP-пакетов.
less length
Истина, если пакет имеет длину меньше или равную length. Это эквивалентно len <= length.
greater length
Истина, если пакет имеет длину больше или равную length. Это эквивалентно len >= length.
ip proto protocol
Истина, если пакет - это IP-пакет протокола, указанного в protocol. Протокол может быть числом или одним из имен icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, или tcp. Заметим, что идентификаторы tcp, udp и icmp - ключевые слова и должны быть "заэкскейпены" через обратный слэш (\).
Прежде чем переходит к примерам рассмотрим, что может нам выдать tcpdump при выполнении.
Типичные результаты работы tcpdump -ttt:
1. 000107 192.168.2.13 > 192.168.2.254: icmp: 192.168.2.13 udp port 3631 unreachable
2. 000313 192.168.2.254.53 > 192.168.2.13.3656: 4 ServFail 0/0/0 (22) (DF)
3. 000287 192.168.2.254 > 192.168.2.100: icmp: net 205.188.179.233 unreachable [tos 0xc0]
4. 010956 192.168.2.254.139 > 192.168.2.13.3661: P 1:5(4) ack 73 win 5840 NBT Packet (DF)
5. 276274 192.168.2.150.3053 > 192.168.2.254.53: 7+ A? Tatyana.karavay-shops.ru. (42)
6. 001162 192.168.2.100.32772 > 192.168.2.254.16007: . ack 73 win 5840 (DF)
Первое поле - поле времени, т. к. запуск осуществлялся с ключом "-ttt", то это разница в микросекундах между этим пакетом и предыдущим.
Потом идет IP-адрес (или имя) отправителя пакета, через точку может указываться порт. После знака ">", указывается получатель пакета (или его имя) и также порт. Затем будет идти либо сразу служебная информация идущая в пакете, либо протокол (у нас это icmp). В служебной информации может быть указано либо состояние флагов в пакете, либо расшифрованная информация ("192.168.2.13 udp port 3631 unreachable" или DNS-запрос об хосте "Tatyana.karavay-shops.ru").
Ну а теперь пора взяться за конкретные примеры.
1. Ловим весь входящий трафик из локальной сети на сервер. Здесь все просто.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt dst host 192.168.2.254
Если вы запускаете его в SSH сессии, то подготовьтесь - польется очень много и очень быстро...
2. Ловим весь входящий трафик, исключая трафик генерируемый нашей SSH-сессией.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'dst host 192.168.2.254 and not ( src host 192.168.2.100 and dst port 22 )'
Вот теперь в потоке пакетов можно разобраться.
3. Нужна информация об DNS-общении между сервером и каким-нибудь узлом сети.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and ip proto \udp'
Здесь, кстати будет бегать не только DNS-трафик. А вообще весь, который идет по UDP. Исправить это можно следующим:
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and port 53'
4. Отлавливаем исключительно icmp пакеты.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'ip proto \icmp'
Вот. Теперь все.
Не забывайте, что более подробную информацию можно получить из man tcpdump. Там же можно прочитать об структуре пакетов основных протоколов, что позволит еще глубже исследовать Ваши сети.
вівторок, 3 березня 2009 р.
Мониторинг нагрузки Apache 2
Рассмотрим ситуацию: у вас на сервере хостится несколько сайтов работающих через mod_php под Apache 2.x. Вы обнаруживаете, что сервер начинает тормозить. Запускаете top и видите, что верхние строчки занимает процесс apache2 (или httpd). Ваша задача — узнать какой из сайтов и какими запросами грузит сервер.
Первый шаг — разрешить загрузку модуля mod_status и сконфигурировать его в /etc/apache2/mods-available/status.conf или в /etc/apache2/apache2.conf (я буду писать пути и команды применительно к Debian):
ExtendedStatus On
SetHandler server-status
Можно опционально ограничить доступ к URL /server-status по IP-адресу или даже поставить пароль.
Добавляем к любому сайту на сервере путь /server-status и смотрим, что там показывается. Если видим много запросов к какому либо сайту в состоянии «W», то можно предположить, что проблема с этим сайтом. Но это будет лишь гипотеза, так как узнать точно ситуацию по нагрузке, используя данный отчет, невозможно.
Используем хитрый ход. Установим модуль mod_perl:
apt-get install libapache2-mod-perl2 apache2-prefork-dev
Пакет apache2-prefork-dev нужен для последующей установки перловых модулей. Далее запустим cpan и установим пару модулей:
cpan> install Sys::Proctitle
cpan> install Apache2::ShowStatus
В файл /etc/apache2/mods-available/perl.conf добавим следующие строчки:
PerlModule Apache2::ShowStatus
PerlInitHandler Apache2::ShowStatus
Проставим линк на этот файл и перезагрузим Apache:
ln -s /etc/apache2/mods-available/perl.conf /etc/apache2/mods-enabled/
apache2 -t
invoke-rc.d apache2 restart
Смотрим что из этого получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | egrep '^USER|httpd' | grep -v grep
USER PID %CPU COMMAND
www-data 14039 0.6 httpd: GET /notices_item/????? HTTP/1.0
www-data 14073 0.5 httpd: GET /notice/???????.html HTTP/1.0
www-data 14069 0.5 httpd: GET /r_9/ HTTP/1.0
www-data 14075 0.5 httpd: GET /notice/???????.html HTTP/1.0
Я заменил часть URL-ов вопросиками из соображений конфиденциальности.
Ну что же, это неплохо, теперь мы видим отсортированные по полю %CPU процессы Apache, а так же видим, какой запрос они выполняют в данный момент. Но мы не видим к какому сайту относятся эти запросы. Придеться немного подпатчить модуль Apache2::ShowStatus в файле /usr/local/share/perl/5.8.8/Apache2/ShowStatus.pm:
--- ShowStatus.pm.orig 2009-01-22 14:19:26.122058102 +0300
+++ ShowStatus.pm 2009-01-22 14:21:01.030847967 +0300
@@ -16,7 +16,7 @@
my $r=shift;
$r->pnotes( 'ProctitleObject'=>
- Sys::Proctitle->new( 'httpd: '.$r->the_request ) );
+ Sys::Proctitle->new( 'httpd: ['.$r->get_server_name().'] '.$r->the_request ) );
return Apache2::Const::DECLINED;
}
Перезагружаем Apache:
invoke-rc.d apache2 restart
Смотрим, что получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | grep httpd | grep -v grep
www-data 16927 3.3 httpd: [www.????????.ru] GET /img_code.html HTTP/1.0
www-data 16885 3.2 httpd: [76.?????????.ru] GET /notices_item/???????/user_register/ HTTP/1.0
www-data 16921 1.0 httpd: [www.??????.ru] GET /products_item/?????? HTTP/1.0
www-data 16933 0.5 httpd: [www.????????.ru] GET /notice/????????.html HTTP/1.0
www-data 16878 0.5 httpd: [??????????.ru] GET /main_???????? HTTP/1.0
www-data 16930 0.2 httpd: [www.??????????.ru] GET /notice/??????????.html?sd=?????????????????????????????? HTTP/1.0
Ну вот, теперь мы видим и сайт, к которому пришел запрос, и сам запрос.
Кто еще какие способы использует для мониторинга нагрузки на хостинге в окружении Apache2 + mod_php5?
Первый шаг — разрешить загрузку модуля mod_status и сконфигурировать его в /etc/apache2/mods-available/status.conf или в /etc/apache2/apache2.conf (я буду писать пути и команды применительно к Debian):
ExtendedStatus On
SetHandler server-status
Можно опционально ограничить доступ к URL /server-status по IP-адресу или даже поставить пароль.
Добавляем к любому сайту на сервере путь /server-status и смотрим, что там показывается. Если видим много запросов к какому либо сайту в состоянии «W», то можно предположить, что проблема с этим сайтом. Но это будет лишь гипотеза, так как узнать точно ситуацию по нагрузке, используя данный отчет, невозможно.
Используем хитрый ход. Установим модуль mod_perl:
apt-get install libapache2-mod-perl2 apache2-prefork-dev
Пакет apache2-prefork-dev нужен для последующей установки перловых модулей. Далее запустим cpan и установим пару модулей:
cpan> install Sys::Proctitle
cpan> install Apache2::ShowStatus
В файл /etc/apache2/mods-available/perl.conf добавим следующие строчки:
PerlModule Apache2::ShowStatus
PerlInitHandler Apache2::ShowStatus
Проставим линк на этот файл и перезагрузим Apache:
ln -s /etc/apache2/mods-available/perl.conf /etc/apache2/mods-enabled/
apache2 -t
invoke-rc.d apache2 restart
Смотрим что из этого получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | egrep '^USER|httpd' | grep -v grep
USER PID %CPU COMMAND
www-data 14039 0.6 httpd: GET /notices_item/????? HTTP/1.0
www-data 14073 0.5 httpd: GET /notice/???????.html HTTP/1.0
www-data 14069 0.5 httpd: GET /r_9/ HTTP/1.0
www-data 14075 0.5 httpd: GET /notice/???????.html HTTP/1.0
Я заменил часть URL-ов вопросиками из соображений конфиденциальности.
Ну что же, это неплохо, теперь мы видим отсортированные по полю %CPU процессы Apache, а так же видим, какой запрос они выполняют в данный момент. Но мы не видим к какому сайту относятся эти запросы. Придеться немного подпатчить модуль Apache2::ShowStatus в файле /usr/local/share/perl/5.8.8/Apache2/ShowStatus.pm:
--- ShowStatus.pm.orig 2009-01-22 14:19:26.122058102 +0300
+++ ShowStatus.pm 2009-01-22 14:21:01.030847967 +0300
@@ -16,7 +16,7 @@
my $r=shift;
$r->pnotes( 'ProctitleObject'=>
- Sys::Proctitle->new( 'httpd: '.$r->the_request ) );
+ Sys::Proctitle->new( 'httpd: ['.$r->get_server_name().'] '.$r->the_request ) );
return Apache2::Const::DECLINED;
}
Перезагружаем Apache:
invoke-rc.d apache2 restart
Смотрим, что получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | grep httpd | grep -v grep
www-data 16927 3.3 httpd: [www.????????.ru] GET /img_code.html HTTP/1.0
www-data 16885 3.2 httpd: [76.?????????.ru] GET /notices_item/???????/user_register/ HTTP/1.0
www-data 16921 1.0 httpd: [www.??????.ru] GET /products_item/?????? HTTP/1.0
www-data 16933 0.5 httpd: [www.????????.ru] GET /notice/????????.html HTTP/1.0
www-data 16878 0.5 httpd: [??????????.ru] GET /main_???????? HTTP/1.0
www-data 16930 0.2 httpd: [www.??????????.ru] GET /notice/??????????.html?sd=?????????????????????????????? HTTP/1.0
Ну вот, теперь мы видим и сайт, к которому пришел запрос, и сам запрос.
Кто еще какие способы использует для мониторинга нагрузки на хостинге в окружении Apache2 + mod_php5?
Замечательный препроцессор для iptables
Я вполне хорошо знаю и умею пользоваться iptables, но не могу сказать, что написание сложных правил доставляет мне удовольствие, в отличие от того же pf). GUI для iptables меня обычно либо вводят в шок (например, fwbuilder просто вынес мне мозг, предоставив писать правила для iptables, как обычно, только мышкой), либо не дают всех нужных возможностей, которые есть в iptables.
На днях, наткнулся на совершенно замечательный препроцессор для iptables, который позволяет описывать правила на более высоком уровне. Что абсолютно радует, это человекочитаемость полученного конфига. В общем, я влюбился в эту программу. Зовется она ferm, подробно о ней можно почитать на домашней страничке проекта. Проект активно развивается, последняя версия выходила в этом месяце.
Чтобы вы сразу прониклись, красотой этой программы, кидаю свой конфиг /etc/ferm/ferm.conf с моего десктопного компа:
# -*- shell-script -*-
#
# Configuration file for ferm(1).
#
table filter {
chain INPUT {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
# allow local packages
interface lo ACCEPT;
# respond to ping
proto icmp ACCEPT;
interface eth1 {
mod state state NEW {
# pdns-recursor
proto (tcp udp) dport domain ACCEPT;
proto tcp {
# ssh
dport ssh ACCEPT;
# pulseaudio
dport 4713 ACCEPT;
# mysql
dport 3306 ACCEPT;
# memcached
dport 11211 ACCEPT;
}
}
}
}
chain OUTPUT {
policy ACCEPT;
# connection tracking
#mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
}
chain FORWARD {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
mod state state NEW {
interface eth1 ACCEPT;
outerface eth1 ACCEPT;
}
}
}
table nat {
chain POSTROUTING {
outerface (ppp0 ppp1) saddr 192.168.0.0/24 MASQUERADE;
}
}
# vim:sw=4 ts=4:
На днях, наткнулся на совершенно замечательный препроцессор для iptables, который позволяет описывать правила на более высоком уровне. Что абсолютно радует, это человекочитаемость полученного конфига. В общем, я влюбился в эту программу. Зовется она ferm, подробно о ней можно почитать на домашней страничке проекта. Проект активно развивается, последняя версия выходила в этом месяце.
Чтобы вы сразу прониклись, красотой этой программы, кидаю свой конфиг /etc/ferm/ferm.conf с моего десктопного компа:
# -*- shell-script -*-
#
# Configuration file for ferm(1).
#
table filter {
chain INPUT {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
# allow local packages
interface lo ACCEPT;
# respond to ping
proto icmp ACCEPT;
interface eth1 {
mod state state NEW {
# pdns-recursor
proto (tcp udp) dport domain ACCEPT;
proto tcp {
# ssh
dport ssh ACCEPT;
# pulseaudio
dport 4713 ACCEPT;
# mysql
dport 3306 ACCEPT;
# memcached
dport 11211 ACCEPT;
}
}
}
}
chain OUTPUT {
policy ACCEPT;
# connection tracking
#mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
}
chain FORWARD {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
mod state state NEW {
interface eth1 ACCEPT;
outerface eth1 ACCEPT;
}
}
}
table nat {
chain POSTROUTING {
outerface (ppp0 ppp1) saddr 192.168.0.0/24 MASQUERADE;
}
}
# vim:sw=4 ts=4:
середа, 25 лютого 2009 р.
Добавление скрипта в автозагрузку
Добавить скрипт в автозагрузку
Пишем скрипт и помещаем его в каталог /etc/init.d Находясь в нем, набираем
# update-rc.d НАЗВАНИЕ_СКРИПТА defaults 99
-defaults запускать на уровнях выполнения по умолчанию (2 - 5)
-99 порядок загрузки
Отключить автозапуск скрипта (удалить все ссылки на скрипт)
Переходим в каталог /etc/init.d
# update-rc.d -f НАЗВАНИЕ_СКРИПТА remove
-f - удалить ссылки на скрипт из всех уровней запуска (сам скрипт в /etc/init.d не удаляется)
Полностью удалить скрипт из автозагрузки и все ссылки на него
Переходим в каталог /etc/init.d
# rm НАЗВАНИЕ_СКРИПТА
# update-rc.d НАЗВАНИЕ_СКРИПТА remove
Cделать локальный репозитарий
Есть куча deb пакетов когда то скачанных из интернета. Чтобы сделать из них свой репозитарий нужно перейти в каталог где лежат эти пакеты и выполнить:
$ dpkg-scanpackages . /dev/null | gzip > Packages.gz
Появиться файл Packages.gz Затем добавляем этой файл в начало файла /etc/apt/sources.list. Допустим пакеты лежат в /home/coder/debs, тогда строка будет выклядеть так
deb file:/home/coder/debs ./
Все. Теперь
# aptitude update
и можно пользоваться.
P.S. Утилита dpkg-scanpackages находиться в пакете dpkg-dev.
Сформировать пакеты из уже установленных программ (оригинальные deb пакеты были утеряны)
dpkg --get-selections | grep -v "deinstall" | awk '{print $1}' | xargs dpkg-repack
Пишем скрипт и помещаем его в каталог /etc/init.d Находясь в нем, набираем
# update-rc.d НАЗВАНИЕ_СКРИПТА defaults 99
-defaults запускать на уровнях выполнения по умолчанию (2 - 5)
-99 порядок загрузки
Отключить автозапуск скрипта (удалить все ссылки на скрипт)
Переходим в каталог /etc/init.d
# update-rc.d -f НАЗВАНИЕ_СКРИПТА remove
-f - удалить ссылки на скрипт из всех уровней запуска (сам скрипт в /etc/init.d не удаляется)
Полностью удалить скрипт из автозагрузки и все ссылки на него
Переходим в каталог /etc/init.d
# rm НАЗВАНИЕ_СКРИПТА
# update-rc.d НАЗВАНИЕ_СКРИПТА remove
Cделать локальный репозитарий
Есть куча deb пакетов когда то скачанных из интернета. Чтобы сделать из них свой репозитарий нужно перейти в каталог где лежат эти пакеты и выполнить:
$ dpkg-scanpackages . /dev/null | gzip > Packages.gz
Появиться файл Packages.gz Затем добавляем этой файл в начало файла /etc/apt/sources.list. Допустим пакеты лежат в /home/coder/debs, тогда строка будет выклядеть так
deb file:/home/coder/debs ./
Все. Теперь
# aptitude update
и можно пользоваться.
P.S. Утилита dpkg-scanpackages находиться в пакете dpkg-dev.
Сформировать пакеты из уже установленных программ (оригинальные deb пакеты были утеряны)
dpkg --get-selections | grep -v "deinstall" | awk '{print $1}' | xargs dpkg-repack
середа, 11 лютого 2009 р.
DNS Amplification (DNS усиление)
Не так давно столкнулся с проблемой (и ее решением) учитывая актуальность этой темы в последнее время, а также то, сколько людей сейчас страдают от этой беды, решил объединить информацию в одну статью. Может быть кому-то еще она будет полезной.
Начало
Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:
10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)
На что, как видно из лога, сервер отвечал отказами. Естественно мне стало интересно, что за IP-адреса долбят мой DNS. Посмотрев несколько адресов через whois я определил, что это крупные хостинговые компании, я написал просьбу прекратить атаку на мой сервер в техподдержку некоторых из них. В ответ я получил отписку, что этот тип атаки относится к тем, что они не могут блокировать, и что они сами они страдают от этой аномальной активности. Было решено со всем разбираться самому.
DNS Amplification (DNS усиление). Теория
Сам тип атаки не нов — о нем было известно еще в 2006 году, подробности на английском языке можно посмотреть здесь , однако активно использовать его начали относительно недавно. В январе-феврале 2009 года несколько интернет-изданий опубликовало информацию о крупномасштабном использовании киберпреступниками этого вида DDOS, о чем можно узнать здесь и на английском языке здесь
Объясняя простым языком, суть усиления заключается в том, что злоумышленник посылает (обычно короткий) запрос уязвимому DNS-серверу, который отвечает на запрос уже значительно большим по размеру пакетом. Если использовать в качестве исходного IP-адреса при отправке запроса адрес компьютера жертвы (ip spoofing), то уязвимый DNS-сервер будет посылать в большом количестве ненужные пакеты компьютеру-жертве, пока полностью не парализует его работу.
Практика
Наиболее эффективен этот тип атаки на старом (непропатченном) или неправильно сконфигурированном DNS-сервере, который, как уже было сказано, отвечает на короткие запросы злоумышленников большими по размеру пакетами.
Вот пример такого взаимодействия (кстати именно такие запросы чаще всего используют атакующие):
Отправляем серверу NS запрос командой
#dig @SERVER_IP NS
где SERVER_IP — IP-адрес сервера. В результате в логе по 53 порту сервера получаем:
11:08:47.994604 IP MY_IP.47816 > SERVER_IP.53: 5655+ NS?. (17)
т.е. как раз те 17 байт запроса, что мы хотели послать.
В ответ в то же самом логе видим:
11:08:47.995853 IP 192.168.100.254.53 > 192.168.100.100.47816: 5655 13/0/6 NS C.ROOT-SERVERS.NET.,[|domain]
т.е. сервер ответил нам подсказкой в виде адресов корневых DNS-серверов, что составляет уже 360 байт. Это длины DNS запроса и ответа, общая же длина пакетов 60 и 402 байта соответственно. Усиление налицо.
Что делать?
Во-первых конечно же проверить актуальность версии вашего DNS-сервера вне зависимости от того, на какой платформе он работает. Во-вторых, убедиться, что настроен сервер достаточно безопасно и не отвечает на «левые» запросы всем подряд. Об этом в сети можно найти множество мануалов и рекомендаций, упомяну здесь только об одном документе, который нашел не так давно.
Что еще можно сделать?
В моем случае делать было уже особенно нечего. Если посмотреть самый первый лог, который я привел, то видно, что атакующий отправляет запрос длиной 17 байт и получает REJECT той же самой длины (17 байт), т.е. никакого усиления не происходит. Но, видимо, «ddos-еры» особенно не торопятся убирать из своих списков адреса DNS-серверов, не подверженных этой уязвимости, и продолжают беспокоить их своей долбежкой… Эта ситуация меня не устраивала. Неприятно что от моего адреса кто-то получает на свой сервер ненужный трафик (даже пусть я в этом и не виноват).
Поначалу я начал ставить в black-лист адреса отправителей, но не тут-то было, со старых адресов атака прекращалась, но появлялись все новые и новые. Было решено использовать более изощренные методы фильтрации и задействовать на моем Linux-сервере модули iptables, до которых раньше у меня никак руки не доходили. Убить, так сказать, сразу двух зайцев — и атакующим сделать -1 и разобраться с парой модулей iptables.
Модуль String
Закрыть 53 порт (DNS) полностью я конечно же не мог — у меня много клиентов которым он нужен. Я решил фильтровать пакеты по содержимому DNS-запросов и убирать те из них, которые содержат запросы атакующих, а они все как один содержали в себе «NS». Для этой задачи подходит модуль iptables string, который как раз позволяет заглянуть в содержимое пакетов.
Для того, чтобы понять что фильтровать, посмотрим на пакет атакующего через wireshark.
Здесь и здесь можно почитать о структуре UDP пакетов и формате кадра DNS соответственно. Для краткости скажу, что первые 14 байт пакета занимают данные протокола Ethernet (на рис. красным), затем идут 20 байт заголовка протокола IP (на рис. синим), затем 8 байт — заголовок UDP (на рис. зеленым), после которого начинаются данные протокола DNS (на рис. желтым). Первые 12 байт кадра DNS занимает заголовок, после которого, наконец, начинается поле DNS Query (т.е. непосредственно сам запрос, на рис. оранжевым). В пакетах, присылаемых атакующим начиная с 54-ого (14+20+8+12) байта идут следующие данные: 00 00 02 00 01 (в шестнадцатеричном коде), что соответствует запросу «NS», о котором я говорил раньше. Таким образом нужно выделить пакеты, которые начиная с 54 байта содержат эти байты. Это будет выглядеть так:
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --jump DROP
Немного поясню.
--in-interface — указывает на каком интерфейсе отлавливать пакеты. Нужно поставить только внешний интерфейс, на который идет атака (незачем ущемлять пользователей во внутри сети).
--match state --state NEW — отлавливаем пакеты только со состоянием NEW, чтобы не проверять все транзакции подряд, а только инициирующие пакеты (мало ли что может передаваться по 53 порту).
Дальше идет самое интересное — задействуем модуль sting. Мы используем следующие параметры:
--algo — указывает алгоритм поиска, по сути не важен я указал kmp, но можно указать и bm;
--hex-string — записывается та самая строка в шестнадцатеричном виде, которую мы ищем;
--from 40 — ищем начиная с 40 байта (заметьте, не с 54 потому что string начинает поиск, а соответственно и отсчет от первого байта протокола IP, т.е. выбрасывается протокол Ethernet, длина которого 14 байт(на рис. сверху красным). Итого 54 — 14 = 40);
--to 45 — соответственно искать до 45 байта пакета.
Модуль Recent
На этом уже можно было бы остановиться. Пакеты уже не будут доходить до bind, но меня еще не утешала мысль, что я закрыл для ВСЕХ возможность обращаться с запросами NS к моему DNS-серверу, поэтому я решил задействовать еще один модуль iptables — recent.
Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.
Рассмотрим простой пример использования recent, состоящий из двух строк:
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --update --seconds 30 --name SSHT --jump DROP
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --set --name SSHT --jump ACCEPT
Начнем разбираться со второго правила. Каждый кто пытается зайти (именно зайти, т.к. мы используем --state NEW) на порт 22 (SSH) пропускается (--jump ACCEPT), но его IP-адрес попадает в таблицу с именем SSHT. Когда с этого адреса пытаются соединиться еще раз, начинает работать первое правило, смысл которого состоит в том, чтобы обновить (--update) запись в таблице и заодно проверить когда эта запись была установлена/обновлена в последний раз. Если запись была установлена/обновлена меньше 30 секунд назад (--seconds 30), то срабатывает --jump DROP и пакет отбрасывается. Таким образом брутфорсеры, пытающиеся долбиться на порт SSH будут отбрасывается, если частота отправки их пакетов будет превышать 1 пакет в 30 секунд.
Попробуем использовать recent для наших нужд:
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --update --seconds 600 --jump DROP
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --set --jump ACCEPT
Таким образом я разрешаю делать запросы NS на внешний интерфейс не чаще, чем 1 раз в 10 минут.
После добавления этих правил в /proc/net/xt_recent моего сервера появился файл DNST, в котором начали записываться IP-адреса атакующих. А DNS-сервер перестал поддаваться на провокации:
14:10:19.011818 IP 89.149.221.182.40320 > MY_IP.53: 23508+ NS?. (17)
14:10:25.243499 IP 89.149.221.182.64984 > MY_IP.53: 25306+ NS?. (17)
14:11:08.832827 IP 89.149.221.182.15864 > MY_IP.53: 48029+ NS?. (17)
14:11:15.063058 IP 89.149.221.182.30959 > MY_IP.53: 64444+ NS?. (17)
Через несколько дней работы правил количество пакетов со стороны атакующих снизилось в несколько раз. Сейчас я получаю 2-3 пакета в минуту, которые тут же отбрасываются фаерволом.
Джерело http://habrahabr.ru/blogs/infosecurity/51574/
четвер, 5 лютого 2009 р.
squid
From: Забудкин Лев Мирославович
Date: Fri, 14 Jan 2005 15:04:58 +0500 (YEKT)
Subject: Настройка Squid для начинающих
Настройка Squid для чайников
(версия статьи 1.0 от 29.10.2004)
Забудкин Лев Мирославович,
Россия, Тюменская область,
Г. Нижневартовск,
ведущий программист
МУ "Библиотечная-информационная система"
zabudkin@mail.ru
http://zabudkin.com
ВСТУПЛЕНИЕ
Многие администраторы сталкиваются с проблемой разумного использования
времени и канала для выхода в сеть Интернет, задумываются о возможности
экономии времени и денег, об ограничении скорости для отдельных видов
файлов или личностей, в конце концов об экономии всего, что связано с
теми или иными аспектами выхода в глобальную сеть.
Я, с помощью этой статьи, попытаюсь наглядно и доходчиво объяснить о
настройках самого распространенного прокси сервера - прокси
сервера Squid.
НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ
Мы не будем вдаваться в процесс установки прокси сервера Squid, а
перейдем сразу к его настройке.
Самое элементарное, что нам после установки следует сделать, так это
разрешить доступ пользователям нашей локальной сети. Для этого служат
параметры http_port, http_access. Кроме этого, мы заведем acl (список
контроля доступа) для нашей локальной сети.
И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid
должен обслуживать только компьютеры нашей локальной сети и быть
невидимым для внешнего мира, дабы исключить возможность "плохим
людям" внешней сети воспользоваться нашим каналом или трафиком, а
в случае, если будут обнаружены "дыры" в коде прокси сервера
Squid, воспользоваться ими.
Параметр http_access используется для разрешения или запрещения доступа
к определенным ресурсам, определенным адресам либо с определенных
адресов, к определенным сайтам, по определенным протоколам, портам и
всему тому, что непосредственно указано с помощью Acl (списков контроля
доступа).
Таблица N 1. Некоторые подсети.
|Диапазон адресов |Полная форма |Краткая форма
192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24
192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24
192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16
10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8
Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254,
тогда добавим новый Acl (см. таблицу N1):
acl LocalNet src 192.168.0.0/24
Предположим, что у Вас прокси сервер Squid расположен по адресу
192.168.0.200 на порту 3128, тогда пишем в файле конфигурации:
http_port 192.168.0.200:3128
Следующим нашим действием будет запрет использования нашего прокси
сервера, кроме как пользователями нашей локальной сети:
http_access allow LocalNet
http_access deny all
В данном случае слово allow является разрешением, а слово deny
запрещением, то есть мы разрешаем доступ к прокси серверу Squid с
адресов нашей локальной сети и запрещаем доступ всем остальным.
Будьте внимательны, указывая http_access, так как Squid использует их в
порядке указания Вами.
ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)
Система управления доступом в прокси сервере Squid является очень гибкой
и обширной. Она состоит из элементов со значениями и списков доступа c
указанием allow (разрешение) или deny (запрещение).
Формат Acl следующий:
acl имя элемент список
Формат списка доступа:
http_access указание имя_acl
Мы рассмотрим некоторые элементы, которые позволяет использовать прокси
сервер Squid, конечно же с примерами:
* acl имя src список
С помощью этого элемента (src) мы указываем IP-адрес источника, то есть
клиента от которого пришел запрос к нашему прокси серверу.
В следующем примере мы разрешим Васе Пупкину (Pupkin) и отделу
программирования (Progs) доступ к нашему прокси серверу, а всем
остальным запретим:
acl Progs src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
http_access allow Progs
http_access allow Pupkin
http_access deny all
* acl имя dst список
Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес
того сервера, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к
примеру, в ней находится тот же aport.ru):
acl Net194 dst 194.67.0.0/16
http_access deny Pupkin Net194
* acl имя dstdomain список
С помощью этого элемента (dstdomain) мы указываем домен, доступ к
которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и
kpnemo.ru:
acl SitesWarez dstdomain .nnm.ru .kpnemo.ru
http_access deny Pupkin SitesWarez
В случае, если будет необходимо указать домен источника, то используйте
srcdomain.
* acl имя [-i] srcdom_regex список
* acl имя [-i] dstdom_regex список
Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них
используются регулярные выражения, которые в данной статье мы не
рассматриваем, но пример всё-таки приведём:
Acl SitesRegexSex dstdom_regex sex
Acl SitesRegexComNet dstdom_regex \.com$ \.net$
http_access deny Pupkin SitesRegexSex
http_access deny Pupkin SitesRegexComNet
В данном примере мы запретили доступ Пупкину Василию на все домены,
содержащие слово sex и на все домены в зонах .com и .net.
Ключ -i призван игнорировать регистр символов в регулярных выражениях.
* acl имя [-i] url_regex список
С помощью этого элемента (url_regex) мы указываем шаблон регулярного
выражения для URL.
Пример указания файлов с расширением avi, начинающихся на слово sex:
acl NoAviFromSex url_regex -i sex.*\.avi$
В случае, если Вы желаете указать шаблон только для пути URL, то есть
исключая протокол и имя хоста (домена), то используйте urlpath_regex.
Пример для указания музыкальных файлов:
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
* acl имя_acl port список
Указание номера порта назначения, то есть порта, к которому желает
подключится клиент нашего прокси сервера.
Как пример, запретим всем использование программы Mirc через наш прокси
сервер:
Acl Mirc port 6667-6669 7770-7776
http_access deny all Mirc
* acl имя_acl proto список
Указание протокола передачи.
Как пример, запретим вышеупомянутому Васе использование протокола FTP
через наш прокси сервер:
acl ftpproto proto ftp
http_access deny Pupkin ftpproto
* acl имя_acl method список
Указание метода http запроса клиентом (GET, POST).
Возьмем ситуацию, когда следует запретить Васе Пупкину просматривать его
почту на сайте mail.ru, но при этом разрешить прогуливаться по сайту без
запретов, то есть запретить Васе возможность войти в свой почтовый ящик
через форму входа на сайте:
acl SiteMailRu dstdomain .mail.ru
acl methodpost method POST
http_access deny Pupkin methodpost SiteMailRu
ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Достаточно часто в нашей стране возникает ситуация, что канала доступа в
глобальную сеть Интернет на всех пользователей не хватает и возникает
желание дать каждому по максимуму, но при этом не дать каналу
"загнуться" из-за любителей позагружать файлы.
Средства прокси-сервера Squid позволяют этого добится несколькими путями:
- первый путь это оптимизация кеширования объектов;
- второй - это ограничение по времени определенных пользователей, что не
совсем корректно;
- третий путь заключается в ограничении скорости для определенных типов
файлов, пользователей и всего того, что определено нами через Acl.
ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ
Ограничить пользователей по времени можно следующим образом:
acl имя time дни чч:мм-ЧЧ:ММ
Где день: M - Понедельник, T - Вторник, W - Среда, H - Четверг, F -
Пятница, A - Суббота, S - Воскресенье.
При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с
00:00-23:59, но нельзя указать 20:00-09:00.
Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до
15 часов каждый день:
acl TimePupkin time 10:00-15:00
http_access deny Pupkin TimePupkin
Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14
часов, то пишем:
acl TimePupkin time 13:00-14:00
http_access allow Pupkin TimePupkin Mirc
http_access deny Pupkin Mirc
А что делать, если необходимо запретить или разрешить в определенные дни
недели? Squid также позволяет это сделать, к примеру с 13 до 14 в
понедельник и в воскресенье:
acl TimePupkin time MS 13:00-14:00
Как видите, ничего сложного в этом нет.
ОГРАНИЧЕНИЯ ПО СКОРОСТИ
Регулировка скорости в прокси сервере Squid осуществляется с помощью
пулов. Пул - это своего рода бочонок с пивом, в который пиво постоянно
заливают до краёв, а клиенты наливают в свои стаканы или иные ёмкости
для дальнейшего внутреннего потребления по мере надобности через свои
персональные краны.
Пулы регулируются с помощью трех параметров: delay_class,
delay_parameters, delay_access. Количество пулов указывается с помощью
параметра delay_pools.
Пулы могут быть трёх классов:
1. Весь поток пива ограничен одним краном (на всю сеть).
2. Весь поток пива ограничен одним краном, но при этом кран делится
на подкранчики (на каждый IP).
3. Весь поток пива ограничен одним краном, но кран делится на
подкранчики (на подсети), которые также делятся на мини кранчики (на
каждый IP).
Форматы:
delay_pools количество_объявленных_пулов
delay_access номер_пула действие имя_acl
действие может быть allow (разрешить) и deny (запретить). При этом,
данный пул действует на тех, кому он разрешен и не действует на тех,
кому он запрещен. В случае, если указано allow all, а затем deny Pupkin,
то на Пупкина данный класс всё-равно подействует, т.к. IP-адрес Пупкина
объявленный в acl Pupkin, входит в список адресов acl all. Имейте это
ввиду.
delay_class номер_пула класс_пула
delay_parameters номер_пула параметры
параметры отличаются в зависимости от класса пула:
для первого класса:
delay_parameters 1 байт_на_всю_сеть
для второго класса:
delay_parameters 1 на_всю_сеть на_клиента
для третьего класса:
delay_parameters 1 на_всю_сеть на_подсеть на_клиента
Для примера, у нас канал на 128 Кбит (в среднем 15 Кбайт в секунду) и мы
желаем Васе (Pupkin) дать всего 4 Кбайта/сек (на все про всё один
маленький бокальчик), отделу программирования (Prog) дать всего 10
Кбайт/сек и на каждого всего по 5 Кб/сек (всего два бокальчика), всех
остальных ограничить в 2 Кбайта/сек на каждого и 10 Кб/сек на всех, а
файлы mp3 (media) ограничить в 3 Кбайта в секунду на всех (на всю бочку
пива такой маленький кран). Тогда пишем:
acl Prog src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
acl LocalNet src 192.168.0.0/255.255.255.0
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
delay_pools 4
# сначала ограничим mp3
delay_class 1 1
delay_parameters 1 3000/3000
delay_access 1 allow media
delay_access 1 deny all
# ограничим бедного Васю
delay_class 2 1
delay_parameters 2 4000/4000
delay_access 2 allow Pupkin
delay_access 2 deny all
# ограничим отдел программирования
delay_class 3 2
delay_parameters 3 10000/10000 5000/5000
delay_access 3 allow Prog
delay_access 3 deny all
# а теперь ограничим остальных (второй класс пула)
delay_class 4 2
delay_parameters 4 10000/10000 2000/2000
delay_access 4 deny media
delay_access 4 deny Pupkin
delay_access 4 deny Prog
delay_access 4 allow LocalNet
delay_access 4 deny all
Часто возникает вопрос, а как лучше всего использовать столь малый
канал, чтобы он автоматически делился между всеми теми, кто в данный
момент что-либо загружает? На этот вопрос имеется однозначный ответ -
средствами прокси сервера Squid этого сделать не возможно, но всё-таки
кое-что предпринять можно:
delay_class 1 2
delay_parameters 1 -1/-1 5000/15000
delay_access 1 allow LocalNet
delay_access 1 deny all
Таким образом мы выделяем на всю нашу сеть и на подсети максимальный
канал (-1 означает неограниченность), а каждому пользователю даем
скорость максимум в 5 Кб/сек после того, как он скачает на максимальной
скорости первые 15 Кбайт документа.
Таким образом клиент не съест весь канал, но достаточно быстро получит
первые 15 Кбайт.
ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID
-----------------------------------------
Существует множество типов файлов, которые обновляются не достаточно
часто, чтобы позволить прокси серверу реагировать на заголовки от
вебсерверов о том, что данный объект не подлежит кешированию либо он был
на удивление только что изменён. Это довольно частая ситуация.
Для разрешения таких ситуаций призван параметр refresh_pattern в файле
настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его
рассматривать не будем.
Формат:
refresh_pattern [-i] строка МИНВ процент МАКСВ параметры
Данный параметр используется для того, чтобы определить возраст объекта
(считайте файла) в кеше, следует ли его обновлять или нет.
МИНВ (минимальное время) - время в минутах, когда объект, имеющийся в
кеше считается свежим.
МАКСВ (максимальное время) - максимальное время в минутах, когда объект
считается свежим.
Параметры - это один или несколько следующих параметров:
- override-expire - игнорировать информацию об истечении свежести объекта
и использовать МИНВ.
- override-lastmod - игнорировать информацию о дате изменения файла и
использовать МИНВ.
- reload-into-ims - вместо запроса клиентского запроса "не кешировать
документы" (no-cache) посылать запрос "Если изменен с"
(If-Modified-Since)
- ignore-reload - игнорировать запросы клиентов "не кешировать документы"
(no-cache) или "перезагрузить документ" (reload).
И так, мы подошли к самом главному. Ну, так какие же типы файлов реже
всех обновляются? Как правило, это разнообразные музыкальные файлы и
картинки.
Установим свежесть объектов, для этого для картинок и музыкальных файлов
укажем, скажем так для примера, целых 30 дней (43200 минут):
refresh_pattern -i \.gif$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.png$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpeg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.pdf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.zip$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tar$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.gz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tgz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.exe$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.prz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.ppt$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.inf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.swf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mid$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.wav$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mp3$ 43200 100% 43200 override-lastmod override-expire
Показанные Выше настройки лишь пример, для того, чтобы была понятна
суть.
Теперь можете проверить эффективность своего прокси сервера, она уж
точно возрастет.
ЗАКЛЮЧЕНИЕ
Прокси сервер Squid не является одним лишь распространенным прокси
сервером, существуют и другие. Но как показывает статистика, большинство
используют именно этот прокси сервер, но при этом всё равно у многих
начинающих возникают проблемы с настройкой.
С помощью этой статьи я попытался хоть немного раскрыть для обширных
масс некоторые функции прокси сервера Squid.
Джерело: http://www.opennet.ru/base/net/squid_inst.txt.html
Date: Fri, 14 Jan 2005 15:04:58 +0500 (YEKT)
Subject: Настройка Squid для начинающих
Настройка Squid для чайников
(версия статьи 1.0 от 29.10.2004)
Забудкин Лев Мирославович,
Россия, Тюменская область,
Г. Нижневартовск,
ведущий программист
МУ "Библиотечная-информационная система"
zabudkin@mail.ru
http://zabudkin.com
ВСТУПЛЕНИЕ
Многие администраторы сталкиваются с проблемой разумного использования
времени и канала для выхода в сеть Интернет, задумываются о возможности
экономии времени и денег, об ограничении скорости для отдельных видов
файлов или личностей, в конце концов об экономии всего, что связано с
теми или иными аспектами выхода в глобальную сеть.
Я, с помощью этой статьи, попытаюсь наглядно и доходчиво объяснить о
настройках самого распространенного прокси сервера - прокси
сервера Squid.
НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ
Мы не будем вдаваться в процесс установки прокси сервера Squid, а
перейдем сразу к его настройке.
Самое элементарное, что нам после установки следует сделать, так это
разрешить доступ пользователям нашей локальной сети. Для этого служат
параметры http_port, http_access. Кроме этого, мы заведем acl (список
контроля доступа) для нашей локальной сети.
И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid
должен обслуживать только компьютеры нашей локальной сети и быть
невидимым для внешнего мира, дабы исключить возможность "плохим
людям" внешней сети воспользоваться нашим каналом или трафиком, а
в случае, если будут обнаружены "дыры" в коде прокси сервера
Squid, воспользоваться ими.
Параметр http_access используется для разрешения или запрещения доступа
к определенным ресурсам, определенным адресам либо с определенных
адресов, к определенным сайтам, по определенным протоколам, портам и
всему тому, что непосредственно указано с помощью Acl (списков контроля
доступа).
Таблица N 1. Некоторые подсети.
|Диапазон адресов |Полная форма |Краткая форма
192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24
192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24
192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16
10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8
Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254,
тогда добавим новый Acl (см. таблицу N1):
acl LocalNet src 192.168.0.0/24
Предположим, что у Вас прокси сервер Squid расположен по адресу
192.168.0.200 на порту 3128, тогда пишем в файле конфигурации:
http_port 192.168.0.200:3128
Следующим нашим действием будет запрет использования нашего прокси
сервера, кроме как пользователями нашей локальной сети:
http_access allow LocalNet
http_access deny all
В данном случае слово allow является разрешением, а слово deny
запрещением, то есть мы разрешаем доступ к прокси серверу Squid с
адресов нашей локальной сети и запрещаем доступ всем остальным.
Будьте внимательны, указывая http_access, так как Squid использует их в
порядке указания Вами.
ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)
Система управления доступом в прокси сервере Squid является очень гибкой
и обширной. Она состоит из элементов со значениями и списков доступа c
указанием allow (разрешение) или deny (запрещение).
Формат Acl следующий:
acl имя элемент список
Формат списка доступа:
http_access указание имя_acl
Мы рассмотрим некоторые элементы, которые позволяет использовать прокси
сервер Squid, конечно же с примерами:
* acl имя src список
С помощью этого элемента (src) мы указываем IP-адрес источника, то есть
клиента от которого пришел запрос к нашему прокси серверу.
В следующем примере мы разрешим Васе Пупкину (Pupkin) и отделу
программирования (Progs) доступ к нашему прокси серверу, а всем
остальным запретим:
acl Progs src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
http_access allow Progs
http_access allow Pupkin
http_access deny all
* acl имя dst список
Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес
того сервера, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к
примеру, в ней находится тот же aport.ru):
acl Net194 dst 194.67.0.0/16
http_access deny Pupkin Net194
* acl имя dstdomain список
С помощью этого элемента (dstdomain) мы указываем домен, доступ к
которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и
kpnemo.ru:
acl SitesWarez dstdomain .nnm.ru .kpnemo.ru
http_access deny Pupkin SitesWarez
В случае, если будет необходимо указать домен источника, то используйте
srcdomain.
* acl имя [-i] srcdom_regex список
* acl имя [-i] dstdom_regex список
Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них
используются регулярные выражения, которые в данной статье мы не
рассматриваем, но пример всё-таки приведём:
Acl SitesRegexSex dstdom_regex sex
Acl SitesRegexComNet dstdom_regex \.com$ \.net$
http_access deny Pupkin SitesRegexSex
http_access deny Pupkin SitesRegexComNet
В данном примере мы запретили доступ Пупкину Василию на все домены,
содержащие слово sex и на все домены в зонах .com и .net.
Ключ -i призван игнорировать регистр символов в регулярных выражениях.
* acl имя [-i] url_regex список
С помощью этого элемента (url_regex) мы указываем шаблон регулярного
выражения для URL.
Пример указания файлов с расширением avi, начинающихся на слово sex:
acl NoAviFromSex url_regex -i sex.*\.avi$
В случае, если Вы желаете указать шаблон только для пути URL, то есть
исключая протокол и имя хоста (домена), то используйте urlpath_regex.
Пример для указания музыкальных файлов:
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
* acl имя_acl port список
Указание номера порта назначения, то есть порта, к которому желает
подключится клиент нашего прокси сервера.
Как пример, запретим всем использование программы Mirc через наш прокси
сервер:
Acl Mirc port 6667-6669 7770-7776
http_access deny all Mirc
* acl имя_acl proto список
Указание протокола передачи.
Как пример, запретим вышеупомянутому Васе использование протокола FTP
через наш прокси сервер:
acl ftpproto proto ftp
http_access deny Pupkin ftpproto
* acl имя_acl method список
Указание метода http запроса клиентом (GET, POST).
Возьмем ситуацию, когда следует запретить Васе Пупкину просматривать его
почту на сайте mail.ru, но при этом разрешить прогуливаться по сайту без
запретов, то есть запретить Васе возможность войти в свой почтовый ящик
через форму входа на сайте:
acl SiteMailRu dstdomain .mail.ru
acl methodpost method POST
http_access deny Pupkin methodpost SiteMailRu
ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Достаточно часто в нашей стране возникает ситуация, что канала доступа в
глобальную сеть Интернет на всех пользователей не хватает и возникает
желание дать каждому по максимуму, но при этом не дать каналу
"загнуться" из-за любителей позагружать файлы.
Средства прокси-сервера Squid позволяют этого добится несколькими путями:
- первый путь это оптимизация кеширования объектов;
- второй - это ограничение по времени определенных пользователей, что не
совсем корректно;
- третий путь заключается в ограничении скорости для определенных типов
файлов, пользователей и всего того, что определено нами через Acl.
ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ
Ограничить пользователей по времени можно следующим образом:
acl имя time дни чч:мм-ЧЧ:ММ
Где день: M - Понедельник, T - Вторник, W - Среда, H - Четверг, F -
Пятница, A - Суббота, S - Воскресенье.
При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с
00:00-23:59, но нельзя указать 20:00-09:00.
Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до
15 часов каждый день:
acl TimePupkin time 10:00-15:00
http_access deny Pupkin TimePupkin
Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14
часов, то пишем:
acl TimePupkin time 13:00-14:00
http_access allow Pupkin TimePupkin Mirc
http_access deny Pupkin Mirc
А что делать, если необходимо запретить или разрешить в определенные дни
недели? Squid также позволяет это сделать, к примеру с 13 до 14 в
понедельник и в воскресенье:
acl TimePupkin time MS 13:00-14:00
Как видите, ничего сложного в этом нет.
ОГРАНИЧЕНИЯ ПО СКОРОСТИ
Регулировка скорости в прокси сервере Squid осуществляется с помощью
пулов. Пул - это своего рода бочонок с пивом, в который пиво постоянно
заливают до краёв, а клиенты наливают в свои стаканы или иные ёмкости
для дальнейшего внутреннего потребления по мере надобности через свои
персональные краны.
Пулы регулируются с помощью трех параметров: delay_class,
delay_parameters, delay_access. Количество пулов указывается с помощью
параметра delay_pools.
Пулы могут быть трёх классов:
1. Весь поток пива ограничен одним краном (на всю сеть).
2. Весь поток пива ограничен одним краном, но при этом кран делится
на подкранчики (на каждый IP).
3. Весь поток пива ограничен одним краном, но кран делится на
подкранчики (на подсети), которые также делятся на мини кранчики (на
каждый IP).
Форматы:
delay_pools количество_объявленных_пулов
delay_access номер_пула действие имя_acl
действие может быть allow (разрешить) и deny (запретить). При этом,
данный пул действует на тех, кому он разрешен и не действует на тех,
кому он запрещен. В случае, если указано allow all, а затем deny Pupkin,
то на Пупкина данный класс всё-равно подействует, т.к. IP-адрес Пупкина
объявленный в acl Pupkin, входит в список адресов acl all. Имейте это
ввиду.
delay_class номер_пула класс_пула
delay_parameters номер_пула параметры
параметры отличаются в зависимости от класса пула:
для первого класса:
delay_parameters 1 байт_на_всю_сеть
для второго класса:
delay_parameters 1 на_всю_сеть на_клиента
для третьего класса:
delay_parameters 1 на_всю_сеть на_подсеть на_клиента
Для примера, у нас канал на 128 Кбит (в среднем 15 Кбайт в секунду) и мы
желаем Васе (Pupkin) дать всего 4 Кбайта/сек (на все про всё один
маленький бокальчик), отделу программирования (Prog) дать всего 10
Кбайт/сек и на каждого всего по 5 Кб/сек (всего два бокальчика), всех
остальных ограничить в 2 Кбайта/сек на каждого и 10 Кб/сек на всех, а
файлы mp3 (media) ограничить в 3 Кбайта в секунду на всех (на всю бочку
пива такой маленький кран). Тогда пишем:
acl Prog src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
acl LocalNet src 192.168.0.0/255.255.255.0
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
delay_pools 4
# сначала ограничим mp3
delay_class 1 1
delay_parameters 1 3000/3000
delay_access 1 allow media
delay_access 1 deny all
# ограничим бедного Васю
delay_class 2 1
delay_parameters 2 4000/4000
delay_access 2 allow Pupkin
delay_access 2 deny all
# ограничим отдел программирования
delay_class 3 2
delay_parameters 3 10000/10000 5000/5000
delay_access 3 allow Prog
delay_access 3 deny all
# а теперь ограничим остальных (второй класс пула)
delay_class 4 2
delay_parameters 4 10000/10000 2000/2000
delay_access 4 deny media
delay_access 4 deny Pupkin
delay_access 4 deny Prog
delay_access 4 allow LocalNet
delay_access 4 deny all
Часто возникает вопрос, а как лучше всего использовать столь малый
канал, чтобы он автоматически делился между всеми теми, кто в данный
момент что-либо загружает? На этот вопрос имеется однозначный ответ -
средствами прокси сервера Squid этого сделать не возможно, но всё-таки
кое-что предпринять можно:
delay_class 1 2
delay_parameters 1 -1/-1 5000/15000
delay_access 1 allow LocalNet
delay_access 1 deny all
Таким образом мы выделяем на всю нашу сеть и на подсети максимальный
канал (-1 означает неограниченность), а каждому пользователю даем
скорость максимум в 5 Кб/сек после того, как он скачает на максимальной
скорости первые 15 Кбайт документа.
Таким образом клиент не съест весь канал, но достаточно быстро получит
первые 15 Кбайт.
ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID
-----------------------------------------
Существует множество типов файлов, которые обновляются не достаточно
часто, чтобы позволить прокси серверу реагировать на заголовки от
вебсерверов о том, что данный объект не подлежит кешированию либо он был
на удивление только что изменён. Это довольно частая ситуация.
Для разрешения таких ситуаций призван параметр refresh_pattern в файле
настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его
рассматривать не будем.
Формат:
refresh_pattern [-i] строка МИНВ процент МАКСВ параметры
Данный параметр используется для того, чтобы определить возраст объекта
(считайте файла) в кеше, следует ли его обновлять или нет.
МИНВ (минимальное время) - время в минутах, когда объект, имеющийся в
кеше считается свежим.
МАКСВ (максимальное время) - максимальное время в минутах, когда объект
считается свежим.
Параметры - это один или несколько следующих параметров:
- override-expire - игнорировать информацию об истечении свежести объекта
и использовать МИНВ.
- override-lastmod - игнорировать информацию о дате изменения файла и
использовать МИНВ.
- reload-into-ims - вместо запроса клиентского запроса "не кешировать
документы" (no-cache) посылать запрос "Если изменен с"
(If-Modified-Since)
- ignore-reload - игнорировать запросы клиентов "не кешировать документы"
(no-cache) или "перезагрузить документ" (reload).
И так, мы подошли к самом главному. Ну, так какие же типы файлов реже
всех обновляются? Как правило, это разнообразные музыкальные файлы и
картинки.
Установим свежесть объектов, для этого для картинок и музыкальных файлов
укажем, скажем так для примера, целых 30 дней (43200 минут):
refresh_pattern -i \.gif$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.png$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpeg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.pdf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.zip$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tar$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.gz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tgz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.exe$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.prz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.ppt$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.inf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.swf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mid$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.wav$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mp3$ 43200 100% 43200 override-lastmod override-expire
Показанные Выше настройки лишь пример, для того, чтобы была понятна
суть.
Теперь можете проверить эффективность своего прокси сервера, она уж
точно возрастет.
ЗАКЛЮЧЕНИЕ
Прокси сервер Squid не является одним лишь распространенным прокси
сервером, существуют и другие. Но как показывает статистика, большинство
используют именно этот прокси сервер, но при этом всё равно у многих
начинающих возникают проблемы с настройкой.
С помощью этой статьи я попытался хоть немного раскрыть для обширных
масс некоторые функции прокси сервера Squid.
Джерело: http://www.opennet.ru/base/net/squid_inst.txt.html
Підписатися на:
Дописи (Atom)