Ну конечно предоставляются, мы же за них доплачиваем.
Поскольку на емейл не ответили, а ответили тут, продублирую сюда.
Мой основной вопрос, верить тарифам сайта (публичной оферты) или тарифам договора или на сайте в панели старая версия договора и с нас не сняли доплату?
Уже очень давно платим за трафик 30 мб/с (свыше 70 мб/с с 7 серверов по 10мб/с на сервер, хотя статистика трафика у вас не отображается в панели c 2014 года, а по моей информации с забикса трафика мы кушаем меньше + куча VPS'ок на др. аккаунте хотя новые VPS уже в другом датацентре беру).
Перед тем как писать сюда, уточнил в ТП по тарифам.
Ответ:
Насколько я могу судить, описание услуги на сайте несколько дезинформирует.
Стоимость доп. услуг при аренде/размещении сервера содержится в прикрепленном файле.
Еще у вас ошибка на сайте в тарифах. infobox.ru/servers/colocation
везде написано что полоса 100 мбит, по факту 10, остальное за доп плату. Видимо маркетолог спутал понятия полоса и порт.
+ трафик внутри датацентра тоже учитывается.
Новая современная панель управления услугами CCPv2, переписанная на javascript, позволяющая работать с услугой без чтения документации. В будущем в эту панель будут добавлены и другие услуги Infobox.
Круть :) Теперь нужно путешествовать по 3 панелям вместо двух :) Ибо старые услуги в новых панелях не отображаются :)
Работал с почтой инфобокса. Особенно ярко запомнилось два момента.
Письмо пришло с незнакомого IP -> В реджект (даже не в спам и ни отправитель ни получатель не узнает, что письмо не дошло и вообще было)
Пришло больше 200 писем за час -> В реджект (даже если до этого неделю не было ни одного письма)
А какие там сложности? указал ip сервера и свой емейл :)
Логически это удобнее, у меня на сервере 30 сайтов. Быстрее указать один раз IP чем 30 раз подтверждать на mail.ru
Здравствуйте, может подскажете.
В FBL вырезали емейлы, кнопку выгрузки тех кому не интересно убрали из постофиса. И как быть? Что делать? Почему яндекс не дает убрать из рассылки тех кому не интересно читать наши письма?
Например, наш арсенал средств защиты относительно недавно пополнился так называемыми функциями губки.
Минус хэшей произвольной длины в том, что мы знаем у каких пользователей пароль короткий, а у каких длинный. И зная длину пароля, можно сразу начать брутфорсить только администратора с самым коротким паролем.
Алгоритмы MD5 и SHA-1 уже не обеспечивают достаточно высокой надёжности с точки зрения вероятности возникновения коллизий (см. Парадокс дней рождения).
Опять же зависит от стоимости информации. Я не отрицаю что в SHA-256 вероятность коллизии меньше чем в SHA-1, но и в MD5 и SHA-1 она крайне мала.
в парадоксе дня рождения всего 365 вариантов значения и 23 человека (6%)
в MD5 вариантов уже 3,4 × 10^38. т.е. даже если все 7 миллиардов человек зарегистрируются, вероятность коллизии будет очень мала и по большому счету ничего не даст. Даже в радужных таблицах вероятность коллизии будет на мой взгляд очень маленькой.
Для примера у меня 80 000 000 записей MD5, больше 4 байт коллизия бывает крайне редко.
Растяжение представляет собой итеративный, или рекурсивный, алгоритм, который раз за разом вычисляет хэш самого себя, десятки тысяч раз (а то и более).
На хабре проводилось исследование. Это приведет к увеличению вероятности коллизии и упрощению брутфорса (по радужным таблицам).
Для генерирования подходящей соли нам нужен хороший генератор случайных чисел. Сразу забудьте о функции rand().
Не понятно чем это обосновано. Соль нужна чтобы по радужным таблицам не найти хэш. В редких случаях когда соль не доступна, при брутфорсе может быть и имеет смысл на жизнь то что вы говорите. Но при этом надо понимать, что стоимость исследований эффективности различных методов генератора случайных чисел затребует достаточно много человекочасов и скорее всего станет нерентабельной. Так же, хотелось бы увидеть код, которым вы сгенерировали картинку для rand(), так как рисунок больше похож на ошибку в программе, не может каждое 30 значение функции rand быть 100% предсказуемым в общем случае.
Так же если вы пишете о том, что нужно добавлять соль, обязательно надо указывать о порядке следования соли и пароля в хэширующей функции для неслучайной соли. Ибо если этот порядок неверный, от соли не будет никакого толку.
Для затруднения брутфорс-атаки соль должна быть длиной не менее 64 символов.
Тоже не понятно, откуда эта цифра и для какого алгоритма? Почему не 16 или почему не 256? Опять же каких символов? (a-z или 0x00-0xFF),
На примере того же md5 в радужных таблицах сейчас редко запись для пароля длиннее 10-12 символов. (псевдослучайных)
ждать не менее секунды между каждой попыткой.
тоже сомнительный совет, откуда эта цифра?
Я как пользователь, если буду ждать секунду пока мой пароль будет проверяться, успею три раза уйти. Почему не 100 мс? Это уже будет не сотни миллионов паролей в секунду для перебора, а всего 10 в секунду.
Да, никогда еще не было так просто блокировать конкурентов.
Одно сообщение им на форум, где его никто не увидит и одно сообщение в роскомнадзор. А если у конкурента https, то вообще сказка.
По этой логике можно заблокировать любой сайт где есть слово «Greatest Hits» и магнет ссылка.
Хотя уже сейчас спокойно могут заблокировать за слова «Чтобы сделать самоубийство надо (нужное дописать)»
Тут вопрос, где заканчивается понятие клон и начинается другой сайт. (yandex ведь не является клоном rutracker)
Чтобы клоном не являлось поменять логотип и фон допустим ( ну или по минимуму чтобы это стал не клон )
А с учетом того, что в суде дело месяц обжалуется, можно спокойно называть rutracker-11-2015.org, потом rutracker-12-2015.org
Месяца как раз хватит перенести в поисковиках домен.
Разве что киберсквотеры зарегают кучу доменов :)
Суды же не могут банить по регулярному выражению?
А смысл блокировать их по IP?
Ну вернулась им 404 страница и все, это же не DDOS.
В моей практике было один раз что администратор заблокировал по IP и в этоге сам не мог попасть на сайт.
(Часто ботами могут быть обычные пользователи, зараженные вирусами, у многIих провайдеров IP динамические)
А практики когда из — за динамических IP живые клиенты не могли попасть на сайт очень много.
Тут как минимум надо смотреть георасположение IP и убедиться что IP не в зоне целевой аудитории и не среди провайдерских IP.
Даже к взломам я по большей части отношусь с интересом, отловить все скрипты и изменения на сайте дело пяти минут, поправить уязвимость еще 10 минут, а злоумышленник проделывает большую работу по тестированию продукта на безопасность в течении многих часов.
Толку только?
Память не переполнится, дескрипторы не закончатся.
Лучше делать редирект на файл размером в сотни гигабайт,
так у них или место закончится на сервере (памяти), или трафик с каналом закончится.
Поскольку на емейл не ответили, а ответили тут, продублирую сюда.
Мой основной вопрос, верить тарифам сайта (публичной оферты) или тарифам договора или на сайте в панели старая версия договора и с нас не сняли доплату?
Перед тем как писать сюда, уточнил в ТП по тарифам.
Ответ:
Сам файл тарифов и договора:
my-files.ru/j093hu
Так что зря минусуете. С вами работаем уже с 2012 года. Даже помог вам с ТТК, чтобы трафик ходил не через германию в ваш датацентр лет 5 назад.
infobox.ru/servers/colocation
везде написано что полоса 100 мбит, по факту 10, остальное за доп плату. Видимо маркетолог спутал понятия полоса и порт.
+ трафик внутри датацентра тоже учитывается.
Круть :) Теперь нужно путешествовать по 3 панелям вместо двух :) Ибо старые услуги в новых панелях не отображаются :)
Письмо пришло с незнакомого IP -> В реджект (даже не в спам и ни отправитель ни получатель не узнает, что письмо не дошло и вообще было)
Пришло больше 200 писем за час -> В реджект (даже если до этого неделю не было ни одного письма)
Логически это удобнее, у меня на сервере 30 сайтов. Быстрее указать один раз IP чем 30 раз подтверждать на mail.ru
В FBL вырезали емейлы, кнопку выгрузки тех кому не интересно убрали из постофиса. И как быть? Что делать? Почему яндекс не дает убрать из рассылки тех кому не интересно читать наши письма?
Минус хэшей произвольной длины в том, что мы знаем у каких пользователей пароль короткий, а у каких длинный. И зная длину пароля, можно сразу начать брутфорсить только администратора с самым коротким паролем.
Опять же зависит от стоимости информации. Я не отрицаю что в SHA-256 вероятность коллизии меньше чем в SHA-1, но и в MD5 и SHA-1 она крайне мала.
в парадоксе дня рождения всего 365 вариантов значения и 23 человека (6%)
в MD5 вариантов уже 3,4 × 10^38. т.е. даже если все 7 миллиардов человек зарегистрируются, вероятность коллизии будет очень мала и по большому счету ничего не даст. Даже в радужных таблицах вероятность коллизии будет на мой взгляд очень маленькой.
Для примера у меня 80 000 000 записей MD5, больше 4 байт коллизия бывает крайне редко.
Слишком просто вычислить.
Достаточно знать свой пароль.
На хабре проводилось исследование. Это приведет к увеличению вероятности коллизии и упрощению брутфорса (по радужным таблицам).
Не понятно чем это обосновано. Соль нужна чтобы по радужным таблицам не найти хэш. В редких случаях когда соль не доступна, при брутфорсе может быть и имеет смысл на жизнь то что вы говорите. Но при этом надо понимать, что стоимость исследований эффективности различных методов генератора случайных чисел затребует достаточно много человекочасов и скорее всего станет нерентабельной. Так же, хотелось бы увидеть код, которым вы сгенерировали картинку для rand(), так как рисунок больше похож на ошибку в программе, не может каждое 30 значение функции rand быть 100% предсказуемым в общем случае.
Так же если вы пишете о том, что нужно добавлять соль, обязательно надо указывать о порядке следования соли и пароля в хэширующей функции для неслучайной соли. Ибо если этот порядок неверный, от соли не будет никакого толку.
Тоже не понятно, откуда эта цифра и для какого алгоритма? Почему не 16 или почему не 256? Опять же каких символов? (a-z или 0x00-0xFF),
На примере того же md5 в радужных таблицах сейчас редко запись для пароля длиннее 10-12 символов. (псевдослучайных)
тоже сомнительный совет, откуда эта цифра?
Я как пользователь, если буду ждать секунду пока мой пароль будет проверяться, успею три раза уйти. Почему не 100 мс? Это уже будет не сотни миллионов паролей в секунду для перебора, а всего 10 в секунду.
Одно сообщение им на форум, где его никто не увидит и одно сообщение в роскомнадзор. А если у конкурента https, то вообще сказка.
Хотя уже сейчас спокойно могут заблокировать за слова «Чтобы сделать самоубийство надо (нужное дописать)»
Чтобы клоном не являлось поменять логотип и фон допустим ( ну или по минимуму чтобы это стал не клон )
Месяца как раз хватит перенести в поисковиках домен.
Разве что киберсквотеры зарегают кучу доменов :)
Суды же не могут банить по регулярному выражению?
Ну вернулась им 404 страница и все, это же не DDOS.
В моей практике было один раз что администратор заблокировал по IP и в этоге сам не мог попасть на сайт.
(Часто ботами могут быть обычные пользователи, зараженные вирусами, у многIих провайдеров IP динамические)
А практики когда из — за динамических IP живые клиенты не могли попасть на сайт очень много.
Тут как минимум надо смотреть георасположение IP и убедиться что IP не в зоне целевой аудитории и не среди провайдерских IP.
Даже к взломам я по большей части отношусь с интересом, отловить все скрипты и изменения на сайте дело пяти минут, поправить уязвимость еще 10 минут, а злоумышленник проделывает большую работу по тестированию продукта на безопасность в течении многих часов.
location /reestr/ { rewrite ^(.*)$ http://mirror.yandex.ru/debian-cd/8.1.0/amd64/iso-dvd/debian-8.1.0-amd64-DVD-3.iso?$1 break; }Память не переполнится, дескрипторы не закончатся.
Лучше делать редирект на файл размером в сотни гигабайт,
так у них или место закончится на сервере (памяти), или трафик с каналом закончится.