» Несанкционированный трафик и провайдеры ...

Суть проблемы.
Подразделение фирмы арендует выделенку в бизнес-центре с публичным ИП. Оплата по договору за трафик (10$ за 100 Мб) + абонентка 10$ (+100Мб).
Внутренняя сетка с приватными ИП подключена к выделенке через сервер под
НТ с установленными на нем ВинРутом и почтовиком М-Демон. Само собой
включен НАТ. Из портов открыты 80, 25, 110, 443.
В один день вдруг с Инетом полная ж..., беда в общем - все лежит. Звоним местному прову - тот говорит что нас отрубили - чрезмерный суточный трафик из-за наличия у нас открытого SMTP релея. По статистике на веб сайте прова - трафик за пол дня якобы по Гигу в каждую сторону!!! За предыдущий день - по 200 Мб (столько бывает за треть месяца макс.).
Ну да ладно - Релей закрыли, с провом поругались, смотрим логи (настроены по всем включенным сервисам) и видим - левого SMTP трафику всего на 8 метров (~1700 мыл) за 3 дня! Причем надо учесть что Почтовик у нас архивирует 100% всей почты! По ВинРуту - туча обращений снаружи на 80 порт (но там только прокся с авторизацией?!). Инет заработал - живем.
На след. день по статистике прова входящий трафик стабильно пребывает по 8Мб в час, исходящий по 4-5 Мб. Причем сами в Инет не ходим, почту почти не шлем. В итоге трафику за день 150/70 Мб (вход/исх). Потребовали у прова лог - прислали кусок на 1,5 часа - там практически одни пакеты по 60 байт на 80 порт. Задропили в ВинРуте все ответы по 80 порту - упал до 0 исходящий трафик, а входящий в статистике так и пребывает. На след. день вообще выдернули кабель прова из сервера и видим в статистике туже картину - входящий траф. пребывает по 8 Мб в час!!!. Мы трясти прова. Его админ - "А вы что хотели, на ваш ИП идут пакеты, мы их честно считаем". Занавес!
Так получается, что запусти какой нибудь децел пинг на наш ИП в цикле, эта сволочь (пров) насчитает нам трафика по самые помидоры, даже при выключенном сервере!!!. А ведь в конце месяца эти ироды выставят, при таком подходе, весьма круглый счет, можно сказать за воздух. К тому же откуда взялся в статистике прова Гиг трафика в день катаклизма - неизвестно. По нашим логам - Инет 3,5 Мб, почта 10 Мб. Итого - 13,5Мб!!! В общем какойто маразм.

Как с этим бороться?

за лохов вас держут
не могут они щитать пакеты которые не дошли до адресата
точней физически могут пропускать пакеты идущие на ваш адрес даже когда ваш комп не работает
но ето незаконо

слать их надо нах
совок похоже будет жить еще долго

Цитата:

Как с этим бороться?

1) Немедленно разорвать с ними договор (пока еще пару гигов не повесили)
2) Внимательно пересмтореть договор на предмет того а за что собс-но вы платите. Вообще, если ты выдергиваешь шнурок из компа, то твой айпи перестает существовать и пакеты должны обламываться на их маршрутизаторе. Как они умудряются их считать - не знаю...
3) Обратиться к грамотному юристу и в какое-нибудь общество по защите прав потребителей (или как там оно в твоей местности называется).

Цитата:

2) Внимательно пересмтореть договор на предмет того а за что собс-но вы платите. Вообще, если ты выдергиваешь шнурок из компа, то твой айпи перестает существовать и пакеты должны обламываться на их маршрутизаторе. Как они умудряются их считать - не знаю...

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


Цитата:

Так получается, что запусти какой нибудь децел пинг на наш ИП в цикле, эта сволочь (пров) насчитает нам трафика по самые помидоры, даже при выключенном сервере!!!.

Именно так. И никак по другому. Провайдер абсолютно не несет ответственности за то, что вас кто-то закидывает пакетами.

Цитата:

Внимательно пересмтореть договор на предмет того а за что собс-но вы платите

По договору мы оплачиваем входящий трафик за оказываемые нам услуги передачи данных

Цитата:

фильтровать трафик у провайдера

А за это они отдельных денег хотят

Цитата:

Провайдер абсолютно не несет ответственности

Да, но по договору он обязан обеспечить качественный сервис, причем соответствующий заявленной спецификации (пропусканая способность канала, время отклика и т.д.), а когда канал забит левым мусором ни о каком соответствии даже речи нет - вообще нефига не работает. Причем это не наш трафик - мы в этот момент не потребляем услуг передачи данных, которые являются предметом договора.

NiX
Представь - ты отключил мобилу, а тебе кто-то все равно звонит, сто раз прослушивает мессагу что абонент недоступен, и на утро ты уже должен оператору 100 баков? Понравиться? Ведь звонящие тебе напрягают сеть передачи данных и телефонное оборудование, а то и вообще звонят с межгорода - просто Эльдорадо для "Остапов Бендеров". Золотая жила!

Не, народ, тема в другом... мне кажется дело не в обслуге. У меня у самого такая тема была, тока там все измерялось гигабайтами... я и сейчас понятия не имею куда-откуда и почему ко мне шли пакеты... Короче, практически аналогичная трабла (я правда на уровне прова ее решил).
Просьба, если кто знает почему сие бывает - не флеймить. Тема реально серьезная.

а уже все сказали почему такое бывает и как бороться .

бывает - потому что изначально не было принято мер безопасности . Представь - юзера кинулись оставлять свое е-мыл где попало и теперь к вам прется несколько тыс. спаммерских емылов ежедневно . До вашего почтовика все доходят , траффик есть . При чем здесь пров ? Так и здесь , если наоставлять открытых релеев и проксей то попадете к куулхацкерам на заметку а они на вас всяких ботов напустят . например внесли адрес вашего прокси в бот , который который проверяет доступность . траффик опять таки идет и пров тут не при чем .

бороться - однозначно вместе с провом . возможно - при помощи денег . \
поставить параллелдьно с винрутом какой-нибудь сниффер .

Нас так обычно всякие сканеры достают.
Обычно хватает простого общения с хозяином сервера,
достающего своими пакетами, либо с его провайдером.

ЗЫ: Так же не помешало б сделать свою сеть невидимкой,
а почту и www, если надо, закинуть на провайдера.

JcVai

Цитата:

невидимкой

то есть?
у меня трабла была с портом 21** это 100% не почта, но траффик так и пер...

Цитата:

сниффер

где его найти?

Цитата:

сниффер

где его найти?

в Варезнике . я предпочитаю observer , наверно есть и более специфичные .

HAPPS

Цитата:

Цитата: невидимкой

то есть?

Цитата:

не отвечать ни на какие внешние запросы

Это сразу сделали, по "факту". Но видимо раз уж засветился то адрес, то долбают.
* Кстати к размышлению: первоначально большинство ломившихся на рэлей было с азиатских доменов (Китай, Корея) а уж потом прорвало со всего света.
* Сидел тут смотрел архив почты и что не пойму, то накой некоторые идолы найдя халявный рэлей шлют через него деловую почту? Шиза.


Цитата:

Кстати, при хорошем прокси

А вот на это рассчитывать не приходится. Стоит что проще и надежней. Обслуживать систему некому - спецов в штате нет. В офисе только несколько менеджеров да бухгалтеров. К тому же тачка под сервером отстойная...

хе,хе.... в теме про защите от прослушивания сниффер - я так понял прога не для защиты.. либо это другой некий сниффер?
JcVai - это не ФТП, это некий порт 2134 типа того...

DBA

Цитата:

Это сразу сделали, по "факту". Но видимо раз уж засветился то адрес, то долбают.

Проверьте. Есть вариант "порт закрыт" и есть "порт недоступен".


Цитата:

большинство ломившихся на рэлей

Цитата:

найдя халявный рэлей шлют через него деловую почту?

А я вот не пойму зачем включать открытый релэй?
Или есть большое желание попасть в черный список почтовиков?

Открытые релэи и прокси являются одними из основных целей ботов-сканеров.

Добавлено
HAPPS

Цитата:

некий порт 2134 типа того

Усек, тогда вам сюда:
http://www.iana.org/assignments/port-numbers

ВО! нашел,
это он, собака..
tivoconnect 2190/tcp TiVoConnect Beacon
tivoconnect 2190/udp TiVoConnect Beacon

Цитата:

зачем включать открытый релэй

Досталось по наследству от предыдущего админа.

Цитата:

хе,хе.... в теме про защите от прослушивания сниффер - я так понял прога не для защиты.. либо это другой некий сниффер?

или я допился до белки , или тема про несанкционированный траффик .

Есть такая проблема и у меня, пров считает по порту на кошке, и ему до фени что за траффик ко мне идет, разница доходила: 35 метров у меня - у прова показывает 723 метра за сутки.
Решил следующим образом:
1. Переговорил с админом, он согласился уменьшить выставленный траффик.
2. Перешел на VPN-подключение

З.Ы. Слышал, что пакеты кошка кидает и на все порты, накручивая таким образом до 10-30 метров за сутки. Так ли это?

Batman

Цитата:

лышал, что пакеты кошка кидает и на все порты, накручивая таким образом до 10-30 метров за сутки. Так ли это

Доказательства в студию.

А по поводу топика.

В данном случае пров *полностью* прав.
Посему как на NAS'е, который обслуживает тебя, этот пакет прошел и счетчик щелкнул.
Что ты будешь делать с этим пакетом -- это твои тараканы.
Если есть большой левый траффик -- тушить его надо на уровень выше, еще до NAS'а.

Batman
точно так если пров считает на "своей стороне" и нет если "у тебя"
выход кроме "разговоров с провом" пока тока один нашелся VPN ...
еще идеи есть ?



Добавлено
в догонку: чем пров мерит (считает) гиги?

Пров все-таки чаще бывает прав. Ну в самом деле, если у тебя есть белый адрес, то сам же и принимаешь всю меру ответсвенности за его работу. Т.е. иметь инет можно и с серым адресом: прокси и проч. А с белым можно принимать входящие соединения. Так вот и они )))))))))).

Попытаюсь предложить решение. Если порт зафайрволить и ответить на пакет REJECT'ом, то по логике вещей этот пакет должен вызвать процедуру убития маршрута между инициатором соединения и принимаемой стороной. Теперь вопрос к знатокам марштуризаторов и ПО: почему эта схема не работает? Почему я не могу отказать в соединении?

Потому что соединения то и не обязательно.
Пакеты идут для инициации соединения.

Повторяю... Допустим, идет TCP пакет с запросом на установление соединения : SYN. Да и вообще может идти любой пакет: UDP (которому не нужна инициализация соединения). Мы его "глушим", а в ответ отсылаем ICMP "хост не доступен". По логике вещей этот пакет должен пойти обратно и вызвать прекращение процедуры установления соединия. Ну и я так думаю, что когда этот пакет идет по маршрутизаторам, то при каких-то условиях вызывает в них процедуру изменения таблицы маршрутизации: хост-то не доступен! Ну допустим глобальным компаниям наша машина по барабану. У них никаких ресурсов не хватит, чтобы запомнить изменения маршрутов для всех желающих. Но свой-то провайдер это выполнить в состоянии!!! В этом случае мы не будем оплачивать паразитный трафик, ну а пров пусть сам думает, как ему тоже от него избавиться.

Может быть, что не обязательно для этого использовать стандартные средства типа протоколов ICMP. Стандартные подходы не все знают, даже в этом форуме Но договориться с провом можно и нужно.

Цитата:

Попытаюсь предложить решение. Если порт зафайрволить и ответить на пакет REJECT'ом, то по логике вещей этот пакет должен вызвать процедуру убития маршрута между инициатором соединения и принимаемой стороной.

помоему no route to host и destination host unreachable это разные вещи . В любом случае процедура убиения маршрута вызываться не будет , ибо за маршруты отвечают специальные протоколы маршрутизации , а icmp служит лишь для информирования юзера .

это-ж какой бардак был бы , если бы каждый мог на маршрутизацию влиять ...

Описанная схема (послать ответ, что destination host unreachable) не будет работать по той причине, что, как правило, динамическую маршпутизацию для клиенстких хостов провайдеры не поддерживают. Твой ответ о недостижимости просто не повляет не перестроение маршрутов. Попробуй ограничить число запросов на соединения, если сможешь, конечно. Входящих запросов на соединения, я имел в виду.

Так вот я и говорю, что провайдеру влом поддерживать эту вещь. Но я и не требую именно такую схему. Да и вообще конкретно эта проблема- не моя. Схема взаимодействия может быть любая вплоть до телефонного разговора между админами. Это я все к тому, что с таким трафиком можно бороться и пусть провайдеры не валят все с себя на клиента. В конце концов прову тоже должно быть невыгодно держать у себя ломанутого клиента со всеми вытекающими последствиями: открытые релей, фтп-варезник, сканирующий хост и т.д. Да и если они будут судиться по поводу оплаты трафика- пров проиграет однозначно.

Пишите письма!

finist

Цитата:

Да и если они будут судиться по поводу оплаты трафика- пров проиграет однозначно.

Аргументируйте.
То есть если маньяк завалил кого-то ножом, то виноват продавец ножа?
Глупости.
Где-то в контракте написано, что провайдер обеспечивает безопасность ваших компов или роутеров?
Я такого не встречал.
Посему админов никто не отменял.

Цитата:

Где-то в контракте написано, что провайдер обеспечивает безопасность ваших компов или роутеров?

Никто и не требует у прова отвечать за безопасность наших компов. Причем тут это? Тем более если с компами все ОК. Это НЕМНОГО разные вещи. Речь то ЛЕВОМ трафике. Он к безопасности никак не относится.

Собственно, если подойти с юридической точки зрения, с провом заключен договор на предоставление КЛИЕНТУ (!) услуг доступа к Интернет и оплатой трафика за этот доступ, то с чего это мы обязаны платить за то что кто-то извне получил доступ (или пытается это сделать) к какому-то из ресурсов нашего компа? Мы на этот "сервис" не подписывались, в тексте договора ни такая возможность, ни наша ответственность за нее не оговаривалась! Да, в договоре был пункт о том, что оператор не отвечает за убытки, которые мы могли бы получить в результате действий третьих лиц, но как раз их мы от этих третьих лиц и не получали, и соответственно никаких претензий на сей счет прову не предъявляем.

finist, Rodriges
А какая разница, устанавливается соединение или нет, если пров все равно считает все типы входящих пакетов за входящий трафик и выставляет вам на этом основании счет?
У нас вообще был поставлен DROP на все внешние пакеты (типа "черная дыра"), а входящий трафик по статистике прова пер по ломовому!

З.Ы. Еще одна фигня в копилку.
Описанный с первом посте инцидент имел место в выходные. Проблема была обнаружена и устранена только с началом рабочего дня в понедельник. Доступ к серверу в выходные физически невозможен, т.к. помещение где он стоит имеет жесткие ограничение по доступу (режимное предприятие), а удаленное управление сервером не установлено. Соответственно, даже если предположить что мы могли увидеть мрачную статистику прова в те дни, физически ничего сделать мы не могли, следовательно для нас имели место обстоятельства непреодолимой силы, т.е. полноценный форс-мажор....

Договор в студию! Шучу, конечно - но на самом деле надо читать договор. Если у вас там сказано что-то вроде "Оплачивается трафик, пришедший в сеть провайдера на адрес клиента" - то формально прав провайдер.

DBA

Цитата:

то с чего это мы обязаны платить за то что кто-то извне получил доступ (или пытается это сделать) к какому-то из ресурсов нашего компа?

Хаха
Я сейчас нагенерю 100 гиг траффика, и скажу, что меня похачили и вычтите мне этот траффик пажаласта
Угадай с трех раз, куда меня пошлют