Выдаются — да. Наверное Вы имеете в виду PPPoE.
Просто PPPoE не было. Было прямое подключение, и ограничение по скорости с использованием rate-limit. В этом случае, пакеты на меня и от меня матчатся на access-list, к которому привязывается группа rate-limit. Когда я выходил с IP которые себе нагло присвоил, этот траффик не матчился на access-list, и поэтому никак не ограничивался, кроме как физической скоростью на интерфейсе.
Если бы было ограничение по трафику, то его бы учитывал netflow. В таком случае, биллинг считает, что мой траффик — траффик на и с моих IP, а так как IP не мои, то и траффик не мой.
А что мешает несколько подсетей прописать? Допустим есть одна большая 100.100.100.0/24. Можно всю захватить, прописав у себя 100.100.100.0/25 и 100.100.100.128/25.
Возможно. Признаться, я достаточно долго думал, писать об этом или не стоит тратить время, свое и читателей. Но факт остается фактом, провайдер вмешательства в их маршрутизацию не заметил. Это перевесило аргументы против.
Проблема в том, как вы определили FAILURES. Как я писал
«Последний параметр – 4 это индекс DEVSEASONAL, этот индекс можно посмотреть командой rrdtool info»
Запустите rrdtool info my.rrd
В результате
filename = «my.rrd»
rrd_version = «0003»
step = 900
last_update = 1301051590
header_size = 1700
ds[val].index = 0
ds[val].type = «GAUGE»
ds[val].minimal_heartbeat = 1800
… rra[4].cf = «DEVPREDICT»
rra[4].rows = 2688
rra[4].cur_row = 2232
…
Индекс rra DEVPREDICT в данном случае 4, я подозреваю у Вас другой, так как вы создали несколько дополнительных агрегированных RRA — вот эти 'RRA:AVERAGE:0.10:3:4464',
'RRA:AVERAGE:0.10:6:4464',
'RRA:AVERAGE:0.10:12:4464'
Базу данных придется создать по новой с правильным индексом.
Начнем с того, что там вовсе не один голосовой поток… И что на текущий момент мы мониторим таким образом более 15 тысяч параметров.
Если коротко, суть работы описанных скриптов следующая:
Один скрипт по snmp опрашивает устройства и заполняет базы данных rrdtool, которые лежат в определённой папке.
Второй скрипт сканирует базы данных в папке на наличие аберраций и выдает алерт по почте.
Добавить сканирование нескольких папок — дело нескольких минут. Добавить опрос других параметров по SNMP тоже не сложно.
Если бы мне год назад показали как это делается, я бы это обязательно сделал, хотя бы для мониторинга основных параметров.
Впрочем, я и так это сделал :)
Нет, не было. Задача другая совсем стояла, а именно, мониторить несколько тысяч параметров транзитного VoIP, которые ведут себя как захотят, и тем не менее поддаются мониторингу прогнозированием.
Кактус у нас живет и живет давно, но он для отображения графиков используется и не более того. Рыться в коде кактуса и модифицировать его сложнее, чем самому написать…
А почему накладно? Всего 2 скрипта, один на bash — заполнение баз данных rrdtool. Второй — на python-e — отображение графиков и алертинг. Оба я привел, они просты и модифицировать под себя не составит труда.
Если считаете, что накладно по ресурсам системы, то скажу, что скрипт в данном посте определяет аберрации для 1600 баз данных максимум за 2 секунды.
Да, я потратил кучу времени пока настраивал, и проверял как это всё работает, но, в результате максимально просто описал как всё делается. Думаю разобраться за день и настроить не составит труда.
amarao, Вы не правы, и напрасно придираетесь к словам g0ff.
Давайте я объясню то же самое, что и g0ff, только другими словами.
В вашем случае, когда «заcранцы» из Vlan 3 стучались на серые IP из Vlan 1, пакеты приходили на inside (внутренний) с точки зрения NAT интерфейс. Маршрутизатор в этом случае решает куда их отправить. Если надо отправить через внешний с точки зрения NAT (outside) интерфейс, то сработает NAT, если через другой интерфейс, не важно прописано там inside, или ничего не прописано, то до NAT дело вообще не дойдет.
Теперь по тому, что написано в статье.
Когда пакет приходит на ouside с точки зрения NAT интерфейс, маршрутизатор проверяет заголовок пакета DST IP. Если IP адрес назначения попадает в пул внешних IP сконфигурированный для NAT, то срабатывает NAT, если нет — то маршрутизация.
Возражу, что для того, чтобы осуществить подобную атаку нужно сначала установить FTP соединение с внутренним хостом, а этого в условиях не было. А задумается инженер в любом случае, просто потому, что, раз спрашивают, то где подвох.
Нет, что вы, это greenshot :). При написании юзер мануалов просто незаменимая вещь. Бесплатен, с открытым кодом и минималистичен. В нем есть все, что нужно, и только то, что нужно. Благодарен тем, кто его написал, в общем — рекомендую.
Во — первых трафик не из серых сетей а на серые сети.
А на счёт паранойи — отнюдь нет.
Любую информацию можно использовать по разному, к примеру задайте такой вопрос на собеседовании с претендентом. Если даже он не ответит, посмотрите, загорятся ли у него глаза, когда скажете про маршрут от провайдера. Поверьте, его реакция может о многом про него рассказать…
Просто PPPoE не было. Было прямое подключение, и ограничение по скорости с использованием rate-limit. В этом случае, пакеты на меня и от меня матчатся на access-list, к которому привязывается группа rate-limit. Когда я выходил с IP которые себе нагло присвоил, этот траффик не матчился на access-list, и поэтому никак не ограничивался, кроме как физической скоростью на интерфейсе.
Если бы было ограничение по трафику, то его бы учитывал netflow. В таком случае, биллинг считает, что мой траффик — траффик на и с моих IP, а так как IP не мои, то и траффик не мой.
«Последний параметр – 4 это индекс DEVSEASONAL, этот индекс можно посмотреть командой rrdtool info»
Запустите
rrdtool info my.rrd
В результате
filename = «my.rrd»
rrd_version = «0003»
step = 900
last_update = 1301051590
header_size = 1700
ds[val].index = 0
ds[val].type = «GAUGE»
ds[val].minimal_heartbeat = 1800
…
rra[4].cf = «DEVPREDICT»
rra[4].rows = 2688
rra[4].cur_row = 2232
…
Индекс rra DEVPREDICT в данном случае 4, я подозреваю у Вас другой, так как вы создали несколько дополнительных агрегированных RRA — вот эти
'RRA:AVERAGE:0.10:3:4464',
'RRA:AVERAGE:0.10:6:4464',
'RRA:AVERAGE:0.10:12:4464'
Базу данных придется создать по новой с правильным индексом.
Если коротко, суть работы описанных скриптов следующая:
Один скрипт по snmp опрашивает устройства и заполняет базы данных rrdtool, которые лежат в определённой папке.
Второй скрипт сканирует базы данных в папке на наличие аберраций и выдает алерт по почте.
Добавить сканирование нескольких папок — дело нескольких минут. Добавить опрос других параметров по SNMP тоже не сложно.
Если бы мне год назад показали как это делается, я бы это обязательно сделал, хотя бы для мониторинга основных параметров.
Впрочем, я и так это сделал :)
Кактус у нас живет и живет давно, но он для отображения графиков используется и не более того. Рыться в коде кактуса и модифицировать его сложнее, чем самому написать…
Если считаете, что накладно по ресурсам системы, то скажу, что скрипт в данном посте определяет аберрации для 1600 баз данных максимум за 2 секунды.
Да, я потратил кучу времени пока настраивал, и проверял как это всё работает, но, в результате максимально просто описал как всё делается. Думаю разобраться за день и настроить не составит труда.
Только
> для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
подменять ничего не надо :)
Давайте я объясню то же самое, что и g0ff, только другими словами.
В вашем случае, когда «заcранцы» из Vlan 3 стучались на серые IP из Vlan 1, пакеты приходили на inside (внутренний) с точки зрения NAT интерфейс. Маршрутизатор в этом случае решает куда их отправить. Если надо отправить через внешний с точки зрения NAT (outside) интерфейс, то сработает NAT, если через другой интерфейс, не важно прописано там inside, или ничего не прописано, то до NAT дело вообще не дойдет.
Теперь по тому, что написано в статье.
Когда пакет приходит на ouside с точки зрения NAT интерфейс, маршрутизатор проверяет заголовок пакета DST IP. Если IP адрес назначения попадает в пул внешних IP сконфигурированный для NAT, то срабатывает NAT, если нет — то маршрутизация.
А на счёт паранойи — отнюдь нет.
Любую информацию можно использовать по разному, к примеру задайте такой вопрос на собеседовании с претендентом. Если даже он не ответит, посмотрите, загорятся ли у него глаза, когда скажете про маршрут от провайдера. Поверьте, его реакция может о многом про него рассказать…