• Сколько бpyтфopcить такой пароль?

    @DaNHell
    Change the world
    Да замечательная штука как плановая смена паролей взята не из воздуха, и не по чей то хотелки.
    Рассчитывается из параметров: алгоритм хеширования, минимальные требования к паролю и ~кол-во юзеров.
    В булке например md5(md5($salt).md5($pass)) скорость брута через cuda среднего класса - 152.0 MH/s (150 миллиона хешей в секунду)!
    Ну это конечно прогресс, 21 век.

    Довольно старая таблица, но все-же
    8tvdxh2.png

    Но это мы говорим про полный перебор.
    Но атаки по маске/правилам/словарям/гибридные и конечно же по радужным таблицам делают свое дело на ура.
    Грубо говоря имея дамп 100к юзеров login : (md5), в течении 3-5 минут получаем результат в более чем 50% подобранных паролей.

    Да и также стоит отметить что увеличивать длину пароля конечно же стоит, увеличив на 2 символа (с 10 до 12) грубо говоря усложняем задачу подбора в 300-500 раз.
    НО: Учитывая что это не просто добавление хоть еще 6-8 букв (словосочетаний) словарных/алфавитных.
    Т.е. ItsGoodPassword даже увеличив до ItsReallyVeryGoodPassword пароль, противостоять сможет всего пару секунд гибридной атаке.

    На 2008 год брут через GPU (UPPER CASE + lower case + digs + symbols)
    • all 6 character password MD5s 3 seconds
    • all 7 character password MD5s 4 minutes
    • all 8 character password MD5s 4 hours
    • all 9 character password MD5s 10 days
    • all 10 character password MD5s ~625 days
    • all 11 character password MD5s fuggedaboudit

    Но на получение 12 символьного пароля ушло далеко не несколько лет, а всего 75 дней.

    P.S. От себя добавлю отличный совет: Если есть возможность - используйте нетрадиционные раскладки языка, спец. символы (которые не так уж и сложно прописывать - FAQ По винде поможет).
    Ну а если еще и закреплять это все стойкостью пароля.. То вы в защите от криптографических атак... но далеко не в абсолютной безопасности...
    Ответ написан
    1 комментарий
  • Как быстро освоить Kubernetes?

    @ProFfeSsoRr
    Сис.админ по Linux
    Существует уже достаточное количество литературы
    нет, не существует - проект очень быстро развивается, литература так быстро не выходит.
    По поводу "как познавал" - есть установка кластера через kubeadm, это утилита от, собственно, разработчиков kubernetes, и есть the hard way от Келси Хайтауэра https://github.com/kelseyhightower/kubernetes-the-... Есть популярный ансибл kubespray, сделанный вокруг kubeadm - но я его не юзал, я написал себе ансибл-роль сам, пока разбирался. Т.к. поднять кластер с одним мастером на kubeadm - это не так уж долго и не особо сложно. Также я ставил сразу на containerd, чтобы не боротся с проблемами докера (например он поднимает свою сеть, что только мешает кубу, и т.д.).
    Окей, вот ты поднял кластер с одним мастером и одной рабочей нодой (лучше хотя бы двумя, если ресурсы позволяют). Дальше надо что-то в кластере запустить - если у тебя есть какое-то простое приложение с вебсервером, в идеале уже собранное в контейнер - вот попробуй его запустить. Потом, чтобы его высунуть наружу - поставь в кластер ingress controller, начни с ingress-nginx от комьюнити (есть еще nginx-ingress от разрабов nginx - он менее функционален, его берут в основном те, кто nginx plus купил). Проще всего ингрес-контроллер запустить с hostNetwork: true и "прибить" его к одному из воркеров куба - сможешь тогда туда перенаправлять трафик и так получить доступ к своему приложению правильным путём.
    Ну а дальше уже зависит от конкретных условий, от нагрузки, от приложений. Если у тебя не планируется запуск приложений с состоянием - можешь для начала держать 1 мастер, не заморачиваясь с мульти-мастером (особенно если запускаешь на виртуалках, чтоб просто целиком мастер бекапить), добавить мониторинг с помощью prometheus-operator, подключить своё приложение к мониторингу, поставить к примеру fluent-bit для сбора логов куда-то... Ну и т.д. :)
    Ответ написан
    Комментировать
  • Кто как задаёт уровень критичности триггеров в Zabbix?

    ky0
    @ky0
    Миллиардер, филантроп, патологический лгун
    Делать триггеры с выражениями, оперирующими не константами, а макросами - в этом случае можно для каждого хоста установить свой порог срабатывания триггера, а уровень оставить одинаковый. Ещё более гибко всё это можно настроить, совместив с правилами оповещений, установив для разных групп хостов разные действия и задержки перед отправкой.
    Ответ написан
    5 комментариев
  • Как организовать защиту от парсинга сайта?

    @starosta6123
    1. Сайт изначально предназначен для публикации, то есть он открыт.
    2. Если вы не хотите чтобы информация была открыта, не публикуйте.

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

    Бросьте это занятие!

    Не существует защиты созданной человеком, которую не возможно сломать, вопрос времени...
    Единственный путь, это шифрование с выдачей ключа клиенту. Но клиент - человек не надежен, и информация уплывет, вопрос цены!

    И еще раз бросьте это!

    Я тоже когда-то думал об этом, но ни к чему не пришел. Всякая защита усложняет систему и увеличивает количество ошибок. Пользователь быстрее уйдет с вашего сайта, только потому что из-за ошибки в скрипте полезные данные не получит.

    Последний совет: бросьте это!

    Единственное что может вам помочь, это не раскрывать полностью всю информацию о предмете, или разделить на несколько частей, но при этом не должно быть неудобства для посетителя. К примеру, скройте "количество зубцов в шестеренке", любую ключевую информацию, без которой "самолет не взлетит".

    А если хотите поиграться, то пришла в голову идея: перемешивание по определенному алгоритму текста, который потом восстанавливается, применение стилей для скрытия "фальшивых" слов или фраз. Например, задать стиль, который скрывает каждое второе предложение или слово. Но к сожалению, это ломается на ура! Но доставит радости для взломщиков :-)

    Извините, за столь большой сумбур!

    1. Динамические запросы. Ну доставят какую-то головную боль для взломщика, но это не так сложно, как кажется.

    2. Верстка. Не знаю про бан от поисковиков, но это тоже ломается. Просто убираете теги и все. Просто в парсер добавляется "умный" фильтр. Можно конечно где-то картинку заменить фоном, или часть текста картинкой, но и на это можно сделать разборщик.

    3. Блокировка по IP не прокатит, так как могут пострадать реальные люди, достаточно применять динамический IP.

    А вообще, если хотите спастись от простых парсеров, то комплекс мер может помочь. Так же могу натолкнуть на идею, того, что парсеры обычно очень активны, и по количеству запросов с одного IP, по USER_AGENT, и другим меткам, а так же по отсутствию javascript, по обработке тега <МЕТА> redirekt.info/article/redirekt-na-html-s-zaderzhko... (отложенный редирект) и другим признакам. Можно запихнуть скрытую картинку (style="display: none"), большинство парсеров ее могут дернуть (зависит от настроек).

    В общем, можно поставить задачу в другом ключе: "Расстановка ловушек для парсеров". То есть ловить на том, чего обычные люди и браузеры делать не будут. Например, заполнять "скрытое поле пароль". Удачные ловушки дадут вам возможность выявить подставных, но лучше делать несколько проверок, а то можно и реального пользователя забанить. А я бы не стал банить, а сливал бы немного или частично измененную инфу. Эта инфа может стать маркером для выявления того, кто действительно желает с вас "слить".

    Все, удачи!
    Ответ написан
    4 комментария