Вы выставляете наружу детали внутренней реализации, пусть даже прикрывая это благозвучным термином «internal». Ваш публичный интерфейс должен изначально быть написан таким образом, чтобы реализацию в любой момент можно было выбросить, полностью переписать с нуля, и ни один тест при этом не сломался, т.к. тестируется не конкретная реализация, а то, что с ее помощью будет достигнуто — а как конкретно, не особо важно.
И да, TDD заключается в том, что сначала пишется тест, а потом под него код. Вы же пытаетесь натянуть сову на глобус, написав сначала ущербный код, а потом пытаясь его протестировать, запрещая при этом его изменять. Если бы ваш сервис принимал делегат для `MessageQueue.Receive` и существующий экземпляр токена отмены, проблем бы с тестированием не было бы никаких, независимо от потоковой модели вашего сервиса.
Замокать конструктор CancellationTokenSource, у вас будет токен на момент начала теста. Выполнить `Start()`, дождаться `Receive()`, после этого протухнуть токен, дождаться очистки очереди задач, проверить сайд-эффекты.
Администрации: статьи на английском смысл имеют, когда это хорошие, грамотные статьи. Лично по моему мнению, данный пост не относится к этой категории.
IE7 все еще не основание не использовать современную версию языка. К счастью, у babel есть транспилеры даже в es3, а недостающий рантаймовый функционал, типа тех же ES6 Proxy, можно нахреначить либо через нативные расширения браузеров, либо тотальным опесочиванием.
Может проблема не в руте, а в mount-ах вида docker run --rm -it -v /:/rootfs busybox sh и полнейшем игнорировании авторами этих "разоблачающих" статей основных принципов работы неймспейсов? Докер запускается с правами рута. При установке докер говорит прямым текстом, что он увеличивает attack surface, поэтому к демону докера должен иметь доступ только рут и судоэры, и добавлять пользователя в группу докера — это риск для безопасности, т.к. фактически выдаются рутовые привилегии. Если кто-то невнимательно читает сообщения при установке, а потом делает из этого сенсацию...
tl;dr — не надо монтировать корневую фс хоста внутрь контейнера, а потом удивляться. Попробуйте лучше вырваться из обычного docker run --rm -it ubuntu и сделать с хостом хоть что-нибудь.
UPD: увидел в одной из ваших статей, что у контейнера якобы есть доступ к /dev/mem и /dev/sd*. Наверное, у меня неправильный контейнер, потому что вот, что лежит в моем /dev:
Горохов Арсений Анатольевич, в 1968 году (за 8 лет до PC от «Apple») создаёт персональный компьютер и получает на него патент!
Знаете ли вы, что первый в мире персональный компьютер был создан, отнюдь, не Стивом Джобсом и Стивом Возняком в гараже Пало-Альто, а простым советским конструктором Арсением Анатольевичем Гороховым в Омском НИИ авиационных технологий?
А вот современные бредографы летописцы с вами не согласны. Широко известный факт, что русские изобрели вообще все, включая Солнце и гравитацию.
Какие вопросы вы задали бы тому, кто проходит собеседование, претендуя на должность, требующую знания TypeScript?
Прочитайте этот список из 20 вопросов и ответов и объясните, почему их ни в коем случае нельзя использовать при отборе кандидатов со знанием TypeScript.
Я имел в виду чистый IP spoofing, т.к. в посте рассматривалась фильтрация конкретно кучи мусорных UDP, и предложение apapacy по выбрасыванию UDP в принципе, без сравнения адреса отправителя.
Найти умножитель это хорошо, но в случае с TCP невозможно (т.к. не получится закончить 3-way handshake, т.к. SYN ACK придет не на тот адрес). Если же уязвимые сервисы отвечают по UDP (как обычно и происходит), но для целевого узла на cloudflare настроено «выбрасывать весь UDP не глядя», то атака захлебнется даже без выяснения всех уязвимых подсетей.
К сожалению, мне особо нечего рассказать конкретно про BGP, т.к. на таком уровне никогда не приходилось работать, и знания мои по данной теме исключительно теоретические. Впрочем, если вы правы, и пограничные роутеры выбрасывают исходящие пакеты с некорректными адресами отправителя, то было бы логично предположить, что любые IP-пакеты с некорректными адресами отправителя будут выброшены, независимо от того, что используется поверх — UDP, TCP или любой другой протокол. Если же атакующий знает, через какую AS идут наружу его пакеты, он может безнаказанно представляться любым адресом из анонсируемых этой AS префиксов.
Если приложение не ожидает UDP, то можно смело выбрасывать его целиком. Но атакующий тогда может перейти на SYN-флуд по известному порту приложения, и т.к. у TCP адрес отправителя подделывается также легко, как и у UDP (хоть и установить подключение не удастся), общий принцип защиты останется прежним. Тут еще не показано, но скорее всего, Cloudflare может видеть номер AS, от которой пришли пакеты, что добавляет информации для фильтров.
Тут описана не атака, при которой нагружается целевое приложение (типа тяжелых POST-запросов к выдаче статистики за 100 лет) — от такой атаки cloudflare не особо поможет, только выдача токенов на стороне приложения и rate limiting.
Атакующий в сценарии статьи просто забивает канал целевого сервера кучей мелких запросов, полностью съедая ресурсы сервера на обработку («это нам? это не нам, выбросить») этих ненужных пакетов. В таком случае cloudflare сможет на своих мощных серверах отбросить большую часть мусорного трафика, пропустив только полезные пакеты, чем они и занимаются. Разница между сервером cloudflare и вашим сервером в ширине канала и доступной вычислительной мощности.
И да, TDD заключается в том, что сначала пишется тест, а потом под него код. Вы же пытаетесь натянуть сову на глобус, написав сначала ущербный код, а потом пытаясь его протестировать, запрещая при этом его изменять. Если бы ваш сервис принимал делегат для `MessageQueue.Receive` и существующий экземпляр токена отмены, проблем бы с тестированием не было бы никаких, независимо от потоковой модели вашего сервиса.
MessageQueue.Receive()MessageProcessorService.Start()но вообще мне не понравилось. Просто случайный набор звуков, без гармонии, без сюжета, без ничего.
Может проблема не в руте, а в mount-ах вида
docker run --rm -it -v /:/rootfs busybox shи полнейшем игнорировании авторами этих "разоблачающих" статей основных принципов работы неймспейсов? Докер запускается с правами рута. При установке докер говорит прямым текстом, что он увеличивает attack surface, поэтому к демону докера должен иметь доступ только рут и судоэры, и добавлять пользователя в группу докера — это риск для безопасности, т.к. фактически выдаются рутовые привилегии. Если кто-то невнимательно читает сообщения при установке, а потом делает из этого сенсацию...tl;dr — не надо монтировать корневую фс хоста внутрь контейнера, а потом удивляться. Попробуйте лучше вырваться из обычного
docker run --rm -it ubuntuи сделать с хостом хоть что-нибудь.UPD: увидел в одной из ваших статей, что у контейнера якобы есть доступ к /dev/mem и /dev/sd*. Наверное, у меня неправильный контейнер, потому что вот, что лежит в моем /dev:
бредографылетописцы с вами не согласны. Широко известный факт, что русские изобрели вообще все, включая Солнце и гравитацию.Найти умножитель это хорошо, но в случае с TCP невозможно (т.к. не получится закончить 3-way handshake, т.к. SYN ACK придет не на тот адрес). Если же уязвимые сервисы отвечают по UDP (как обычно и происходит), но для целевого узла на cloudflare настроено «выбрасывать весь UDP не глядя», то атака захлебнется даже без выяснения всех уязвимых подсетей.
Атакующий в сценарии статьи просто забивает канал целевого сервера кучей мелких запросов, полностью съедая ресурсы сервера на обработку («это нам? это не нам, выбросить») этих ненужных пакетов. В таком случае cloudflare сможет на своих мощных серверах отбросить большую часть мусорного трафика, пропустив только полезные пакеты, чем они и занимаются. Разница между сервером cloudflare и вашим сервером в ширине канала и доступной вычислительной мощности.