Phsm

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

Сайты uaunit.com, billing.uaunit.com, МХ-сервер находятся в России на хостинге Мароснет. Создаётся впечатление, что хостинг-провайдер не доверяет собственному хостингу. К тому же проверка связности с вами становится нетривиальной задачей: пойди угадай вашу автономку и блоки адресов.

Используется усиление атаки через дырки в ntpd. Дырявому серверу бедбой шлет маленькие пакеты(64байта) с поддельными адресами(жертвы), в ответ сервер пускает на жертву udp пакеты максимально возможного размера(до 1500) Технология такая же, как и в дырявом named когда-то. Это все понятно. НО: входящих пакетов практически не было. Если не было входящих пакетов, то откуда дос? Входящих-то как раз должно быть много.

Дико плюсую этого товарища. Пофигизм "атакующих" провайдеров поражает. Зато когда атакуемый ресурс отрезает трафик с их сетей, тут же находят телефоны ДЦ и возмущаются: честных людей обижают.

ip route add default via адрес шлюза src нужный адрес Если не хочется ставить маршрут вручную, то первый адрес на интерфейсе для дефолтроута будет исходящим адресом по умолчанию (в конфиге местами поменяйте объявление адресов)

На данный момент в Гиганете 15882 префиксов

Критику технического аспекта - я могу принять.

Ага, тем самым дав возможность использовать уязвимости всем желающим. Может сразу нейтронной бомбой бахнуть, для надёжности? Если написать "У провайдера "Васятелеком" - открытые прокси, на контакт не идут", без публикации самого списка ипов, то есть шанс что админ Васятелекома напишет supportod, и они совместно урегулируют проблему. К тому же, вместо того чтобы мониторить форум, получая с него список _провайдеров_ с открытыми проксями, не проще ли злоумышленнику использовать готовые списки проксей?

Луше писать абузы на мыло, а не публиковать в открытом доступе. Именно публикация списка уязвимостей конкретной сети - наибольшее зло, которое можно совершить. Так supportod писал, что намеревается публиковать тех, кто на контакт не идёт, можно сказать last resort для решения вопроса.

Как-то не вяжется со стартовым постом: От того что на этом форуме обосрут группу провайдеров владельцы прокси аж никак не узнают об "опасности". Ну, если провайдеры читают этот форум (а скорее всего почти все читают), то владельцы прокси узнают это из уведомления от провайдера, методом andryas-a

Уведомляю абонента, предлагаю бесплатную помощь, при необходимости. Вы молодец, если это так и есть. Все бы так делали.

Я действительно не понимаю, с чего такая агрессия на идею. Кто против идеи таких списков, не могли бы толком объяснить? Идея же не в том чтобы гнобить и насмехаться над владельцами открытых прокси, а чтобы доносить до ума людей возможные последствия, потому что подавляющее большинство таких "сервисов" работает по незнанию владельца хоста. Мне известен случай, когда за открытый вайфай "для соседей, мне не жалко" прислали повестку к следователю, правда в качестве свидетеля. По причине того, что через него было сделано что-то нехорошее. Просто, чтобы вы были в курсе.

Публичные авторитативные днс - конечно не мешают. Публичные дефолтно настроенные открытые резолверы, старые версии ntpd, выпущенные в мир SNMP с community public (да-да, даже такие встречаются!) мешают многим, в том числе мне, практически каждый день. Amplified DDoS называется. Самая большая атака из украинских сетей, которую я видел, составляла 60 Гбит/с - это только украинский трафик, без учёта того, что лилось из остального мира - эта цифра хорошо говорит о масштабах попустительства со стороны провайдеров. Забавно, в момент её проведения нам звонили админы провайдеров и возмущались, мол эт

А вот говорить абоненту что ему можно, а что нельзя открывать и запускать на его компьютере - противоречит интересам провайдера этого абонента. Я где-то сказал, что провайдер должен диктовать что можно, а что нельзя? Я сказал что закрытие таких ресурсов выгодно провайдеру. Допустим, у вас обнаружилось 100 открытых проксей, каждый из которых постоянно грузит канал в среднем на 10 мбит. Это 1 гигабит паразитного трафика. Вы разослали абонентам смс вида "Уважаемый абонент, мы обнаружили потенциально опасную программу (открытый прокси-сервер) на Вашем компьютере/роутере. Скорее всего он б

Закрытие случайно или специально установленного у абонента открытого прокси должно быть в интересах провайдера этого абонента. Такой ресурс потенциально может создавать постоянную, а не всплесковую нагрузку на аплинки, платя за неё сущие копейки. Если не вдаваться в вопросы "запрещать/можно ли держать открытые прокси", то простой список айпишников-провайдеров будет кстати. Вдруг действительно огласка сподвигнет провайдеров способствовать закрытию проксей

а что это вам даст? фволом дропнуть все, если боитесь атак, и все, имхо. не? Я возможно закрыть фволом внешний ип хоп при трассировке? Не будет работать TCP offload engine и соответственно каналы будет значительно нагружены.А можно пруф? Что-то не верится. Это обычное правило, которое дропнет на исход интерфейса пакеты icmp ttl exceeded, как по мне.

Где-то на наге (или в IRC) читал, что ребята решили проблему другим способом: При нажатии в личном кабинете биллинга "оплатить", инет включается на 15 минут на низкой скорости (только юзеру об этом не говорится), и он может оплатить чем угодно. А вообще лучшим решением будет всё таки кредит доверия: при блокировании абонента, к примеру, 1го числа на странице-уведомлении дать возможность включить интернет до 3го с формулировкой вида "Обещаю оплатить до 3го числа, включить интернет", ну и заодно вывести инфу: код оплаты (если абоненты платят еще и через платежные терминалы), рекомендованн

Никогда с STP не работал, могу ошибаться, но вроде ведь на кучу вланов нужно использовать MSTP, чтобы был один инстанс на все вланы? Вообще STP - протокол стандартный и очень старый, думаю между разными вендорами проблем не должно быть. UPD: погуглил, вот: http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/spanning-trees-ex-series-mstp-configuring.html Up to 64 MSTI instances can be created for an EX Series switch, and each MSTI can support up to 4094 VLANs.

x670 будет слишком мощно для такой задачи, как по мне. Там L3, который автору не нужен, и 48, а не 24 порта. Можно посмотреть на х650, в бюджет автора укладывается: http://www.ebay.com/sch/i.html?_nkw=extreme+networks+x650 (если брать б/у)

Трасса к ним или от них? на http://lg.x.uaможно посмотреть трассу к себе.

А как, кстати, это реализовано? Просто скриптами создаются и обновляются фильтры? Да, никакого rocket science, просто обновление с помощью bgpq3, который возвращает json с префиксами, входящие в данный as-set. P.S. сорри за некропостинг

Ruslik, спасибо за ответ, но я планировал его получить от Phsm, чтобы увидеть его уровень знаний в этом вопросе. Он пишет что услуги других - дорогие. На основании этого я задаюсь вопросами: - Видимо, он имеет большой опыт в организации VDI инфраструктуры и хорошо знает порядок цен?! - Тогда зачем мне платить другим дороже, если можно обратиться к Phsm? По цене сервера сказать не могу, я плаваю в ценах на железо. Основной расходуемый ресурс на терминальных серверах это оперативная память. У меня на прошлой работе был сервер для ~70 человек. Работали в основном в 1C 8.x и MS Of

Phsm, как Вы решаете вопрос удалённого просмотра видео, чтобы картинка фильмов не дёргалась и была такого же качества, словно видео воспроизводится на локальном компьютере? Если использовать Windows в качестве удалённого рабочего стола, то воспроизведение мультимедиа вызывает большой входящий поток на локальный компьютер (с которого зашли на удалённый рабочий стол). Например, просмотр фильма в DVD качестве (~ 4ГБ) генерирует входящий трафик в 30-40 Мбит/с, порой даже до 50 Мб/с доходит В моих usecase-ах никогда видео не требовалось. Изображения/PDF - да. Когда сервер стоит недалеко

Ну во-первых да, RH не причём. Во вторых непонятно вообще - зачем автор скрипта в случае удаления pid-файлов использовал ключ -r (рекурсия) Судить по кривому инитскрипту, пролезшему из апстрима, о всём дистрибутиве это перебор. Была аналогичная проблема с bumblebee ("rm -rf /usr /lib/.....") - но сам проект много кому помог, и на качество оного никто не жаловался, насколько мне известно (сам я владелец ноута с интеловой картой, поэтому пляски с видеодровами мне устраивать не пришлось). RHEL/Centos много чем хорош, например своей стабильностью: напиши сколь угодно кривую прогу, дёргающую

Мне кажется, что будет немного выше загрузка за счёт инкапсуляции в PPPoE (хотя спорный вопрос: у меня куча qinq инкапсулируется/деинкапсулируется, а в вашем случае будет pppoe) , но справится легко, я думаю. А зачем именно pppoe, ipoe ведь гораздо проще для абонента. Можно попробовать один небольшой сегмент сети перевести на ipoe, и потом если понравится, всё остальное. И техподдержка забудет про ошибку 619, ошибку 800