дергать надо не на роутере, а на Windows, потому что по умолчанию Windows будет использовать начальный MTU 1500 и соответствующий ему MSS. Процесс обнаружения Path MTU в TCP это отдельная проблема и в нее достаточно часто упираются, но выглядит она обычно иначе.
TCP offload (connection offload) не пробовали отключать в параметрах сетевого адаптера? Пока вы его не отключили TCP соединениями по факту занимается не совсем Windows.
на реалтеках проблемы с офлоадом TCP встречались и чинились
Плейн-текстом пароли не передает, но шифрование еще хуже чем в TACACS. Я имею ввиду, что упирать именно на TACACS не стоит, потому что все зависит от используемого зоопарка - если поддерживается DIAMETER лучше использовать его, если у вас все на Cisco - то будет TACACS, но как правило есть еще и что-то, что поддерживает только RADIUS.
У схемы с TOTP есть моменты, которые делает ее хуже варианта с одноразовым OTP привязанным к конечному устройству, по крайней мере если они изначально не предусмотрены:
TOTP на самом деле не одноразовый
Если используется общий ключ, а не генерируется отдельный ключ на каждый девайс, то пароль можно переиспользовать, т.е. если потроянлено одно конечное устройство - на нем можно получить TOTP в момент входа и через него доступ к другому девайсу
Если генерируется ключ на каждый девайс - то они все равно где-то хранятся между бастионом и tacacs и это делает схему хуже, чем хранение одноразовых кодов привязанных к устройcтву
Почему пароли? Почему TACACS а не RADIUS/DIAMETER? RADIUS гораздо более поддерживаемый протокол, DIAMETER (RADIUS поверх TLS/DTLS) - гораздо более безопасный и умеет и UDP и TCP. И проблем с EAP них обычно не возникает (в TACACS+ нет стандартной поддержки EAP), можно авторизоваться не только паролями.
Тема с оптимизацией алгоритмов не раскрыта КМК, можно было бы на питоне сгенерировать дерево if'ов. Код конечно слегка вырастет, зато какой прирост производительности!
Можно на последовательность значений, чтобы срабатывало при memcpy(), например, но не суть, я думаю можно много векторов придумать которые не требуют выполнения кода.
любые обрабатываемые данные (например содержимое HTTP заголовка или HTTP запроса) будет проходить через регистры общего назначения. Даже содержимое ICMP ping пакета будет проходить через регистры общего назначения, потому что оно копируется в ответный пакет.
Закладка может активироваться, например, через определенное значение регистров общего назначения - такая закладка легко будет активироваться практически любым сетевым запросом
Microsoft вернул поддержку ARM-архитектуры еще в Windows 8 (aka Windows RT), для Windows 10/11 это одна из "родных" архитектур, соответственно есть Windows-приложения собранные под ARM и Wine ее поддерживает.
>А как быть если у нас в качестве MUA-веб интерфейс?(того же мейла или гугла). Браузерные плагины? А мобилки?
MTA-STS не требует поддержки в MUA, как следует из названия, он реалиуется на уровне MTA. Если вы используете интерфейс мейла или гугла, поддержка на уровне софта MTA-STS у вас уже есть. Если у вас свой домен в облачной почте, поддерживающей MTA-STS - вам достаточно опубликовать только политику MTA-STS, чтобы защитить входящие письма, для этого достаточно опубликовать текстовый файл на веб-сервере и TXT-запись в DNS, специального софта не требуется.
у MTA-STS и PGP / S/MIME совершенно разные цели и они друг друга не заменяют. PGP и S/MIME подтверждает Пете что письмо написал Вася и делает так что письмо адресованное Пете никто другой не прочитает. MTA-STS ни в коем случае не заменяет шифрование письма и электронную подпись, она защищает канал передачи данных. Без MTA-STS человек-по-средине во-первых, может знать сам факт передачи письма от Васи Пете, во-вторых, может им манипулировать, например сделать так, что Петя письмо не получит, хотя Вася получит уведомление о доставке.
Шифрование точка-точка имеет совершенно другие проблемы. Либо оно совершенно неуправляемо, т.к. требует чтобы пользователи управляли собственными ключами, либо оно превращается в криптографический цирк, когда их ключами управляет кто-то другой, типа "облачных ключей". Например, вы стали клиентом Банка Б. В какой момент и как вы обменяетесь с ним ключами электронной почты? Что делать если ключ утерян? Как переносить его на другое устройство? Все это более-менее решается в пропиетарных приложениях типа Viber, потому что есть единственная имплементация и разработчик можно однозначно сказать как. В федеративных сетях типа электронной почты слишком много вариантов реализаций этого "как", именно потому что это должно поддерживаться в MUA. Если у Банка Б 100,000,000 клиентов это делает PGP / S/MIME непригодным для использования в переписке с ними, как минимум для шифрования.
В этот эффект входит не только косметика, им называют увеличения продаж некоторых товаров в кризис в целом. Обычно есть рост спроса на недорогие domestic-товары и аналоги (и это даже без учета ухода брендов) - в той же статье в качестве примера приведено местное пиво.
Кого-то просто не было, кому-то мешал юный возраст, кому-то отсутствие допусков к военной сети США, поэтому "разрабов почтовика" на тот момент было человек 5, каждый со своим стандартом и нужен был стандарт который был бы обратно совместим со всеми. RFC 724 где фиксируется примерно такой формат заголовков для ARPA написан в 1977м году , более новые RFC писались (в основном) с обратной совместимостью с предшественниками, в т.ч. и первый стандарт для интернет RFC 822 в 1982м, потому что одномоментно переключить всех на новый стандарт невозможно.
Тогда письмо показывалось в текстовой форме и заголовки показывались "как есть", поэтому стандарт в основном определял как сгенерировать заголовки чтобы они были более-менее унифромными и читаемы для человека, а не как их машинно-распарсить + было несколько почтовых сетей со своими стандартами и нужен был стандарт который был бы обратно совместим со всеми.
оба формата валидны, в вашем примере John Doe это не отображаемое имя пользователя как в примере выше, а комментарий. В такой форме письма генерировал юниксовый mail (и до сих пор в некоторых системах так делает), комментарий генерируется по GECOS из /etc/passwd, в общем случае это был именно комментарий, он помимо имени может содержать много чего еще.
From: "John Doe" <john@example.com> (John Doe, system administrator, 712345678901 some street)
Они, небось, для обучения распарсили какой-нибудь stackoveflow. Осталось научить вопросы там же задавать если нужного кода не нашлось - и программа обгонит 90% программистов. 95% если на питоне.
дергать надо не на роутере, а на Windows, потому что по умолчанию Windows будет использовать начальный MTU 1500 и соответствующий ему MSS. Процесс обнаружения Path MTU в TCP это отдельная проблема и в нее достаточно часто упираются, но выглядит она обычно иначе.
TCP offload (connection offload) не пробовали отключать в параметрах сетевого адаптера? Пока вы его не отключили TCP соединениями по факту занимается не совсем Windows.
на реалтеках проблемы с офлоадом TCP встречались и чинились
Плейн-текстом пароли не передает, но шифрование еще хуже чем в TACACS. Я имею ввиду, что упирать именно на TACACS не стоит, потому что все зависит от используемого зоопарка - если поддерживается DIAMETER лучше использовать его, если у вас все на Cisco - то будет TACACS, но как правило есть еще и что-то, что поддерживает только RADIUS.
У схемы с TOTP есть моменты, которые делает ее хуже варианта с одноразовым OTP привязанным к конечному устройству, по крайней мере если они изначально не предусмотрены:
TOTP на самом деле не одноразовый
Если используется общий ключ, а не генерируется отдельный ключ на каждый девайс, то пароль можно переиспользовать, т.е. если потроянлено одно конечное устройство - на нем можно получить TOTP в момент входа и через него доступ к другому девайсу
Если генерируется ключ на каждый девайс - то они все равно где-то хранятся между бастионом и tacacs и это делает схему хуже, чем хранение одноразовых кодов привязанных к устройcтву
Почему пароли? Почему TACACS а не RADIUS/DIAMETER? RADIUS гораздо более поддерживаемый протокол, DIAMETER (RADIUS поверх TLS/DTLS) - гораздо более безопасный и умеет и UDP и TCP. И проблем с EAP них обычно не возникает (в TACACS+ нет стандартной поддержки EAP), можно авторизоваться не только паролями.
Тема с оптимизацией алгоритмов не раскрыта КМК, можно было бы на питоне сгенерировать дерево if'ов. Код конечно слегка вырастет, зато какой прирост производительности!
И это примерно сюда же, как это может удивлять носителей русского языка, где падежные окончания есть всегда, а предлоги - нет (друг - с другом)
Да, например анонсировано на arm https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2021 - и это замечательное место для закладки, потому что будет вызываться на любом memcpy. А пока на arm https://github.com/ARM-software/optimized-routines/blob/master/string/aarch64/memcpy.S - если ваши данные попадают в memcpy можно установить практически любую комбинацию регистров общего назначения.
Можно на последовательность значений, чтобы срабатывало при memcpy(), например, но не суть, я думаю можно много векторов придумать которые не требуют выполнения кода.
любые обрабатываемые данные (например содержимое HTTP заголовка или HTTP запроса) будет проходить через регистры общего назначения. Даже содержимое ICMP ping пакета будет проходить через регистры общего назначения, потому что оно копируется в ответный пакет.
Закладка может активироваться, например, через определенное значение регистров общего назначения - такая закладка легко будет активироваться практически любым сетевым запросом
Microsoft вернул поддержку ARM-архитектуры еще в Windows 8 (aka Windows RT), для Windows 10/11 это одна из "родных" архитектур, соответственно есть Windows-приложения собранные под ARM и Wine ее поддерживает.
В этой статье разбирались атаки через UGC в письмах и как их предотвращать.
Все обоснованные тесты IQ обязательно нормируются по возрасту, поэтому возраст не может влиять на величину IQ.
>А как быть если у нас в качестве MUA-веб интерфейс?(того же мейла или гугла). Браузерные плагины? А мобилки?
MTA-STS не требует поддержки в MUA, как следует из названия, он реалиуется на уровне MTA. Если вы используете интерфейс мейла или гугла, поддержка на уровне софта MTA-STS у вас уже есть. Если у вас свой домен в облачной почте, поддерживающей MTA-STS - вам достаточно опубликовать только политику MTA-STS, чтобы защитить входящие письма, для этого достаточно опубликовать текстовый файл на веб-сервере и TXT-запись в DNS, специального софта не требуется.
у MTA-STS и PGP / S/MIME совершенно разные цели и они друг друга не заменяют. PGP и S/MIME подтверждает Пете что письмо написал Вася и делает так что письмо адресованное Пете никто другой не прочитает. MTA-STS ни в коем случае не заменяет шифрование письма и электронную подпись, она защищает канал передачи данных. Без MTA-STS человек-по-средине во-первых, может знать сам факт передачи письма от Васи Пете, во-вторых, может им манипулировать, например сделать так, что Петя письмо не получит, хотя Вася получит уведомление о доставке.
Шифрование точка-точка имеет совершенно другие проблемы. Либо оно совершенно неуправляемо, т.к. требует чтобы пользователи управляли собственными ключами, либо оно превращается в криптографический цирк, когда их ключами управляет кто-то другой, типа "облачных ключей". Например, вы стали клиентом Банка Б. В какой момент и как вы обменяетесь с ним ключами электронной почты? Что делать если ключ утерян? Как переносить его на другое устройство? Все это более-менее решается в пропиетарных приложениях типа Viber, потому что есть единственная имплементация и разработчик можно однозначно сказать как. В федеративных сетях типа электронной почты слишком много вариантов реализаций этого "как", именно потому что это должно поддерживаться в MUA. Если у Банка Б 100,000,000 клиентов это делает PGP / S/MIME непригодным для использования в переписке с ними, как минимум для шифрования.
В этот эффект входит не только косметика, им называют увеличения продаж некоторых товаров в кризис в целом. Обычно есть рост спроса на недорогие domestic-товары и аналоги (и это даже без учета ухода брендов) - в той же статье в качестве примера приведено местное пиво.
Есть еще и "эффект губной помады" - обычно в кризисы продажи косметики не страдают, а в некоторых категориях - наоборот, заметно растут.
Кого-то просто не было, кому-то мешал юный возраст, кому-то отсутствие допусков к военной сети США, поэтому "разрабов почтовика" на тот момент было человек 5, каждый со своим стандартом и нужен был стандарт который был бы обратно совместим со всеми. RFC 724 где фиксируется примерно такой формат заголовков для ARPA написан в 1977м году , более новые RFC писались (в основном) с обратной совместимостью с предшественниками, в т.ч. и первый стандарт для интернет RFC 822 в 1982м, потому что одномоментно переключить всех на новый стандарт невозможно.
Тогда письмо показывалось в текстовой форме и заголовки показывались "как есть", поэтому стандарт в основном определял как сгенерировать заголовки чтобы они были более-менее унифромными и читаемы для человека, а не как их машинно-распарсить + было несколько почтовых сетей со своими стандартами и нужен был стандарт который был бы обратно совместим со всеми.
оба формата валидны, в вашем примере John Doe это не отображаемое имя пользователя как в примере выше, а комментарий. В такой форме письма генерировал юниксовый mail (и до сих пор в некоторых системах так делает), комментарий генерируется по GECOS из /etc/passwd, в общем случае это был именно комментарий, он помимо имени может содержать много чего еще.
From: "John Doe" <john@example.com> (John Doe, system administrator, 712345678901 some street)В целом формат подразумевался примерно такой
Где конкретно в евросоюзе англоязычная аудитория?
Они, небось, для обучения распарсили какой-нибудь stackoveflow. Осталось научить вопросы там же задавать если нужного кода не нашлось - и программа обгонит 90% программистов. 95% если на питоне.