rm_ Опубликовано 18 ноября, 2012 · Жалоба CloudFlare - прикольные чуваки. Я про них узнал изучая респонсы одного сайтика и увидел в хедерах CloudFlare-nginx. Вот они уже и схлопотали за 4чан 108.162.201.254;images.4chan.org;https://images.4chan.org/hm/src/135249... NetRange: 108.162.192.0 - 108.162.255.255CIDR: 108.162.192.0/18 OriginAS: AS13335 NetName: CLOUDFLARENET NetHandle: NET-108-162-192-0-1 Parent: NET-108-0-0-0-0 NetType: Direct Assignment Comment: http://www.cloudflare.com RegDate: 2011-10-28 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-108-162-192-0-1 images.4chan.org между тем резовится ещё в пять IP-адресов, которые в реестре отсутствуют, так что открываться продолжать будет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 18 ноября, 2012 · Жалоба Ваще то у чуваков 23 датацентра на текущий момент http://www.cloudflare.com/network-map Баны CDN это здорово! Стоит ли предлагать провайдерам свое решение для нормальной URL фильтрации? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 ноября, 2012 (изменено) · Жалоба Стоит ли предлагать провайдерам свое решение для нормальной URL фильтрации? Почему бы нет? Стоимость решения на 10 Gbps сквозного трафика с автоматическим определением HTTP по любым портам, полным анализом заголовков (не только первого пакета) и гарантированной фильтрацией по списку из 5000-15000 регэкспов произвольной длины (до 512 символов) хотелось бы услышать. ТТХ - L3-роутинг, wirespeed пропускание при заданных выше параметрах, не более 3 мс задержки в фильтре, отбивка блокировки по TCP/RST в обе стороны + фильтрация проходящего трафика на пару подлежащих фильтрации сокетов в течение нескольких секунд. Изменено 19 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 ноября, 2012 · Жалоба с автоматическим определением HTTP по любым портам, полным анализом заголовков (не только первого пакета) ТТХ - wirespeed пропускание при заданных выше параметрах, не более 3 мс задержки Взаимно исключающие требования. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 ноября, 2012 (изменено) · Жалоба Взаимно исключающие требования. В случае малых решений - согласен :) Но речь не о них, поэтому немножко уточню: 1. Wirespeed для всего трафика, проходящего систему насквозь, и не попадающего в детальный фильтр по заданному критерию (IP/протокол/детект заголовков). Ни в коем случае не должно быть потерь на проходящем насквозь трафике. 2. Соответственно показатель задержки - только для части трафика, попавшей под регэкспы (только заголовки, сам контент HTTP должен проходить по п.1). Поскольку появляется задержка - буферы не резиновые, и возможен определенный дроп (с которым справится TCP) до момента прохождения заголовками фильтра, но ни в коем случае - не после. Пропускная способность фильтра заголовков должна быть не менее 100000 коннектов/сек на 10 Гбит/с трафика (вполне либеральный показатель, 1 коннект на 13 Кб трафика). 3. Полный анализ заголовков с пересборкой (без матчинга по регэкспам) - да в принципе не вопрос даже wirespeed при нормальной организации конвееров. В теории - реализовать такое возможно. Детекты заголовка/контента в HTTP делаются достаточно просто, и вполне себе wirespeed. Вот со сравнивалкой по регэкспам слегка сложнее - тут должна быть аппаратная фильтр-матрица, как ее реализовать, я приблизительно представляю, но поскольку ни разу не железячник, то представляю только логику работы оной "в железе", а не конкретное решение. Мне интересно - есть ли подобные решения на данный момент, и если есть - какова их стоимость. Изменено 19 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 19 ноября, 2012 · Жалоба автоматическим определением HTTP по любым портам Заставь кое-кого молиться, он и лоб расшибёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 ноября, 2012 (изменено) · Жалоба автоматическим определением HTTP по любым портам Заставь кое-кого молиться, он и лоб расшибёт. У нас HTTP может еще и через прокси ходить, да и порт 80 - не обязателен. Когда в список попадёт URL с портом - будете материться и городить костыли. Поэтому - надо. В принципе легко определяется по: <method> <URL> HTTP/<version> [CRLF], даже дальше первых байт потока лезть не обязательно. Т.е. если DPI'ть - то DPI'ть, а всё остальное - опять же к полноценным решениям не относится. Изменено 19 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 ноября, 2012 · Жалоба Не очень показательно. Я могу CRLF отправить вторым пакетом. А ещё, фишка, о которой тут забыли - можно посылать фрагментированые ип пакеты с разными оффсетами, в тч пересекающимися, с разными данными. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 19 ноября, 2012 · Жалоба Я могу CRLF отправить вторым пакетом Вы так говорите, будто http-запрос юзер каждый раз сам составляет и по пакетам распихивает. Его же стандартный софт отправляет, в абсолютно подавляющем числе случаев это браузер, а браузеров у нас 4 штуки... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 19 ноября, 2012 (изменено) · Жалоба Некоторые броузеры опенсорс. Так что если понадобится правильно разрезать запрос GET по пакетам - сделают :( Изменено 19 ноября, 2012 пользователем Tosha Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 19 ноября, 2012 · Жалоба Это из разряда "используют анонимайзер или зарубежный прокси". Может и используют, но кого тот процент гиков интересует... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 ноября, 2012 (изменено) · Жалоба Не очень показательно. Я могу CRLF отправить вторым пакетом. А ещё, фишка, о которой тут забыли - можно посылать фрагментированые ип пакеты с разными оффсетами, в тч пересекающимися, с разными данными. Так о чем и речь - нужна пересборка пакетов перед фильтрацией. Т.е. некоторая буферизация потока неизбежна. Делается по типовым схемам а-ля MMU, соответственно полная адресная ассоциативность, аппаратный SG на уровне пакетных "страниц". Сделать реально, вопрос стоимости. Изменено 19 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 ноября, 2012 · Жалоба Ну, допустим, некоторые дпи смогут собрать фрагменты. Может даже правильно соберут с пересекающимися оффсетами (хотя виндузятникам такие пакеты не доступны в принципе). С урл энкодингом что делать? С отступлениями от стандартов, когда до сих пор можно слать LF вместо CRLF? С хттп 1.1, когда от клиента идёт больше одного гет запроса в соединении tcp? С дос атаками на этот дпи, в виде заливания ему бесконечных гет запросов кучей клиентов или нахождения лимита и держания кучи коннектов с макс буферами? Я это к тому, что хттп это жопа, и лучше туда не влазить в такой позе (посредине). :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 ноября, 2012 · Жалоба Ну, допустим, некоторые дпи смогут собрать фрагменты. Может даже правильно соберут с пересекающимися оффсетами (хотя виндузятникам такие пакеты не доступны в принципе). С урл энкодингом что делать? С отступлениями от стандартов, когда до сих пор можно слать LF вместо CRLF? С хттп 1.1, когда от клиента идёт больше одного гет запроса в соединении tcp? С дос атаками на этот дпи, в виде заливания ему бесконечных гет запросов кучей клиентов или нахождения лимита и держания кучи коннектов с макс буферами? Нет таких проблем. Число сессий на юзера как раз можно ограничить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
straus Опубликовано 19 ноября, 2012 · Жалоба Нет таких проблем. Число сессий на юзера как раз можно ограничить. Какой величиной? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
karpa13a Опубликовано 19 ноября, 2012 · Жалоба Число сессий на юзера как раз можно ограничить. а на основании чего? в тарифах это обозначите?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ohfsgcscft Опубликовано 19 ноября, 2012 · Жалоба У нас HTTP может еще и через прокси ходить, да и порт 80 - не обязателен.Когда в список попадёт URL с портом - будете материться и городить костыли. Поэтому - надо. В принципе легко определяется по: <method> <URL> HTTP/<version> [CRLF], даже дальше первых байт потока лезть не обязательно. Я пробовал на локальном компе весь исходящий TCP шерстить, косяки очень нехорошие вылазят. не проходит отправка сообщения на форум если там есть этот <method> <URL> HTTP/<version> [CRLF] из черного списка. Файл с дампом исходящих запросов тоже на сервер не загрузить. Но в законе нет разрешения/требования блокировать все подряд. Так что обязательно нужно проверять поле host и совпадение IP назначения у пакета с этим доменом. Иначе, для абонента - услуга ненадлежащего качества. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Irsi Опубликовано 19 ноября, 2012 · Жалоба Число сессий на юзера как раз можно ограничить. а на основании чего? в тарифах это обозначите?) А зачем это обозначать-то? Кстати все кто сидят за NAT-ом - по факту имеют такое ограничение... И не жужжат. И самое главное - доказать это со стороны юзера очень сложно, да и не заметит он скорей всего этого ограничения - если оно будет не слишком сильным. Кстати вспомнилось - раньше домушники очень любили это делать, чтоб к одному безлимитному тарифу не подключалось несколько квартир. Потом вымерло само собой. Никто не жужжал особо. Ща даже вспомню у кого это в договоре было прописано - у старнета вроде... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 19 ноября, 2012 · Жалоба Кстати вспомнилось - раньше домушники очень любили это делать, чтоб к одному безлимитному тарифу не подключалось несколько квартир. Потом вымерло само собой. Никто не жужжал особо. Ща даже вспомню у кого это в договоре было прописано - у старнета вроде... У которого из старнетов, уточни, пожалуйста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Irsi Опубликовано 19 ноября, 2012 · Жалоба Кстати вспомнилось - раньше домушники очень любили это делать, чтоб к одному безлимитному тарифу не подключалось несколько квартир. Потом вымерло само собой. Никто не жужжал особо. Ща даже вспомню у кого это в договоре было прописано - у старнета вроде... У которого из старнетов, уточни, пожалуйста. ДС-1 который, который из "великой тройки" интернет кидалова начала нулевых. И единственный кто из них выжил вроде как. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woddy Опубликовано 21 ноября, 2012 · Жалоба http://lifenews.ru/news/106747 - Статья Lurkmore, как и другие лживые статьи в отношении нашей партии в Интернете, являются целенаправленной информационной войной со стороны Соединенных Штатов. Эта страна с удовольствием использует пропаганду против нас и выделяет на это немалые гранты, - уверяет Федоров. - Что касается статьи про партию, она уже не является предметом рассмотрения для реестра запрещенных сайтов, но вполне попадает под ответственность новой уголовной статьи за клевету. Поэтому суд вполне сможет обязать данный ресурс заблокировать статью. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elcambino Опубликовано 21 ноября, 2012 · Жалоба http://lifenews.ru/news/106747 - Статья Lurkmore, как и другие лживые статьи в отношении нашей партии в Интернете, являются целенаправленной информационной войной со стороны Соединенных Штатов. Эта страна с удовольствием использует пропаганду против нас и выделяет на это немалые гранты, - уверяет Федоров. - Что касается статьи про партию, она уже не является предметом рассмотрения для реестра запрещенных сайтов, но вполне попадает под ответственность новой уголовной статьи за клевету. Поэтому суд вполне сможет обязать данный ресурс заблокировать статью. http://lenta.ru/news/2012/11/21/lurk/ впрочем национальное развлечение "лицом с разбега в гвно" никто не отменял Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Irsi Опубликовано 21 ноября, 2012 · Жалоба Читать лифньюс - себя не уважать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 21 ноября, 2012 (изменено) · Жалоба Я пробовал на локальном компе весь исходящий TCP шерстить, косяки очень нехорошие вылазят.не проходит отправка сообщения на форум если там есть этот <method> <URL> HTTP/<version> [CRLF] из черного списка. Неправильно шерстите потому что. Я выше специально указал: не надо лезть дальше первых байт потока. Т.е. смотрите начиная с 0 не в пакете, а в потоке (!!!), и до СRLF либо первого расхождения с паттерном. Пробелов перед <method> быть не может (хотя их наличие проверку сильно не усложнит). Ну, допустим, некоторые дпи смогут собрать фрагменты. Может даже правильно соберут с пересекающимися оффсетами (хотя виндузятникам такие пакеты не доступны в принципе). С урл энкодингом что делать? С отступлениями от стандартов, когда до сих пор можно слать LF вместо CRLF? С хттп 1.1, когда от клиента идёт больше одного гет запроса в соединении tcp? С дос атаками на этот дпи, в виде заливания ему бесконечных гет запросов кучей клиентов или нахождения лимита и держания кучи коннектов с макс буферами? Да понятно, что всё это костыль. Но давайте посмотрим ближе. С отступлениями просто - LF/CR/CRLF. URLdecoding в железе - 0 проблем 0 копеек для строк определенной длины (не более X). Бесконечные GET-запросы или коннекты - заметьте, мы фильтруем трафик со стороны абонента, а значит конкретный абонент не анонимен, т.е. получает по голове, и расторжение договора (в худших случаях - повестку в суд) - это не техническими способами решается. Вот HTTP/1.1 - это да, это самая проблемная часть реализации. Особенно chunked. Надо помозговать. Изменено 21 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ohfsgcscft Опубликовано 21 ноября, 2012 · Жалоба Хорошо, я понял, но там в <method> <URL> нет домена до первого СRLF (только в запросах к прокси) Так что нужно еще Host: отлавливать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
