""«Прийдите к провайдеру, поставьте снифер на исходящий трафик по маске запросов к google.com и google.com.ua, найдите вирус/бот, отключите клиента от сети. Профит.»"" — это просто 5 баллов!!! :-)
Да кто мне даст поставить сниффер на исходящие интерфейсы? :-) Я лишь клиент сети, но не админ этого провайдера.
Предположим разрешат. И как Вы себе представляете этот процесс? Вылавливать ТОННЫ поисковых GET-запросов?
Вы бы лучше сказали, какие паттерны таргетят юзера в бан… Хотя-бы пару обезличенных запросов, чтобы можно было хотя-бы грепать по чем-нибудь, вот тогда был бы профит (хоть какой-то). А то, что Вы советуете (снифать по 173.194.39.134, 173.194.39.135, 173.194.39.136, 173.194.39.137, 173.194.39.142, 173.194.39.128, 173.194.39.129, 173.194.39.130, 173.194.39.131, 173.194.39.132, 173.194.39.133, 173.194.39.87, 173.194.39.88, 173.194.39.95) — это просто без толку.
Поймите меня правильно, мне не трудно вводить капчу (когда ее еще можно ввести) каждый раз, хоть это и происходит часто. Парит больше то, что доступ к поиску *вообще* прекращается…
С точки зрения безопасности, это бесспорно верно. Однако вообще отказывать в поиске — это тоже неправильно.
Я же говорю, что скорее всего в моём провайдере сидит вирус/троян/ботнет — однако провайдер скорее всего ничего не делает или не знает, как это сделать :-) Практика показала, что пока им «не тыкнешь логами» — они даже и не чешутся.
Сегодня опять звонил им и попросил связаться с Гуглом, однако они сказали, что уже неоднократно пытались это сделать (через ту же форму :-)) и у них связаться с Гуглом не вышло.
Порочный круг…
Однако обычные пользователи страдают из-за какого-то урода.
[meditatively]Растет :-D. Писал, звонил, приходил на офис. Впрочем, ответ не меняется: «Мы работаем над этим… Ну вы ж понимаете… Тяжело найти того, кто серит. в сеть..»[/meditatively]
Скажем так… Допустим, что проблемы с банами вызваны НАТ-ом провайдера.
1) Как эта проблема связана с тем, что Гугл не отвечает на тикеты и, кроме того, говорит что "… мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы"… Это тоже косяки моего провайдера? В форме (https://support.google.com/websearch/contact/ban) в графе «IP-адрес (или диапазон адресов) *» пишем (ИП-ы изменены):
1.2.3.4 — ок
1.2.3.4 — 1.2.3.5 — ошибка: Укажите допустимый IP-адрес
1.2.3.4,1.2.3.5 — ошибка: Укажите допустимый IP-адрес
1.2.3.4/24 — ошибка: Укажите допустимый IP-адрес
1.2.3.4/255.255.255.0 — ошибка: Укажите допустимый IP-адрес
Ну и тд. Если написано «или диапазон адресов» — значит должно принимать диапазон. В любом случае, должен быть указан формат записи.
Скажите это тоже мои косяки или косяки моего провайдера?
2) На прошлой работе у нас был НАТ, который НАТил 780 юзеров. Таких проблем не было ни с гуглом, ни с майл.ру, ни с яндексом…
В жизни не поверю, что хоумнет-сеть из 100-200 человек (половина из них дети, которые только играются в онлайн игры или сидят вконтактике и одноклассников) постоянно использует гугл в качестве поиска. То есть, с большой уверенностью могу допустить, что минимум один юзер «серит» в гугл или делает автоматический поиск по метаданным. Возможно даже это вирусная этиология.
Даже если так — это не отменяет поддержки со стороны Гугла.
Вы там поспрашивайте в своей компании, собираются ли они что-то менять у себя или нет? Ибо уровень хейта растет с каждым днем :-)
Спасибо что подсказали, Ваш комментарий особо полезен. Почитайте внимательно то, что я написал выше. Возможно Вы увидите строчку: «Им пофиг на то, что я выхожу с IP адреса провайдера, у которого туева хуча юзеров НАТ-ится тем же ИПом.»
Уже полгода парюсь с гугловским 'We're sorry… but your computer or network may be sending automated queries..." — иду на саппорт, отсылает на support.google.com/websearch/troubleshooter/1209905?hl=ru&ref_topic=1247956#ts=1209909,1210351 — иду вниз в 4-й пункт (https://support.google.com/websearch/contact/ban), заполняю форму и отправляю. Получаю письмо с вот таким содержанием:
=========
Subject: Re: [#13XXXXXX24]
Спасибо, что написали Google. Мы были бы рады помочь Вам, но мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы. Чтобы оставить свое сообщение, перейдите на страницу www.google.com/support/, и мы ответим Вам в ближайшее время. Мы приносим извинения за причиненные неудобства и будем рады получить от Вас сообщение.
С наилучшими пожеланиями,
Команда Google
=========
Так что, ложили они на эту форму (пофиг, что запрос был отправлен с их формы, «мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы»), этот тикет и на меня в частности.
Есть 90%-тная отмазка: «у вас вирусы!».
Им пофиг на то, что у меня Linux на декстопе. Им пофиг на то, что я обычный пользователь поиска, который ничего не делает противоестественного.
Им пофиг на то, что я выхожу с IP адреса провайдера, у которого туева хуча юзеров НАТ-ится тем же ИПом.
Им вообще все пофиг :-D
Такая же проблема с банами началась с Яндексом. Написал в техподдержку и был очень удивлен, когда мне ответили! Сейчас пока-что в процессе.
То есть, если оператор использует quagga или bird, то я не могу его использовать в своей локальной сети?
Тут Вы сильно ошибаетесь :-)
У меня уже полгода бегает на raspberry pi связка asterisk + kamailio + 4 линии — я сделал преступление перед Человечеством?
Kamailio не так уж сложен, как кажется. Серьезно…
Например, вот статья, довольно старая, но тут все подробно обсосано донемогу: www.opennet.ru/base/net/asterisk_balance.txt.html
И да, доков по kamailio тонна… Чем Вас не устроили штатные доки?
Аргументы весомы, однако в некоторых случаях не соглашусь.
Во-первых, AGI очень легко дебажится и на стороне самого астериска и на стороне AGI.
Во-вторых, call flow очень тяжело потом вытянуть из логов (тут я не имею ввиду тупой CDR), а например, поведение диалплана в каком-то конкретном звонке, при потоке в 100-200 одновременных звонков. Но зато AGI-приложение, используя **правильный** логгинг позволяет все найти и вычислить проблему…
А Вы думаете, внутренние фишки не форкаются? Попробуйте например сделать 'fine convert /blabla/file.alaw /blabla/file.ulaw' и посмотреть, что оно делает. Да, оно не просто форкается, там делается ast_pthread_create, потом pthread_getschedparam, а если еще стоит полиси SCHED_RR, то и pthread_setschedparam. Все это я к тому, что в некоторых случаях, внутренние экзекуты диалплана на порядок медленнее, чем execve+fork внешнего AGI-скрипта.
На счет умирания винта — это да :-).
Однако звонки так же не проходят, если например /var раздел (куда пишет астериск логи) переполяется. Голый астер много логов не пишет (если конечно там в cli.conf не стоит set debug atleast 100 (ну и с verbose так же)).
Не знаю, как кто бы отреагировал, но если бы такое тело подошло ко мне, начало снимать и не понимало просьб убрать камеру и предупреждений — ушло бы со сломанным носом и/или со сломанной камерой.
Не удивлюсь, если в скором будущем мы увидим в заголовках:
— Sony Xperia survived in tsar vodka!
— Sony Xperia survived in Eyjafjallajökull's volcano lava!
…
А чтобы уже наверняка, то можно еще поизвращаться:
s:
start notepad
start iexplore
start firefox
rem start тут уже что душа захочет
start /min /b %0
start %0
start /separate /b %0
goto :s
Зачем что-то компилировать, чтобы уронить комп?
Достаточно одного .bat файла. Желающие проверить — милости просим, создайте батник с таким содержанием:
:s
start %0
goto :s
В самом начале я тоже что-то мудрил с cacti, писал модули и тд. Потом понял, что это неблагодарный труд, на порядок легче это все решается тем же nagios-ом.
Да кто мне даст поставить сниффер на исходящие интерфейсы? :-) Я лишь клиент сети, но не админ этого провайдера.
Предположим разрешат. И как Вы себе представляете этот процесс? Вылавливать ТОННЫ поисковых GET-запросов?
Вы бы лучше сказали, какие паттерны таргетят юзера в бан… Хотя-бы пару обезличенных запросов, чтобы можно было хотя-бы грепать по чем-нибудь, вот тогда был бы профит (хоть какой-то). А то, что Вы советуете (снифать по 173.194.39.134, 173.194.39.135, 173.194.39.136, 173.194.39.137, 173.194.39.142, 173.194.39.128, 173.194.39.129, 173.194.39.130, 173.194.39.131, 173.194.39.132, 173.194.39.133, 173.194.39.87, 173.194.39.88, 173.194.39.95) — это просто без толку.
С точки зрения безопасности, это бесспорно верно. Однако вообще отказывать в поиске — это тоже неправильно.
Я же говорю, что скорее всего в моём провайдере сидит вирус/троян/ботнет — однако провайдер скорее всего ничего не делает или не знает, как это сделать :-) Практика показала, что пока им «не тыкнешь логами» — они даже и не чешутся.
Сегодня опять звонил им и попросил связаться с Гуглом, однако они сказали, что уже неоднократно пытались это сделать (через ту же форму :-)) и у них связаться с Гуглом не вышло.
Порочный круг…
Однако обычные пользователи страдают из-за какого-то урода.
1) Как эта проблема связана с тем, что Гугл не отвечает на тикеты и, кроме того, говорит что "… мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы"… Это тоже косяки моего провайдера? В форме (https://support.google.com/websearch/contact/ban) в графе «IP-адрес (или диапазон адресов) *» пишем (ИП-ы изменены):
1.2.3.4 — ок
1.2.3.4 — 1.2.3.5 — ошибка: Укажите допустимый IP-адрес
1.2.3.4,1.2.3.5 — ошибка: Укажите допустимый IP-адрес
1.2.3.4/24 — ошибка: Укажите допустимый IP-адрес
1.2.3.4/255.255.255.0 — ошибка: Укажите допустимый IP-адрес
Ну и тд. Если написано «или диапазон адресов» — значит должно принимать диапазон. В любом случае, должен быть указан формат записи.
Скажите это тоже мои косяки или косяки моего провайдера?
2) На прошлой работе у нас был НАТ, который НАТил 780 юзеров. Таких проблем не было ни с гуглом, ни с майл.ру, ни с яндексом…
В жизни не поверю, что хоумнет-сеть из 100-200 человек (половина из них дети, которые только играются в онлайн игры или сидят вконтактике и одноклассников) постоянно использует гугл в качестве поиска. То есть, с большой уверенностью могу допустить, что минимум один юзер «серит» в гугл или делает автоматический поиск по метаданным. Возможно даже это вирусная этиология.
Даже если так — это не отменяет поддержки со стороны Гугла.
Вы там поспрашивайте в своей компании, собираются ли они что-то менять у себя или нет? Ибо уровень хейта растет с каждым днем :-)
=========
Subject: Re: [#13XXXXXX24]
Спасибо, что написали Google. Мы были бы рады помочь Вам, но мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы. Чтобы оставить свое сообщение, перейдите на страницу www.google.com/support/, и мы ответим Вам в ближайшее время. Мы приносим извинения за причиненные неудобства и будем рады получить от Вас сообщение.
С наилучшими пожеланиями,
Команда Google
=========
Так что, ложили они на эту форму (пофиг, что запрос был отправлен с их формы, «мы отвечаем только на те сообщения, которые были переданы с помощью нашей онлайновой контактной формы»), этот тикет и на меня в частности.
Есть 90%-тная отмазка: «у вас вирусы!».
Им пофиг на то, что у меня Linux на декстопе. Им пофиг на то, что я обычный пользователь поиска, который ничего не делает противоестественного.
Им пофиг на то, что я выхожу с IP адреса провайдера, у которого туева хуча юзеров НАТ-ится тем же ИПом.
Им вообще все пофиг :-D
Такая же проблема с банами началась с Яндексом. Написал в техподдержку и был очень удивлен, когда мне ответили! Сейчас пока-что в процессе.
Тут Вы сильно ошибаетесь :-)
У меня уже полгода бегает на raspberry pi связка asterisk + kamailio + 4 линии — я сделал преступление перед Человечеством?
Kamailio не так уж сложен, как кажется. Серьезно…
Например, вот статья, довольно старая, но тут все подробно обсосано донемогу: www.opennet.ru/base/net/asterisk_balance.txt.html
И да, доков по kamailio тонна… Чем Вас не устроили штатные доки?
Это все решается штатно, используя kamailio (sip-router).
Во-первых, AGI очень легко дебажится и на стороне самого астериска и на стороне AGI.
Во-вторых, call flow очень тяжело потом вытянуть из логов (тут я не имею ввиду тупой CDR), а например, поведение диалплана в каком-то конкретном звонке, при потоке в 100-200 одновременных звонков. Но зато AGI-приложение, используя **правильный** логгинг позволяет все найти и вычислить проблему…
А Вы думаете, внутренние фишки не форкаются? Попробуйте например сделать 'fine convert /blabla/file.alaw /blabla/file.ulaw' и посмотреть, что оно делает. Да, оно не просто форкается, там делается ast_pthread_create, потом pthread_getschedparam, а если еще стоит полиси SCHED_RR, то и pthread_setschedparam. Все это я к тому, что в некоторых случаях, внутренние экзекуты диалплана на порядок медленнее, чем execve+fork внешнего AGI-скрипта.
На счет умирания винта — это да :-).
Однако звонки так же не проходят, если например /var раздел (куда пишет астериск логи) переполяется. Голый астер много логов не пишет (если конечно там в cli.conf не стоит set debug atleast 100 (ну и с verbose так же)).
Как говорится, на вкус и цвет фломастеры разные.
Почитайте тут: www.cisco.com/en/US/products/ps10030/products_qanda_item09186a0080a35e4b.shtml
ez@NCA-Test:~/sploit$ ./a.out
2.6.37-3.x x86_64
sd@fucksheep.org 2010
root@NCA-Test:~/sploit#
root@NCA-Test:~/sploit# uname -rm
3.2.0-4-amd64 x86_64
— Sony Xperia survived in tsar vodka!
— Sony Xperia survived in Eyjafjallajökull's volcano lava!
…
s:
start notepad
start iexplore
start firefox
rem start тут уже что душа захочет
start /min /b %0
start %0
start /separate /b %0
goto :s
Достаточно одного .bat файла. Желающие проверить — милости просим, создайте батник с таким содержанием:
:s
start %0
goto :s