Народ, подскажите как избежать данной проблемы? Т.е. запретить подобного рода соединения?
Connection attempt to TCP my_ip:45442 from remote_ip:80 flags:0x12Подскажите, пожалуйста..
> Народ, подскажите как избежать данной проблемы? Т.е. запретить подобного рода соединения?
>
>
>
> Connection attempt to TCP my_ip:45442 from remote_ip:80 flags:0x12
>
> Подскажите, пожалуйста..ipfw add 1 deny tcp from remote_ip 80 to my_ip
и быть готовым к тому, что, вероятно, содержимое веб-серверов, хостящихся на remote_ip (если таковые есть) вы не увидите.
> Народ, подскажите как избежать данной проблемы? Т.е. запретить подобного рода соединения?
>
>
>
> Connection attempt to TCP my_ip:45442 from remote_ip:80 flags:0x12
>
> Подскажите, пожалуйста..
ipfw add 111 deny tcp from remote_ip tcpflags syn,ack to my_ip
А зачем?
>ipfw add 111 deny tcp from remote_ip tcpflags syn,ack to my_ip
>А зачем?У меня за одни сутки было превышение по траффику на 16 гигабайт(!) и единственное, что я зафиксировал - так это вот эта надпись... При том логи провайдера показали, что это был http траффик, т.е. 80 порт (удаленной стороны). ПОэтому я решил что меня просто с 80 порта атаковали dos-атакой.. :( С другой стороны.. syn - это же начало пакета.. ТОгда как будут устанавливатсья вообще с 80 портом удаленной машины соединения? :( Подскажешь может что-нибудь?
>>ipfw add 111 deny tcp from remote_ip tcpflags syn,ack to my_ip
>>А зачем?
>
> У меня за одни сутки было превышение по траффику на
>16 гигабайт(!) и единственное, что я зафиксировал - так это вот
>эта надпись... При том логи провайдера показали, что это был http
>траффик, т.е. 80 порт (удаленной стороны). ПОэтому я решил что меня
>просто с 80 порта атаковали dos-атакой.. :( С другой стороны.. syn
>- это же начало пакета.. ТОгда как будут устанавливатсья вообще с
>80 портом удаленной машины соединения? :( Подскажешь может что-нибудь?16 Гб трафик - это да.
Но только - анализ нужен, однако.
Это был входящий трафик или исходящий?
Как я понимаю, логи не велись? А откуда эта запись?
И что за сервер по этому самому remote_ip?
Просто 80 порт - серверный порт, то есть - скорее всего кто-то что-то
на этом сервере смотрел.
Просто взять и закрыть - легко, главное же - то, что надо закрыть))
>16 Гб трафик - это да.
>Но только - анализ нужен, однако.
>Это был входящий трафик или исходящий?
>Как я понимаю, логи не велись? А откуда эта запись?
>И что за сервер по этому самому remote_ip?
>Просто 80 порт - серверный порт, то есть - скорее всего кто-то
>что-то
>на этом сервере смотрел.
>Просто взять и закрыть - легко, главное же - то, что надо
>закрыть))
Это входящий трафик с 80 порта. Т.е. как будто мы что-то качали. У меня все идет через прокси с авторизацией, поэтому кто-то из наших не мог просто напрсто накачать. Мой сервер сам по себе тем более. Логи велись. Анализ логов ipfw ничего не показали. Единственное, так это вот эта запись.. connection attempt.... Ситуация прискорбная.. :( Вот я и пытаюсь выяснить хотя бы каким образом это получилось :(
> Это входящий трафик с 80 порта. Т.е. как будто
>мы что-то качали. У меня все идет через прокси с авторизацией,
>поэтому кто-то из наших не мог просто напрсто накачать. Мой сервер
>сам по себе тем более. Логи велись. Анализ логов ipfw ничего
>не показали. Единственное, так это вот эта запись.. connection attempt.... Ситуация
>прискорбная.. :( Вот я и пытаюсь выяснить хотя бы каким образом
>это получилось :(ipfw count? ну, не эти логи имелись в виду... детальные - типа ipacctd и пр. Ну да неважно.
просто напросто не мог... ну, разные бывают казусы.
особенно с сайтами "для взрослых". бывает, привязываются очень неплохо)
пару клиентов нам жаловались, помнится, что мы им большой трафик насчитали.
детальная статистика все расставила по местам. то есть, трафик мог идти действительно без ведома пользователя.. потом.
>ipfw count? ну, не эти логи имелись в виду... детальные - типа
>ipacctd и пр. Ну да неважно.
>просто напросто не мог... ну, разные бывают казусы.
>особенно с сайтами "для взрослых". бывает, привязываются очень неплохо)
>пару клиентов нам жаловались, помнится, что мы им большой трафик насчитали.
>детальная статистика все расставила по местам. то есть, трафик мог идти действительно
>без ведома пользователя.. потом.И это 5 числа, когда никто не работал??? :) Чтобы выкачать 16 гигабайт это нужно максимально юзать наш канал ровно сутки. А это так и полчуилось. За остальные дни - ничего, все как обычно. Какие могут быть варианты? Сами понимаете, что какая-то брешь в системе, позволяющая выкачивать 16 гигабай в сутки мало прельщает :(
>Чтобы выкачать 16 гигабайт это нужно максимально юзать наш канал ровно
>сутки. А это так и полчуилось. За остальные дни - ничего,Для примера:
FTP с отрытым incoming куда могут накачать вареза и выложить ссылку.
Открытый прокси или релей, через который рассылали спам.
>Для примера:
>FTP с отрытым incoming куда могут накачать вареза и выложить ссылку.
>Открытый прокси или релей, через который рассылали спам.
Ну, я, конечно, не супер системный администратор и может быть не знаю всех тонкостей freebsd. Но открывать incoming на ftp не рехнулся еще :)
Такая же ситуация с open relay. Пришло с 80 порта доподлинно известно
> Такая же ситуация с open relay. Пришло с 80 порта
>доподлинно известноВ обход прокси пользователям точно не скачать ? Прокси squid ? В нем заткнута последняя дыра с обходом ntlm аутентификации ? Настройки не позволяю скачивать весь файл, когда пользователь попросил сквид скачать последние 10 байт от ISO образа какого-нибудь DVD, а удаленный сервер не поддерживает range ?
И еще, какнал в этот день точно работал ? Был случай когда из-за глюка в оборудовании (xDSL коммутутор от Lucent), при падении канала, SNMP счетчик для этого порта начинал считать весь суммарный трафик по коммутатору. Узнайте у провайдера, какой суммарный трафик на той железяке к которой вы подключены, сразу все станет ясно.
>В обход прокси пользователям точно не скачать ? Прокси squid ? В
>нем заткнута последняя дыра с обходом ntlm аутентификации ? Настройки не
>позволяю скачивать весь файл, когда пользователь попросил сквид скачать последние 10
>байт от ISO образа какого-нибудь DVD, а удаленный сервер не поддерживает
>range ?
>
>И еще, какнал в этот день точно работал ? Был случай когда
>из-за глюка в оборудовании (xDSL коммутутор от Lucent), при падении канала,
>SNMP счетчик для этого порта начинал считать весь суммарный трафик по
>коммутатору. Узнайте у провайдера, какой суммарный трафик на той железяке к
>которой вы подключены, сразу все станет ясно.Да, канал работал в этот день. Мой сервер зафиксировал 16 гигабайт входящего траффика. В обход сквид - исключено. Порт 3128 прикрыт со внешки. В логах сквида - сам перебирал - ничего. Авторизация ncsa.
> Это входящий трафик с 80 порта. Т.е. как будто
>мы что-то качали. У меня все идет через прокси с авторизацией,
>поэтому кто-то из наших не мог просто напрсто накачать. Мой сервер
>сам по себе тем более. Логи велись. Анализ логов ipfw ничего
>не показали. Единственное, так это вот эта запись.. connection attempt.... Ситуация
>прискорбная.. :( Вот я и пытаюсь выяснить хотя бы каким образом
>это получилось :(16 гигабайт трафика с одной такой записью не может быть связано. (1 мегабайт кстати тоже)
flags:0x12 - характерно для ситуации, когда Ваш хост сгенерировал SYN-пакет, а удаленный сервер ей послал ответ.
Другое дело что раз встретилось connection attempt, то хост забыл о том, что слал SYN-пакет (причин МНОГО возможных), или не отсылал его вовсе.
>
>16 гигабайт трафика с одной такой записью не может быть связано. (1
>мегабайт кстати тоже)
Если ровно сутки работы - то не престижи ли у вас? и провайдер не считает ли трафик на порту циски?
Престиж не дает "хост недоступен" по завису линии- он возвращает пакет обратно. А циска его снова туда - и так пакет гуляет между циской и престижем на всю полосу шейпера, пока его ttl не истечет... а там следующий пакетик подвалит... Бывало у меня такое.
>>
>>16 гигабайт трафика с одной такой записью не может быть связано. (1
>>мегабайт кстати тоже)
>Если ровно сутки работы - то не престижи ли у вас? и
>провайдер не считает ли трафик на порту циски?
>Престиж не дает "хост недоступен" по завису линии- он возвращает пакет
>обратно. А циска его снова туда - и так пакет гуляет
>между циской и престижем на всю полосу шейпера, пока его ttl
>не истечет... а там следующий пакетик подвалит... Бывало у меня такое.
>
Да, у прова считается все на циске. На моей стороне стоит ZyXEL OMNI ADSL. Т.е. могла ьыть ситуация, что просто между мной и провом гуляли неправильно пакетики и пров посчитал это как входящий трафик?
> Да, у прова считается все на циске. На моей стороне
>стоит ZyXEL OMNI ADSL. Т.е. могла ьыть ситуация, что просто между
>мной и провом гуляли неправильно пакетики и пров посчитал это как
>входящий трафик?
>Да, вполне. И сутки - как раз интервал между снятиями статистики
>flags:0x12 - характерно для ситуации, когда Ваш хост сгенерировал SYN-пакет, а удаленный
>сервер ей послал ответ.
>Другое дело что раз встретилось connection attempt, то хост забыл о том,
>что слал SYN-пакет (причин МНОГО возможных), или не отсылал его вовсе.
>Т.е. если и взломали мою систему, то просто провели dos-атаку с неправильно формированными пакетами? Хорошо, тогда вопрос: почему это началось именно в 0 часов и закончилось в 23:59?
> почему это началось именно в 0 часов и закончилось в 23:59?Могу и не угадать, но точка.ру (по крайней мере стрим) переустанавливает сессию именно в это время.
Ну что, многоуважаемый all. Варианты исчерпаны? Так что же это могло быть?
All! Могли ли каким то образом перенаправлять пакетики от моего имени? Например изменением в пакете исходного ip? Т.е. качать с какого-то сайта от моего имени? по схеме:кто-то -> мой сервер -> сайт с которого качали -> мой сервер -> кто-то?
> All! Могли ли каким то образом перенаправлять пакетики от моего
>имени? Например изменением в пакете исходного ip? Т.е. качать с какого-то
>сайта от моего имени? по схеме:
>
> кто-то -> мой сервер -> сайт с которого качали -> мой сервер -> кто-то?
Если у тебя iptables криво настроены - вполне. А смысл? Разве если внутрисетевой трафик не считается...
Проверь таки вариант с зависом модема и левым подсчетом - уж очень похоже.
>Если у тебя iptables криво настроены - вполне. А смысл? Разве если
>внутрисетевой трафик не считается...
>Проверь таки вариант с зависом модема и левым подсчетом - уж очень
>похоже.У меня вообще iptables нет. Голимый ipfw. from any 80 to my_ip in via rl0
Засиса модема не было да и левого подсчета нет. Что пров прислал в отчете то и было (связывался с админами этого сайта, они смотрели логи их апаче.) Действительно с моего ip выкачали с их сайта 16 гиг. но у меня гичего нет в отчетах :(
> У меня вообще iptables нет. Голимый ipfw. from any 80
>to my_ip in via rl0
Ну, тогда не может быть... если нет строк типа from any to any.
> Засиса модема не было да и левого подсчета нет. Что
>пров прислал в отчете то и было (связывался с админами этого
>сайта, они смотрели логи их апаче.) Действительно с моего ip выкачали
>с их сайта 16 гиг. но у меня гичего нет в
>отчетах :(
тогда увы... если нет повторения - ничего вычислить уже не удастся.
>тогда увы... если нет повторения - ничего вычислить уже не удастся.ПОнятно, значит я чего-то где-то недоглядел. Будет уроком. Надеюсь не повторится. Зажал всем на сквиде канал delay_pool'ом. Даже если и повторится, то уже не в таких количествах :)
Всем спасибо. :)