Все записи автора KulMaks

Немного о Unifi. Запуск unifi controller в виде сервиса в win2k8r2. Фильтр мак-адресов.

Рано или поздно во всех компаниях возникает вопрос расширения зоны покрытия wi-fi сети. Самый просто вариант — покупаем еще одну точку доступа и создаем еще одну сеть. Вариант подходит тем, у кого все сотрудники «стационарны» и не перемещаются из зоны действия одной сети в другую.

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

Вариант третий: купить точки Ubiquiti UniFi. Их прелесть в том, что сами точки, по сути, просто передатчики. Вся логика вынесена в отдельную программу-контроллер, которая может быть установлена на windows, linux, mac os. Таким образом, расширяется сеть путем установки новых точек доступа и добавления их в контроллер.

Но если бы все было так просто, этой заметки не появилось бы в моем блоге. Всем админам хочется сделать систему максимально автономной и не требующей вмешательства в случае перезагрузок. По умолчанию, unifi controller запускается в виде обычного приложения. Т.е. после каждой перезагрузки, необходим ручной запуск — иначе новые устройства не смогут подключиться (старые будут работать). К счастью, производитель предусмотрел вариант запуска приложения в качестве сервиса. Согласно мануалу необходимо выполнить:

 1. Закройте UniFi, если он запущен.

2. Добавьте в переменную PATH путь к Java. Путь будет таким C:\Program Files (x86)\Java\jre6\bin или  C:\Program Files\Java\jre6\bin (либо jre7, в случае использования java 7).

3. Запустите с правами администратора командную строку (cmd.exe) и перейдите в директорию с файлами UniFi (cd «%userprofile%/Ubiquiti Unifi»).

4. Выполните java -jar lib\ace.jar installsvc

5. Запустите сервис.

А вот здесь, если у вас windows server 2008 r2, можно добавить пункт 6 — убедитесь, что сервис не стартует с «говорящей» ошибкой

The unifi controller service terminated with service-specific error: the operation completed successfully.

Проблема заключается в использовании 64-битной версии java. С ней запустить сервис, по какой-то причине, не удается. Для решения этой проблемы, необходимо доустановить jre x86 и изменить в переменной окружения PATH путь к java на директорию, содержащую версию x86 — C:\Program Files (x86)\Java\jre6\bin или C:\Program Files (x86)\Java\jre7\bin. После этого сервис запустится без ошибок.

Еще один вопрос, который может возникнуть — фильтрация MAC-адресов. Многие компании применяют этот метод в качестве одного из способов ограничения доступа в wi-fi сеть. По какой-то причине, разработчики UniFi не включили этот функционал в возможности контроллера. Но он доступен в виде дополнения от команды тестировщиков UniFi — unifi-lab-master.

Качаем дополнение, скачиваем Python 2.7 x86-64, если у вас windows x64  (не 3 ветку!), устанавливаем и добавляем в переменную PATH путь к нему — C:\Python27 по умолчанию. Качаем cURL с поддержкой SSL. Распаковываем его и кладем в директорию со скриптами unifi-lab. Редактируем, при необходимости, конфигурационный файл unifi_lab_production.ini и запускаем unifi_lab.py. В файл unifi_lab_mac_auth.list вносим мак-адреса устройств, которым разрешено подключение к сети (по одному в каждой строке). Файл перечитывается постоянно, поэтому изменения вступают в силу сразу после сохранения.

Для того, чтобы не запускать скрипт вручную, его можно конвертировать в exe при помощи py2exe. После этого создаем задание в планировщике на запуск программы при старте системы, настраиваем его на запуск вне зависимости от входа пользователя и снимаем галочку «Stop the task if it runs longer than 3 days».

Теперь перезагрузки будут не страшны — все запустится автоматически.

Уязвимость в XMLRPC WordPress, позволяющая использовать ваш сайт в DDoS-атаках

Внимание пользователям WordPress! Ваш сайт легко может стать частью ботнета, используемого для DDoS-атак. Вам для этого даже делать ничего не придется :)

Недавно была опубликована статья, в которой описывается довольно мощная атака с использованием сайтов под управлением WordPress. Атака стала возможной из-за включенного по умолчанию Pingback (механизма оповещения с других блогов). Для использования сайта в атаке, злоумышленнику достаточно обратиться к файлу xmlrpc.php и передать ему определенные параметры, которые включают в себя в том числе адрес атакуемого сайта. В ответ на этот запрос ваш сайт автоматически сформирует новый запрос к атакуемому сайту. Таким образом, рассылая «легкие» запросы на сотни или тысячи сайтов WordPress, можно добиться поступления запросов на атакуемый сервер с частотой сотен или тысяч запросов в секунду. Если нерадивый сисадмин не позаботился об ограничении количества одновременно обрабатываемых запросов на сервере — сервер просто-напросто перестанет отвечать.

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

Отключаем оповещения с других блогов:

Защита wordpress от xmlrpc

Отключаем оповещения для уже опубликованных записей:

Отключение оповещения для записей

Отключение оповещения для записей wordpress

После выставления этих настроек ваш сайт не сможет стать частью ботнета, а вы избежите отключения сайта хостером за превышение нагрузки :)

Tracert через Cisco ASA виндовым клиентом

В диагностике сетевых проблем сложно переоценить пользу такой простой утилиты как tracert (traceroute). Все мы знаем, что она в своей работе опирается на протокол icmp. И вполне логичным кажется обеспечение работы этого протокола на cisco asa путем «волшебного» inspect icmp. Однако, в случае с tracert это не помогает. Для ее нормального функционирования, необходимо разрешить на внешнем интерфейсе icmp типа time-exceeded от any к any:

access-list FROMOUTSIDE extended permit icmp any any time-exceeded
access-group FROMOUTSIDE in interface OUTSIDE

Только после этого вас ожидает полностью рабочий tracert.

Решение найдено здесь: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Приоритезация трафика voip и skype на cisco asa 5510 или как мы переходили на Cisco ASA — часть 3

При большом количестве людей и отсутствии нормального, полноценного PBR (policy-based routing) на cisco asa, каким-то образом необходимо уменьшить потенциальные «тормоза» в передаче звука и видео по скайпу с компьютеров в переговорных комнатах, а также звука с ip-телефонов. Обладатели cisco-роутеров удивятся «сложности» постановки задачи. В роутерах практически любой трафик можно выделять по протоколу (match protocol skype и др.). Но не тут-то было. ASA «знает» только самые распространенные протоколы типа http, ftp и др. Также, она умеет выделять трафик по регулярным выражениям, но описать регулярными выражениями трафик скайпа довольно сложно.

Решение, в общем-то, нашлось довольно быстро. С наших IP-телефонов никакой трафик кроме голосового идти не может, поэтому приоритет будет отдаваться всему трафику с их айпишников. Для упрощения дальнейшего администрирования, самый простой способ — добавить все эти адреса в object-group.

object-group network IPPHONES
network-object host 192.168.1.25
network-object host 192.168.1.26

Далее создаем access-list:

 access-list IPPHONES extended permit ip object-group IPPHONES any

Этот access-list мы используем в class-map:

class-map IPPHONES
match access-list IPPHONES

А class-map, в свою очередь, в policy-map:

policy-map LOCAL
 class IPPHONES
  priority

Таким образом, при дополнении этого policy-map политиками ограничения скорости для других типов трафика, мы отдадим приоритет исходящему трафику с телефонов.

С трафиком скайпа в переговорных комнатах можно поступить таким же образом (выдать приоритет всему трафику), но в нашем случае нашелся более изящный вариант. В переговорных комнатах установлены компьютеры под управлением ОС Windows и они входят в домен. При помощи групповых политик можно назначать значения DSCP трафику, генерируемому конкретными приложениями. Для этого надо создать новую политику QoS (Computer Configuration -> Windows Settings -> Policy-based QoS) в новом объекте (или в одном из существующих) групповой политики и назначить эту групповую политику на необходимый нам OU. В политике QoS необходимо выставить отличное от нуля (например, 1) значение DSCP для трафика TCP и UDP, генерируемого приложением skype.exe. После этого мы можем создать class-map для выделения этого трафика из потока:

class-map SKYPE
 match dscp 1

И добавить этот класс в наш policy-map:

policy-map LOCAL
 class SKYPE
  priority

И не забываем применять policy-map к интерфейсу:

 service-policy LOCAL interface LOCAL

В итоге мы получаем минимальные задержки для интересующего нас трафика довольно простыми методами.

Ограничение скорости интернета для пользователей на Cisco ASA 5510 или как мы переходили на Cisco ASA — часть 2

Итак, с PBR на Cisco ASA кое-как разобрались. Пришло время взяться за ограничение скорости для пользователей. На дебиане оно было реализовано просто и эффективно: при помощи iptables + htb у всех были выставлены минимальная (гарантированная) и максимальная скорость. Все были довольны, всем всего хватало. По необходимости, скорость конкретным пользователям весьма просто увеличивалась или уменьшалась.

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

Первый и, как мне кажется, более правильный способ — шейпинг трафика (traffic shaping). Его прелесть в том, что при превышении разрешенной скорости пакеты не отбрасываются, а по возможности складываются в буфер, откуда в дальнейшем отправляются в точку назначения. Это может вносить небольшие задержки (которые зависят от размера буфера и наличия высокоприоритетного трафика), но при этом мы можем отдавать приоритет определенному (например, голосовому) трафику и передавать его максимально быстро. Шейпинг трафика может быть применен только по отношению к исходящим пакетам.

Второй способ — traffic policing. Основное его отличие от шейпинга состоит в отсутствии буфера, т.е. «лишние» пакеты просто отбрасываются. Еще одним отличием от шейпинга является то, что он может применяться как к входящим пакетам, так и к исходящим. Несмотря на отсутствие буфера, приоритезация трафика возможна и в этом случае. Осуществляется она благодаря использованию очереди LLQ (Low-latency queuing). Отличие от шейпинга в данном случае состоит в том, что задержки для любого типа трафика будут ниже, но при этом возможность потери пакетов гораздо выше.

С точки зрения качества обслуживания, было бы неплохо использовать шейпинг трафика. Но тут кроется основная проблема: ASA умеет шейпить трафик только для class-default, т.е. весь трафик, да и то только исходящий. По сути, эта «фишка» реализована тут только для приближения скорости передаваемых данных к ширине канала — передать максимум, пусть и с задержками, потерять минимум.

Таким образом, ограничить входящую скорость всем и каждому мы можем только при помощи полисинга. При этом, если мы желаем ограничить скорость именно для каждого айпишника, нам придется создать по одному acl (access-list) на каждый адрес. Далее, для каждого acl необходимо создать class-map. Вот тут-то и кроется загвоздка. Общее количество class-map’ов в ASA ограничено числом 255. Если общее количество работников/серверов превышает это значение, то вы не сможете ограничить всех и каждого. Так или иначе придется разбивать всех по определенным группам и выставлять скорость уже для группы. При этом, естественно, любители скачивать торренты будут «отбирать» у группы больше скорости, чем было в случае iptables + htb — соответственно качество обслуживания остальных будет ниже.

Рассмотрим конкретный пример ограничения входящей скорости до 10 Мбит/с.

Создать access-list для интересующих нас адресов (сеть 192.168.1.0/24):

access-list LIMITED extended permit tcp any 192.168.1.0 255.255.255.0

Создать соответствующий class-map:

class-map LIMITED
match access-list LIMITED

Создать policy-map:

policy-map LIMITED
class LIMITED
police output 10000000

И применить его к интерфейсу локальной сети:

service-policy LIMITED interface LOCAL

Несколько пояснений по вышеуказанной конфигурации:

  • направление трафика output соответствует трафику, исходящему с интерфейса внутрь сети, т.е. в нашем случае это будет входящий трафик из интернета;
  • скорость для полисинга указывается в битах в секунду;
  • policy-map применяется для локального интерфейса, т.к. на внешнем интерфейсе у нас будут видны только адреса, которые прошли через NAT;

Такой вариант ограничения скорости может быть хорошим в том случае, если список адресов, у которых скорость ограничена всегда укладывается в одну подсеть или редко меняется. На практике такое встречается не часто и поэтому гораздо удобнее пользоваться группами объектов. В группы можно добавлять адреса по одному или целыми подсетями. При этом, два одинаковых адреса добавить не получится (чего не скажешь о двух одинаковых правилах access-list). Создадим группу и добавим в нее несколько хостов:

object-group network LIMITED
network-object host 192.168.1.5
network-object host 192.168.1.7
network-object host 192.168.1.8

Создадим access-list для этой группы:

access-list LIMITED extended permit tcp any object-group LIMITED

Если же нам необходимо исключить из полисинга какой-то трафик (к примеру, трафик DMZ-сети), то мы должны добавить соответствующий access-list с действием deny до этого правила. Выглядеть это будет примерно так (допустим, DMZ-сеть имеет адреса 192.168.15.0/24):

access-list LIMITED extended deny tcp 192.168.15.0 255.255.255.0 object group LIMITED
access-list LIMITED extended permit tcp any object-group LIMITED

После этого применим такие же class-map и policy-map, которые были рассмотрены выше и сохраним конфигурацию краткой командой wr. При необходимости, можно посмотреть статистику полисинга:

show service-policy police

Эта команда выведет данные по ограничению скорости для каждого class-map, перечисленного в policy-map.

На этом простая настройка ограничения скорости завершена.