ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘Новости’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

4 декабря прошел очередной (уже 10-ый) пиринговый форум MSK-IX.

Я был одним из участников данного форума, уже не впервый раз. Как и на других форумах MSK-IX были и интересные доклады и не очень.

Но и в этот раз не обошлось без тем о безопасности сетей и о DDoS. Что меня побудило на написание данной статьи ? Сейчас расскажу.

На данном форуме уже 3 доклада было посвящено данной проблеме, т.е. рост этой проблемы очевиден и чем дальше тем хуже. Я хочу обратить внимание на данную проблему не только тех кто присутствовал на данном мероприятии, но и остальных наших подписчиков.

Все мы сталкивались с проблемой DDoS`а, но далеко не все понимают, что она существует благодаря нам самим. Почему ?

Потому что не все, далеко не все, админы следуют, казалось бы простым, правилам и тем самым они, сами того не понимая, являются соучастниками DDoS атак, т.к. не делают ничего чтобы препятствовать им. Число Amplification атак растет как на дрожжах. Почему ? Да потому что реализация такой атаки проста. Они и далее будет расти, если ВЫ, уважаемый читатель, по прежнему будете бездействовать и рано или поздно это бездействие вернется к вам, как бумеранг.

Доклады (PDF версии докладов, а так же видео доступны тут):

Хорошие манеры или манифест устойчивой маршрутизации

(Докладчик: Андрей Робачевский Internet Society)

DDoS атаки: динамика за 2014 год

(Докладчик: Алексей Семеняка Qrator Labs)

Отражение DDoS-атак: защита CDN-трафика с CloudFlare

(Докладчик: Мартин Леви Cloudflare)

 

Давайте пройдемся по этим докладам и посмотрим какова ситуация по данной проблеме на текущий день.

Проект MANRS (Mutually Agreed Norms for Routing Security)

Простые правила:

  • Фильтрация BGP: Предотвращение распространения неправильной маршрутизационной информации
  • Анти-спуфинг: Предотвращение трафика с подложными IP-адресами
  • Содержание контактой и иной иформации в up-to-date: Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе

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

Хуже чем что ? Читаем далее.

Посмотрите на рост кол-ва атак:

ddos_1

А вот как вам такая картинка:

ddos_2

Россия даже Китай обогнала по кол-ву ботов…. а теперь задумайтесь насколько велика разница по кол-ву народа в Китае и в России.

Вам не обидно за державу ? Мне обидно.

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

ddos_3

Кол-во атак, из-за криво настроенной службы NTP, впереди планеты всей…. Хотя настройка службы NTP занимает не более 5 минут.

Смотрим во что все это выливается:

ddos_4

ddos_5

ddos_6

ddos_7

А теперь спросите себя: А вы хотите оказаться жертвой атаки в 400 Гбит/с ? Думаю что ответ будет «НЕТ!».

Ну и следующий вопрос, который стоит задать себе: А что лично Я сделал для того чтобы это остановить ?

Если ответ будет «ничего», то СРОЧНО приступите к тому, чтобы остановить ЭТО в подконтрольных вам сетях.

Для этого много не надо, как минимум:

  1. вы не должны выпускать НЕ свои IP-адреса из своей сети
  2. ваши DNS сервера не должны позволять рекурсию
  3. ваши NTP сервера должны быть настроены и не пропускать MONLIST
  4. ваша SNMP служба не имеет дефолтовых community public и private, а так же отвечат на запросы от НЕ ваших хостов
  5. если у вас есть BGP клиенты, то убедитесь что у вас есть BGP фильтры на анонсы от ваших клиентов и что они пропускают только префиксы вашего клиента

Что надо делать:

  1. На вашем Border`е (пограничный маршрутизатор вашей сети) зафильтровать все пакеты, где SRC IP не является IP-адресом из ваших подсетей.
  2. Настроить ваш DNS сервер, чтобы он выполнял рекурсивняе запросы только для IP-адресов из ваших подсетей.
  3. Настроить NTP службу.
  4. Настроить SNMP службу.
  5. Установить фильтры на анонсы подсетей ваших BGP клиентов.

Запрет рекурсии DNS  для bind и разрешение только вашим клиентам

acl "allow-recursion" {
        127.0.0.1;
        10.0.0.0/8;
        172.16.0.0/12;
        192.168.0.0/16;
        XXX.XXX.XXX.XXX/YY;
        ...
};
options {
        ...
        allow-recursion{ allow-recursion; };
        allow-query-cache{ allow-recursion; };
        ...
};

Либо полностью отключить возможность рекурсии, если этот DNS сервер используется только для резолва ваших доменов:

options {
        ... 
       recursion no;
       allow-query-cache{ none; };
       ...
}; 

Настройки для NTP службы

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict -6 ::1
# server(s) we time sync to
server 192.0.2.1
server 2001:db8::1
server time.example.net 

Вот ещё вариант конфига для NTP:

disable monitor
enable auth
# server(s) we time sync to
server 192.36.143.151
restrict 192.36.143.151 noquery notrap
server 195.66.241.10
restrict 195.66.241.10 noquery notrap
server 192.87.106.2
restrict 192.87.106.2 noquery notrap
server 145.238.203.14
restrict 145.238.203.14 noquery notrap

driftfile /var/db/ntp.drift

restrict 127.0.0.1
restrict XXX.XXX.XXX.XXX mask 255.255.YYY.ZZZ nomodify notrap
restrict default ignore

Где XXX.XXX.XXX.XXX это ваша IP-подсеть, а 255.255.YYY.ZZZ её маска.

Настройка SNMP службы

rocommunity MYCOMPANY-RO 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX
rwcommunity MYCOMPANY-RW 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX

Где XXX.XXX.XXX.XXX это доверенный хост в вашей сети. Так же вы можете просто запретить фаирволом обращение на порт UDP 161 для всех кроме ваших доверенных хостов.

Так же не стоит забывать о ваших пользователях,если они у вас есть, которые так же имеют реальные IP-адреса и которые в большинстве случаев вообще не понимают «как это работает», а значит они так же могут являться источниками для осуществления DDoS`а.

Вы можете проверить, подвержены ли вы уязвимостям и смогут ли вас использовать для осуществления DDoS атаки, используя команды:

DNS Amplifiers

# dig @ВАШ-IP-АДРЕС +edns=0 +ignore +noadflag com ANY

NTP Amplifiers

# ntpdc -nc monlist ВАШ-IP-АДРЕС

SNMP Amplifiers

# snmpbulkget -v2c -c public ВАШ-IP-АДРЕС 1.3

«Инструменты«, помимо ваших рук, которые вы можете использовать для поиска IP-адресов из вашей AS которые могут быть использованы в кач-ве усилителей атаки:

Посетите данные ресурсы, посмотрите что они покажут вам по вашим IP подсетям. Если результат не будет нулевым, то обязательно устраните все проблемы. Если вы этого не сделаете, то кто-то обязательно пострадает от DDoS`а, а вы можете стать следующим.

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

В противном случае данное ЗЛО будет только расти и приумножаться.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Всем трям !

После очередного взлома Asterisk`а клиента нашего клиента (простите за тавтологию :)) и отправки через него SIP вызовов на дорогие направления и данного топика на форуме мы снова между собой заговорили про давнюю идею…

Идея, которая сидит не только в наших головах, до которой пока ни у кого толком руки так не дошли…

Идея проста: для email есть тот же Spamcop, а для VoIP ? Хм… да ничего нету… И вот этот пробел хорошо бы устранить.

Что необходимо ?

Online сервис, в последствии распределенный сервис, который будет содержать список фродовых номеров и/или направлений и предоставлять возможность обращаться к нему за этим данными, например перед тем как разрешить совершение вызова.

Что это даст ?

Ну как минимум: клиенту это может сэкономить его деньги, а нам это даст сохранение клиента, своих нервов и попыток доказать клиенту, что его система все же совершала вызовы на дорогие направления.

Ведь наверняка и у вас было когда клиент говорил «это не мое !» и потом «тогда я отключаюсь от вас».

Так было принято решение: brain -> hands -> service 🙂

Встречайте пилотную версию нового проекта subnets.ru -> frod.subnets.ru

Надо же с чего то начинать.

Вот вкратце как предполагается  использовать и уже сейчас можно использовать:

Asterisk dialplan

DNS + ENUMLOOKUP

Пример контекста:

[tests]
exten => test,1,Set(DIAL=${ENUMLOOKUP(${EXTEN},,,,frod.subnets.ru.)})
exten => test,n,NoOp(${DIAL})
exten => test,n,GotoIf($["${DIAL}" = ""]?dial:frod)
exten => test,n(dial),NoOp(Dial(SIP/prov/${EXTEN},60,ti))
exten => test,n,Hangup
exten => test,n(frod),NoOp(Frod detected, skip dial)
exten => test,n,Hangup

В CLI Asterisk будет:

-- Executing [test@tests:1] Set("SIP/6003-000002b2", "DIAL=810972592132872@127.0.0.1") in new stack
-- Executing [test@tests:2] NoOp("SIP/6003-000002b2", "810972592132872@127.0.0.1") in new stack
-- Executing [test@tests:3] GotoIf("SIP/6003-000002b2", "0?dial:frod") in new stack
-- Goto (tests,test,6)
-- Executing [test@tests:6] NoOp("SIP/6003-000002b2", "Frod detected, skip dial") in new stack
-- Executing [test@tests:7] Hangup("SIP/6003-000002b2", "") in new stack

API Для тех кому нужно будет большее чем DNS запрос, будет доступно API:

Консоль

# nslookup 7781046406664700.frod.subnets.ru
Server: 91.217.137.1
Address: 91.217.137.1#53

Name: 7781046406664700.frod.subnets.ru
Address: 216.121.95.194

Вышеописанное уже есть на данный момент, а далее… далее очень много вопросов. Вопросов таких как:

  • получение данных извне
  • обработка данных (добавление номера в список, кол-во времени хранения и т.п.)
  •  удаление номера из базы извне

Это конечно не полный список вопросов, которые нужно решить и которые будут решаться. Если у вас есть данные о фродовых вызовах с ваших серверов/железа и вы готовы ими поделиться с остальными, то отправка этих данных нам приветствуется 🙂 Если у вас есть мысли, идеи, то они так же приветствуются. Можно написать тут в комментах, можно отправить на virus [СОБАЧКА-ГАВ-ГАВ] subnets.ru Пока нет логики обработки данных, то пока данные из базы будут представляться as-is.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Heartbleed OpenSSL Security Bug

Несколько дней назад обнаружили уязвимость в протоколе SSL.

CVE-2014-0160

Description

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

http://www.nixp.ru/news/12427.html

Уязвимость CVE-2014-0160, о которой стало официально известно 7 апреля, затрагивает последние релизы OpenSSL: стабильную 1.0.1 и бету 1.0.2-beta, которые, в частности, используются в актуальных версиях дистрибутивов GNU/Linux и других UNIX-подобных систем (например, Ubuntu 12.04 и 13.10, Fedora 18, CentOS 6.5, FreeBSD 8.4). Проблема в обработке памяти в расширении TLS heartbeat приводит к возможности получить данные, хранимые в OpenSSL, что несет серьезную угрозу конфиденциальности информации, передаваемой по зашифрованному каналу.

Проблему обнаружил Нил Мехта (Neel Mehta) из Google. Исправление уже доступно пользователям OpenSSL 1.0.1 в релизе 1.0.1g, а для бета-версии 1.0.2-beta будет представлено в 1.0.2-beta2. Всем пользователям OpenSSL 1.0.1 рекомендуется срочно обновиться до актуальной версии. Поставщики крупных Linux-дистрибутивов и других систем, использующих OpenSSL, уже выпустили соответствующие обновления.

KB у Juniper: [JSA10623] 2014-04 Out of Cycle Security Bulletin: Multiple products affected by OpenSSL «Heartbleed» issue (CVE-2014-0160)

Проверить ваш HTTS сервис на наличие данной уязвимости можно с помощью online тулз:

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

Сегодня ночью обнаружилось, что один из апстрим каналов начал играть в «ванька-встанька».

BGP сессия падала, поднималась, снова падала, снова поднималась и так до бесконечности.

В логах BGP читалось:

Sep  9 00:26:59.219845 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from Established to Idle (event RecvUpdate)
Sep  9 00:27:03.460183 bgp_read_v4_update:8189: NOTIFICATION sent to XX.XX.XX.141 (External AS XXXX): code 3 (Update Message Error) subcode 11 (AS path attribute problem)
Sep  9 00:27:39.219859 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from OpenConfirm to Established (event RecvKeepAlive)

В messages:

Sep  9 00:27:33  rpd[1153]: XX.XX.XX.141 (External AS XXXX) Received BAD update for family inet-unicast(1), prefix 212.118.142.0/24

Полез разбираться, читаем:
BGP Notification Message Error Codes and Error Subcodes

Table 142: BGP Notification Message Error Codes  

Error
Code
Value
Code Name Description
1 Message Header
Error
A problem was detected either
with the contents or length of the BGP header. The Error Subcode
provides more details on the nature of the problem.
2 Open
Message Error
A problem was
found in the body of an Open message. The Error Subtype field
describes the problem in more detail. Note that authentication failures
or inability to agree on a parameter such as hold time are included
here.
3 Update Message
Error
A problem was found in the body
of an Update message. Again, the Error Subtype provides
more information. Many of the problems that fall under this code are
related to issues detected in the routing data or path attributes sent
in the Update message, so these messages provide feedback about
such problems to the device sending the erroneous data.
4 Hold
Timer Expired
A message was
not received before the hold time expired.
See
the description of the Keepalive message for details on this timer
.
5 Finite State
Machine Error
The BGP finite state machine
refers to the mechanism by which the BGP software on a peer moves from
one operating state to another based on events (
see
the TCP finite state machine description for some background on this
concept
). If an event occurs that is unexpected
for the state the peer is currently in, it will generate this error.
6 Cease Used when a
BGP device wants to break the connection to a peer for a reason not
related to any of the error conditions described by the other codes.

Table 143: BGP Notification Message Error Subcodes  

Error
Type
Error
Subcode Value
Subcode
Name
Description
Message
Header Error (Error Code 1)
1 Connection Not
Synchronized
The expected value in the Marker
field was not found, indicating that the connection has become unsynchronized.
See
the description of the Marker field
.
2 Bad
Message Length
The message
was less than 19 bytes, greater than 4096 bytes, or not consistent with
what was expected for the message type.
3 Bad Message
Type
The Type field of the
message contains an invalid value.
Open
Message Error (Error Code 2)
1 Unsupported
Version Number
The device
does not “speak” the version number its peer is trying to
use.
2 Bad Peer AS The router doesn’t recognize
the peer’s autonomous system number or is not willing to communicate
with it.
3 Bad
BGP Identifier
The BGP Identifier
field is invalid.
4 Unsupported
Optional Parameter
The Open message contains
an optional parameter that the recipient of the message doesn’t understand.
5 Authentication
Failure
The data in
the Authentication Information optional parameter could not be
authenticated.
6 Unacceptable
Hold Time
The router refuses to open a
session because the proposed hold time its peer specified in its Open
message is unacceptable.
Update
Message Error (Error Code 3)
1 Malformed
Attribute List
The overall
structure of the message’s
path
attributes
is incorrect, or an attribute
has appeared twice.
2 Unrecognized
Well-Known Attribute
One of the mandatory well-known
attributes was not recognized.
3 Missing
Well-Known Attribute
One of the
mandatory well-known attributes was not specified.
4 Attribute Flags
Error
An attribute has a flag set to
a value that conflicts with the attribute’s type code.
5 Attribute
Length Error
The length
of an attribute is incorrect.
6 Invalid Origin
Attribute
The Origin attribute has
an undefined value.
7 AS
Routing Loop
A routing loop
was detected.
8 Invalid Next_Hop
Attribute
The Next_Hop attribute
is invalid.
9 Optional
Attribute Error
An error was
detected in an optional attribute.
10 Invalid Network
Field
The Network Layer Reachability
Information
field is incorrect.
11 Malformed
AS_Path
The AS_Path
attribute is incorrect.

Такс… приехали…

При помощи своего апстрима удалось выяснить что действительно мне и многим другим другим поднасрал Saudi Telecom и анонсируемый им префикс 212.118.142.0/24.
О чем свидетельствуют мои логи, рассказ апстрима о проблемах и у других его клиентов, а так же:  Saudi Telecom sending route with invalid attributes 212.118.142.0/24:

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
Accepted Multipath

-Jonas

Ответ:

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.

Смотрим инфу в RIPE:

% Information related to '212.118.140.0/22AS25019'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
remarks: for any Abuse or Spamming Please send an e-mail to abuse@saudi.net.sa
origin: AS25019
mnt-by: saudinet-stc
source: RIPE # Filtered

% Information related to '212.118.140.0/22AS39891'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
origin: AS39891
mnt-by: saudinet-stc
source: RIPE # Filtered

О как, за двумя ASками данный префикс числится. Красавцы, чего тут сказать.

Отфильтровав этот префикс к чертям собачьим, BGP сессия сразу же перестала падать. Вечером та же участь постигла и другого апстрима.

Т.к. к вечеру я уже реально задолбался, то взял отфильтровал нафиг по as-path обе аски  AS39891 и AS25019. Пусть саудовский телеком идет лесом и уже научится пользоваться BGP фильтрами.

Вот так один «олень» может доставить гемороя многим во всем мире.

З.Ы. Junos:

    JUNOS Base OS Software Suite [9.4R1.8]
    JUNOS Kernel Software Suite [9.4R1.8]

Пролеме точно подвержены Junos`ы версии 9.4 и ниже, update JunOS`а ждет меня и не только меня 🙂



Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Исходные данные

  1. Несколько vlan на сisco catalyst 3560G. В качестве примера будут использоваться vlan 10,20 и 30
  2. Сервер на FreeBSD с работающим trafd и сетевым интерфейсом «смотрящим» в cisco catalyst 3560G

Задача

Получить статистику по трафику для каждого из вланов по отдельности.

Вариант решения

1. Настройка зеркалирования трафика на 3560.

Предполагаем, что интерфейс сервера соединён с портом Gi0/1 на 3560.

Настраиваем порт:
c3560# conf t
c3560(config)# interface GigabitEthernet0/1
c3560(config-if)# description mirror_server
c3560(config-if)# switchport trunk encapsulation dot1q
c3560(config-if)# switchport trunk allowed vlan 10,20,30
c3560(config-if)# switchport mode trunk
c3560(config-if)# exit
c3560(config)# exit
c3560# wri

Создаём сессию span:
c3560# conf t
c3560(config)#monitor session 2 source vlan 10 , 20 , 30 both
c3560(config)#monitor session 2 destination interface Gi0/1 encapsulation dot1q
c3560(config)# exit
c3560# wri

На вторую команду коммутатор может сказать что-то похожее

% Warning: One or more specified dest port does not support requested encapsulation.

Однако порт нормально добавляется в сессию
c3560# sho monitor session 2

Session 2
---------
Type              : Local Session
Source VLANs      :
Both          : 10,20,30
Destination Ports : Gi0/11
Encapsulation : DOT1Q
Ingress : Disabled

2. Настройка интерфейсов сервера и trafd
Предполагаем, что на сервере для получения зеркалируемого трафика используется интерфейс bge1.

Создаём vlan’ы на интерфейсе bge1:

/sbin/ifconfig bge1 up
/sbin/ifconfig vlan10 create vlan 10 vlandev bge1
/sbin/ifconfig vlan10 up promisc
/sbin/ifconfig vlan20 create vlan 20 vlandev bge1
/sbin/ifconfig vlan20 up promisc
/sbin/ifconfig vlan30 create vlan 30 vlandev bge1
/sbin/ifconfig vlan30 up promisc
/sbin/ifconfig bge1 -promisc

Устанавливаем trafd:

cd /usr/ports/net-mgmt/trafd
make install clean

После установки смотрим, что он установился:

/usr/sbin/pkg_info | grep trafd
trafd-3.0.1_2 The BPF Traffic Collector

Описываем trafd в /etc/rc.conf (параметры будут использоваться стартовым скриптом /usr/local/etc/rc.d/trafd.sh.sample):

trafd_enable=»YES»
trafd_ifaces=»vlan10 vlan20 vlan30″
trafd_flags=»-r -p»

Стартуем trafd:
/usr/local/etc/rc.d/trafd.sh.sample start

И наблюдаем запущенные процессы:

/bin/ps -ax | grep trafd

93173  ??  Ss     0:04.28 /usr/local/bin/trafd -i vlan10 -r -p
93175  ??  Ss     0:12.64 /usr/local/bin/trafd -i vlan20 -r -p
93177  ??  Ss     2:05.00 /usr/local/bin/trafd -i vlan30 -r -p

Добавляем в планировщик (/etc/crontab) периодический сброс накопленной trafd информации:

*/10 * * * * root /usr/local/bin/trafdump vlan10; sleep 2; /usr/local/bin/trafsave vlan10
*/10 * * * * root /usr/local/bin/trafdump vlan20; sleep 2; /usr/local/bin/trafsave vlan20
*/10 * * * * root /usr/local/bin/trafdump vlan30; sleep 2; /usr/local/bin/trafsave vlan30

Логи будут сохраняться в директории /usr/local/var/trafd как отдельные файлы вида trafd.vlan10, trafd.vlan20, trafd.vlan30 в бинарном формате. Каждые 10 минут будет происходить дописывание вновь сбрасываемого трафика в эти файлы, т.е. append.
Файл с историей дампа трафика по умолчанию: /var/log/traffic.log

Если сервер не является шлюзом, во избежание закольцовывания трафика и появления duplicate пакетов лучше отключить
форвардинг:

/sbin/sysctl net.inet.ip.forwarding=0
net.inet.ip.forwarding: 1 -> 0

а также терминировать полученные зеркалированные пакеты на сервере, запретив их хождение через вланы каким-либо файрволлом, например ipfw (правила лучше разместить где-нибудь вначале):

/sbin/ipfw add 10 deny ip from any to any via vlan10
/sbin/ipfw add 20 deny ip from any to any via vlan20
/sbin/ipfw add 30 deny ip from any to any via vlan30

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: MadMax
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,25 из 5)
Загрузка...
Отправить на почту Отправить на почту