«Зачем» — вопрос неправильный. Правильно спрашивать «почему».
Все провайдеры обязаны как-то блокировать запрещенные сайты. При этом вариант «за меня все блокируют мои аплинки» прокуратуру не устраивает. Вот и получается бессмысленная комбинация из двух разных методов блокировки (скажем, местный провайдер блокирует по DPI, а вышестоящий — путем подделки DNS-ответов).
Совершенно непонятно для меня сочетание DPI и подмены А-записей, или перенаправления на свой DNS. Я не могу ответить на вопрос, кому в голову пришло так делать, и зачем.
А для меня вполне понятно. Это может быть комбинация блокировок от этого провайдера и от вышестоящего, по двум разным технологиям.
Раз уж вы все равно собрались писать вторую статью, неплохо бы в ней привести обоснование, почему перемешивание отсчетов входного сигнала помогает. Т.е. сделать без него и ткнуть носом, что получилось хуже. А то будет контраргумент, что (с малой вероятностью) в случайной последовательности может встретиться какой угодно кусок, и нет каких-либо оснований считать, что похожие на фрагмент перемешанной картинки куски будут встречаться чаще, чем похожие на фрагмент неперемешанной.
Я всё искал методику, которая бы позволила быстрее искать кусок сигнала в другом случайном сигнале
В вашем случае, когда начало куска может быть где угодно в случайной последовательности, трюк с преобразованием Фурье заведомо дает точный результат за время порядка O(M log M), где M — просматриваемая длина случайной последовательности (т.е. индекс, дальше которого мы в нее не заглядываем). Ускорение возможно за счет следующих соображений.
1. Отказ от возможности начинать кусок с произвольного места в случайной последовательности. Тупо режем ее на последовательные (без перекрытия) кусочки фиксированной длины, как для классического векторного квантования. Тогда можно просто вычислить скалярное произведение куска входной последовательности с каждым из «эталонных», и это займет всего O(M), где M — сумма длин этих самых эталонных кусков. Сэкономили log(M) вычислений и log(M/N) бит на кусок в выходном потоке, где M/N — длина куска, ценой некоторой потери качества.
2. Отказ от требования найти наиболее похожий кусок в пользу «достаточно похожих». На этом пути классикой являются k-d деревья. Но если хочется набросать что-то на скорую руку, что работает немного хуже (но все равно в разы быстрее, чем честный перебор из п. 1), то вот еще простой алгоритм.
Как уже сказано, есть N эталонных кусков сигнала, много входных кусков и какая-то функция похожести одного куска на другой. Надо найти среди эталонных кусков какой-либо похожий на каждый входной (чем более похожий — тем лучше).
Заранее честным образом вычисляем функцию похожести для всех пар эталонных кусков (A, B). Для каждого эталонного куска A пишем в таблицу 8-16 (подобрать по результатам) номеров наиболее похожих других эталонных кусков. Полученную таблицу сохраняем.
Затем, когда очередной входной кусок будет известен, крутим такой простенький цикл (начиная с первого эталонного куска как с кандидата на роль достаточно похожего), пока он дает переходы на более похожий эталонный кусок. Зная, что эталонный кусок с номером A уже рассмотрен на предыдущем шаге, надо рассмотреть все 8-16 кусков, самых похожих на A согласно таблице, и выбрать среди них наиболее похожий на входной. Получается постепенное улучшение кандидата на роль достаточно похожего эталонного куска, но нахождение действительно наиболее похожего не гарантируется — что-то вроде локального максимума.
Собственно, Америку вы не открыли. В звуковых кодеках примерно то же самое применяется давным-давно, как правило, именно для высокочастотных диапазонов, и называется «векторное квантование». В том же Speex'е эта идея используется в комбинации с линейным предсказанием. Правда, там не говорится явно о псевдослучайной последовательности, но суть та же — имеем N (где N зависит от целевого битрейта) «кусков» звука, кодировщик пишет номер наиболее похожего.
Пакеты наружу таки уходят. Злоумышленник их tcpdump'ом видит. Просто на машине злоумышленника эти пакеты не попадают ни в INPUT, ни в FORWARD (проверял через -j LOG). Если использовать в качестве MAC'а назначения не ff:ff:ff:ff:ff:ff, а MAC злоумышленника, то и tcpdump видит, и протоколируется, и через NAT проходит, и возвращается. Только толку от этого нет, т.к. надо знать MAC.
Еще непроверенная идея: со шлюза послать nping'ом какой-нибудь UDP-пакет с произвольным заспуфленным IP источника, с самим шлюзом в качестве IP назначения, и с broadcast'ом (ff:ff:ff:ff:ff:ff) в качестве MAC'а назначения. По идее, такое должно пройти через NAT (где бы он ни был), вернуться, и тем самым выдать себя.
Еще предлагаю со шлюза попинговать жертву. Или послать какой-нибудь пакет на закрытый порт. Правильно ли я понимаю, что ICMP-ответ или TCP RST пойдет через NAT и тем самым спалит посредника через IP источника?
По третьему найденному фрагменту — как cppcat догадывается, что имеет место именно deallocation? Какой-то словарь подстрок, которые, если встречаются в имени, с большой вероятностью указывают на разрушительный характер функции?
узел источник трафика имеет на интерфейсе одним из адресов указанный в качестве адреса назначения
Объясняю. Железка хотела поговорить сама с собой или принять чей-то траффик. Только в этот момент один из ее IP-адресов был (временно) снят, и она отправилась его искать согласно таблице маршрутизации.
При обычном логауте предлагаю просто стирать куку. Это не требует ввода пароля и не затрагивает другие устройства.
Для использования функциональности «логаут на всех устройствах» пользователь в моей схеме действительно должен ввести пароль. Впрочем, я эту функциональность в явном виде могу и не предоставлять. Достаточно фразы «Если вы подозреваете, что злоумышленники получили доступ к вашей учетной записи, смените пароль».
К недостаткам ПростоVPN.АнтиЗапрет: если настраивать на роутере, то работает только в одной из двух моих квартир. В квартире, где сервис не работает, роутер Buffalo WBMR-HP-G300H с OpenWRT и ADSL от Ростелекома. Неработоспособность проявляется в следующем: VPN поднимается, но по нему не всегда ходит траффик. Есть подозрение, что, из-за большого количества добавляемых по одному маршрутов, та сторона иногда успевает посчитать роутер мертвым, пока он добавляет маршруты.
В квартире, где сервис работает, используется Ethernet-провайдер, роутер ASUS RT-N66U (более быстрый) и прошивка Tomato Shibby.
Функция «логаут на всех устройствах» в моем варианте как раз есть. Для этого достаточно поменять пароль (в том числе на тот же самый) — при этом изменится его соленый хеш.
Другое дело, что я забыл включить в куку и в подписанные данные идентификатор пользователя.
Поставил минус, так как описаны не все действия, которые должны производиться с токеном. Например, не сказано, как токен проверять, как эту табличку зачищать, что делать при смене пароля, каковы правила сосуществования нескольких токенов для одного пользователя.
Ну и при наличии минимальных знаний криптографии от таблички можно отказаться (см. Flask-Login): делать подписанную куку на основе секретного ключа, хеша от «соленого хешированного пароля», который уже есть в базе, IP и даты протухания. Грубо говоря:
hash(salted_password_hash) + date + ip, hmac(secret_key, hash(salted_password_hash) + date + ip)
При получении такой куки проверять все поля. Если не подходит hmac, неправильный IP, протухшая дата или несоответствующий хеш от «соленого хешированного пароля» — кука невалидна, пользователя по ней не пускаем, стираем. Если валидна — переставляем с новой датой протухания. Для каждого пользователя существует множество кук, по которым его пустило бы. Это не проблема, так как для выставления фальшивой, но валидной куки необходимо взломать hmac или украсть с сайта секретный ключ.
Очевидно, элемент случайности уже есть в salted_password_hash в виде соли. Зачищать на стороне сервера ничего не надо, так как ничего не хранится, кроме того, что и так должно храниться вечно.
Также очевидно, что смена пароля (в том числе на тот же самый) сделает куки на других устройствах недействительными.
I don't know how useful the module-equalizer-sink is today in practice, but even if it is completely unusable, a first step should not be to remove the code, but to stop building it by default.
Не понимаю, при чем здесь РайффайзенБанк. У них сейчас SMS либо ридер, генерирующий одноразовые пароли, без которых ничего перевести невозможно. А по ссылке выше последнее сообщение от 02.12.2013.
P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.
Все провайдеры обязаны как-то блокировать запрещенные сайты. При этом вариант «за меня все блокируют мои аплинки» прокуратуру не устраивает. Вот и получается бессмысленная комбинация из двух разных методов блокировки (скажем, местный провайдер блокирует по DPI, а вышестоящий — путем подделки DNS-ответов).
А для меня вполне понятно. Это может быть комбинация блокировок от этого провайдера и от вышестоящего, по двум разным технологиям.
Раз уж вы все равно собрались писать вторую статью, неплохо бы в ней привести обоснование, почему перемешивание отсчетов входного сигнала помогает. Т.е. сделать без него и ткнуть носом, что получилось хуже. А то будет контраргумент, что (с малой вероятностью) в случайной последовательности может встретиться какой угодно кусок, и нет каких-либо оснований считать, что похожие на фрагмент перемешанной картинки куски будут встречаться чаще, чем похожие на фрагмент неперемешанной.
В вашем случае, когда начало куска может быть где угодно в случайной последовательности, трюк с преобразованием Фурье заведомо дает точный результат за время порядка O(M log M), где M — просматриваемая длина случайной последовательности (т.е. индекс, дальше которого мы в нее не заглядываем). Ускорение возможно за счет следующих соображений.
1. Отказ от возможности начинать кусок с произвольного места в случайной последовательности. Тупо режем ее на последовательные (без перекрытия) кусочки фиксированной длины, как для классического векторного квантования. Тогда можно просто вычислить скалярное произведение куска входной последовательности с каждым из «эталонных», и это займет всего O(M), где M — сумма длин этих самых эталонных кусков. Сэкономили log(M) вычислений и log(M/N) бит на кусок в выходном потоке, где M/N — длина куска, ценой некоторой потери качества.
2. Отказ от требования найти наиболее похожий кусок в пользу «достаточно похожих». На этом пути классикой являются k-d деревья. Но если хочется набросать что-то на скорую руку, что работает немного хуже (но все равно в разы быстрее, чем честный перебор из п. 1), то вот еще простой алгоритм.
Как уже сказано, есть N эталонных кусков сигнала, много входных кусков и какая-то функция похожести одного куска на другой. Надо найти среди эталонных кусков какой-либо похожий на каждый входной (чем более похожий — тем лучше).
Заранее честным образом вычисляем функцию похожести для всех пар эталонных кусков (A, B). Для каждого эталонного куска A пишем в таблицу 8-16 (подобрать по результатам) номеров наиболее похожих других эталонных кусков. Полученную таблицу сохраняем.
Затем, когда очередной входной кусок будет известен, крутим такой простенький цикл (начиная с первого эталонного куска как с кандидата на роль достаточно похожего), пока он дает переходы на более похожий эталонный кусок. Зная, что эталонный кусок с номером A уже рассмотрен на предыдущем шаге, надо рассмотреть все 8-16 кусков, самых похожих на A согласно таблице, и выбрать среди них наиболее похожий на входной. Получается постепенное улучшение кандидата на роль достаточно похожего эталонного куска, но нахождение действительно наиболее похожего не гарантируется — что-то вроде локального максимума.
См. github.com/torvalds/linux/blob/master/net/ethernet/eth.c, функцию eth_type_trans(). Она метит полученные пакеты с MAC'ом назначения ff:ff:ff:ff:ff:ff как PACKET_BROADCAST. А теперь см. github.com/torvalds/linux/blob/master/net/ipv4/ip_forward.c, функцию ip_forward(). Она в первую очередь отбрасывает все пакеты, помеченные не как PACKET_HOST.
Объясняю. Железка хотела поговорить сама с собой или принять чей-то траффик. Только в этот момент один из ее IP-адресов был (временно) снят, и она отправилась его искать согласно таблице маршрутизации.
Для использования функциональности «логаут на всех устройствах» пользователь в моей схеме действительно должен ввести пароль. Впрочем, я эту функциональность в явном виде могу и не предоставлять. Достаточно фразы «Если вы подозреваете, что злоумышленники получили доступ к вашей учетной записи, смените пароль».
В квартире, где сервис работает, используется Ethernet-провайдер, роутер ASUS RT-N66U (более быстрый) и прошивка Tomato Shibby.
В итоге и там и там настроил TOR.
Другое дело, что я забыл включить в куку и в подписанные данные идентификатор пользователя.
Ну и при наличии минимальных знаний криптографии от таблички можно отказаться (см. Flask-Login): делать подписанную куку на основе секретного ключа, хеша от «соленого хешированного пароля», который уже есть в базе, IP и даты протухания. Грубо говоря:
hash(salted_password_hash) + date + ip, hmac(secret_key, hash(salted_password_hash) + date + ip)
При получении такой куки проверять все поля. Если не подходит hmac, неправильный IP, протухшая дата или несоответствующий хеш от «соленого хешированного пароля» — кука невалидна, пользователя по ней не пускаем, стираем. Если валидна — переставляем с новой датой протухания. Для каждого пользователя существует множество кук, по которым его пустило бы. Это не проблема, так как для выставления фальшивой, но валидной куки необходимо взломать hmac или украсть с сайта секретный ключ.
Очевидно, элемент случайности уже есть в salted_password_hash в виде соли. Зачищать на стороне сервера ничего не надо, так как ничего не хранится, кроме того, что и так должно храниться вечно.
Также очевидно, что смена пароля (в том числе на тот же самый) сделает куки на других устройствах недействительными.
Ответили ( lists.freedesktop.org/archives/pulseaudio-discuss/2014-March/020177.html ):
P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.