Есть Cisco ASA, которая обеспечивает доступ в интернет предприятию. С
версии 7.2 можно использовать WCCP.
WCCP это цисковский протокол, который используется для web кеширования,
как следствие мониторинг всех web-обращений пользователей.
Перенаправлять буду на squid, установленный на FreeBSD.
Сама настройка Cisco ASA 5520 сводится к минимум двум командам, это
собственно активация wccp web-cache и привязыка интерфейса с которого
будет перенаправляться трафик на внешний прокси сервер (в нашем случае
Squid 2.6)
ciscoasa(config)# wccp web-cache
ciscoasa(config)# wccp interface inside web-cache redirect in
Если нам нужно явно указать кого нам форвардить на cache сервер, а кого
нет, делается это с помощью redirect-list
Для начала создадим тот самый лист:
В режиме глобальной конфигурации:
access-list WCCP deny ip host 10.0.0.10 any
access-list WCCP extended permit ip 10.0.0.0 255.255.255.0 any
Затем этот лист применить для WCCP
wccp web-cache redirect-list WCCP
Таким образом, мы создали редирект лист, в котором запрещаем
перенаправлять на cache сервер пришедшее с хоста 10.0.0.10 (т.е. всё
будет ходить напрямую), а всех остальных пожалуй будем пропускать через
в нашем случае squid 🙂
http://cisco.com/en/US/docs/security/asa/asa72/configuration/guide/dhcp.html
Сама настройка сквида заключается в изменении нескольких директив
http_port 127.0.0.1:3128 transparent
директива которая отвечает за установление прозрачного проксирования,
благодаря ей мы можем заворачивать web-трафик, пришедший к нам на
FreeBSD через ipfw fwd (об этом чуть ниже).
wccp2_router 10.0.0.1
Указываем IP-адрес Inside нашей ASA.
wccp2_forwarding_method 1
wccp2_return_method 1
wccp2_service standard 0
Директивы отвечающие за связь с wccp cisco ASA и за то, что будет
применяться wccp версии 2.
Больше настройка squid’а ничем не отличается, от обычной его найтройки
(т.е. без использования wccp).
Так же прописываются ACL для наших пользователе.
Для обеспечения работы ASA и FreeBSD + Squid необходимо создать gre
интерфейс, по которому и будет работать наше перенаправление трафика.
/sbin/ifconfig gre0 plumb
/sbin/ifconfig gre0 link2
/sbin/ifconfig gre0 tunnel 10.0.0.1 IP_OUTSIDE
/sbin/ifconfig gre0 inet 1.1.1.1 1.1.1.2
это можно прописать в /etc/rc.conf или /etc/rc.local. rc.conf предпочтительнее.
проверяем:
gre0: flags=f051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,LINK2,MULTICAST> mtu 1476
tunnel inet 10.0.0.6 —> IP_OUTSIDE
inet 1.1.1.1 —> 1.1.1.2 netmask 0xff000000
Теперь нам нужно настроить форвард всего приходящего на сервер www
трафика от wccp на squid, делается это с помощью ipfw
ipfw add fwd 127.0.0.1,3128 tcp from any to any dst-port 80 recv gre0
Проверим всё ли нормально на Cisco ASA.
ciscoasa# sh wccp
Global WCCP information:
Router information:
Router Identifier: IP_OUTSIDE
Protocol Version: 2.0Service Identifier: web-cache
Number of Cache Engines: 1
Number of routers: 1
Total Packets Redirected: 228325
Redirect access-list: -none-
Total Connections Denied Redirect: 0
Total Packets Unassigned: 165
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
ciscoasa#Total Packets Redirected: 228325 — значение растёт,значит кто-то уже идет по 80 порту нарушу, соответсвенно редиректится.
ciscoasa# sh wccp web-cache detail
WCCP Cache-Engine information:
Web Cache ID: 10.0.0.6
Protocol Version: 2.0
State: Usable
Initial Hash Info: 00000000000000000000000000000000
00000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%)
Packets Redirected: 228784
Connect Time: 03:29:53
ciscoasa#
10.0.0.6 — это адрес нашего сервера, на котором установлен squid.
можно посмотреть debug, как общаются между собой Cisco ASA и Squid.
ciscoasa# debug wccp packets
WCCP-PKT:S00: Received valid Here_I_Am packet from 10.0.0.6 w/rcv_id 00001FB9
WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.6 w/ rcv_id 00001FBA
WCCP-PKT:S00: Received valid Here_I_Am packet from 10.0.0.6 w/rcv_id 00001FBA
WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.6 w/ rcv_id 00001FBB
Всё хорошо, устройства друг друга видят. Т.е. по сути это обычные
keepalive пакеты, т.е. проверка на живучесть друг друга.
Если Squid вдруг падает, то перенаправление на него производиться не
будет, и пользователи продолжат работать.
Теперь посмотрим, доходят ли пакеты до нашего сервера, для этого
посмотрим счётчик пакетов правила fwd
bsd# ipfw show
00101 225034 30895608 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 recv gre0
Пакеты форварадятся, всё хорошо.
Для удобного просмотра статистики, кто куда ходит в рабочее время можно
использовать множество утилит, например sarg,sams, lightsquid.
Все эти утилиты доступны из портов FreeBSD /usr/ports/www/
Я выбрал для себя lightsquid
Установка не отличается ничем от других приложений, в самом общем виде:
cd /usr/ports/www/lightsquid ; make && make install clean
после установки в /usr/local/www/lightsquid появятся нужные нам скрипты.
Прописываем соответсвенно эту директорию в свой https.conf (в корень,
или виртуальный хост, у кого как всё это организовывается). Настройка
apache выходит за пределы этой статьи.
Необходимо лишь к apache привязать mod_perl и дать разрешение на запуск
cgi скриптов, например таким образом
<Directory «/usr/local/www/lightsquid»>
AddHandler cgi-script .cgi
AllowOverride All
</Directory>
Настройка самого lightsquid заключается в прописывании правильных путей
где находится access.log нашего squid’а, который собственно и будем
анализировать.
Файлы настроек лежат по умолчанию: /usr/local/etc/lightsquid/
Основой файл lightsquid.conf. В самом простом случае, требуется
подкорректировать только его.
Для проверки, правильно ли настроили lightsquid запустим перл скрипт
/usr/local/www/lightsquid/lightparser.pl
Если всё нормально, создастся report, которые будут видны через web.
При правильной настройке, при запуске lightparser.pl появиться в консоли
ничего не должно.
Теперь сделаем, чтоб отчёт автоматически формировался, скажем какждые 30
минут. Для этого пропишем запуск скрипта в /etc/crontab следующим
образом:
*/30 * * * * root /usr/local/www/lightsquid/lightparser.pl today
Наверняка захочется сделать ограничение на посещение различных сайтов
клиентами, для этого можно использовать так же множество программ, самые
известные это: squidGuard и rejik.
Я отдал предпочтение squidGuard, выбор зависит от религиозных убеждений.
squidGuard так же есть в портах: /usr/ports/www/squidguard/
Устанавливается по уже вышеописанным правилам.
После установки, все файлы конфигурации будут находиться в уже известном
нам пути: /usr/local/etc/squid
Основной файл конфигурации squidGuard.conf.sample, который мы скопируем
в squidGuard.conf, которым и будем пользоваться в дальнейшем.
В этом файле описываются группы пользователей, т.е. можно создать кучу
групп, одной из которых запретить только порнографию, другое скачивание
аудио и видео, а другой, скажем начальству разрешить всё. Подробно
останавливаться на данной конфигурации не буду, всё доступно на
официальном сайте: http://squidguard.com
Теперь необходимо указать squid’у, что посещаемые сайты необходимо
проверять squidguard’ом. В версии 2.6 в отличии от 2.5 это делается
следующим образом:
url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/etc/squid/squidGuard.conf
указываем непосредсвенно как запускать программу редиректа и с каким
конфигурационным файлом использовать
url_rewrite_children 3
запускаем три процесса редиректа squidguard’а
собтсвенно сами так называемые blacklist’ы сайтов, которые мы будем
запрещать можно скачать с того же squidguard.org.
В файле squidguard.conf укажем dbhome — путь к blacklis’у
Обновление blacklist можно автоматизировать простым скриптом, написанном
на perl,shell который будет скачивать каждую неделю файл, распаковывать,
перезаписывать и пересоздавать базы через squidGuard -C all, который
будет выполняться через тот же crontab.
После запуска squid (не забываем первый запуск squid’а делать с -z для
потроение всяких директорий для кеша). После запуска, смотрим что и как
у нас запустилось:
bsd# ps ax | grep squid
39796 ?? Is 0:00.00 /usr/local/sbin/squid -D
39798 ?? S 0:03.47 (squid) -D (squid)
39799 ?? Ss 0:06.86 (squidGuard) -c /usr/local/etc/squid/squidGuard.conf (squidGuard)
39800 ?? Ss 0:00.77 (squidGuard) -c /usr/local/etc/squid/squidGuard.conf (squidGuard)
39801 ?? Is 0:00.21 (squidGuard) -c /usr/local/etc/squid/squidGuard.conf (squidGuard)
41935 p0 R+ 0:00.00 grep squid
bsd#
Видим, что поднялся сам squid + 3 процесса squidguard (помним ту троечку
url_rewrite_children?). Всё хорошо.
И наконец посмотрим что есть в log-файле самого squidguard’а
bsd# tail /var/log/squidGuard.log
2008-02-28 12:52:21 [39801] init urllist /usr/local/etc/squid/db//violence/urls
2008-02-28 12:52:21 [39801] loading dbfile /usr/local/etc/squid/db//violence/urls.db
2008-02-28 12:52:21 [39801] init expressionlist /usr/local/etc/squid/db//violence/expressions
2008-02-28 12:52:21 [39801] init domainlist /usr/local/etc/squid/db//warez/domains
2008-02-28 12:52:21 [39801] loading dbfile /usr/local/etc/squid/db//warez/domains.db
2008-02-28 12:52:21 [39801] init urllist /usr/local/etc/squid/db//warez/urls
2008-02-28 12:52:21 [39801] loading dbfile /usr/local/etc/squid/db//warez/urls.db
2008-02-28 12:52:21 [39801] squidGuard 1.2.0 started (1204192341.404)
2008-02-28 12:52:21 [39801] recalculating alarm in 13059 seconds
2008-02-28 12:52:21 [39801] squidGuard ready for requests (1204192341.414)
bsd#
Вот и всё, squidguard готов получать себе запросы, и фильтровать
соответсвенно с настройками.
