Как стать автором
Обновить
4
0
Сергей @Mur81

Сисадмин

Отправить сообщение
IPsec точно в 1809 сломан. Затронуло ли DC проверять желания нет, но там и кейс специфический что бы оно проявилось.
Артём, в Windows Release Health перечислены исправления для всех релизов Win 10 кроме 1809 и, соответственно, Windows Server 2019. А статусы по проблемам c IPsec и DC так и висят как не решённые. Если посмотреть описание проблемного KB, то проблема с IPsec так же значится не решённой, но для проблемы с DC написано ставить KB5010790. Это KB для релиза 1607 и для 1809 оно не подходит (я уже проверил).
За что так обделили пользователей Win 10 LTSC 1809 и 2019-го сервера? Я понимаю, что это вероятно ошибка и просто забыли. Но номера-то нам надо где-то взять.
И как это противоречит тому, что по умолчанию используется именно отвратительный 3DES?

3DES не используется по умолчанию. Будет использован наиболее лучший протокол согласованный обоими сторонами (в теории). И если удалённая сторона не согласует AES, то винда в этом не виновата.
Здорово, а теперь Вы можете предоставить ссылку на документацию где это чётко прописано? Я выше указал такую ссылку прямо на документацию от Microsoft, теперь жду ответа от Вас.

Извините, но какую ссылку я должен предоставить? И почему вообще я что-то должен?
Позволю себе напомнить Ваше изначальное утверждение:
Потому что встроенный в Windows клиент вообще, на мой скромный взгляд, не надо использовать, ибо там из протоколов шифрования только дырявый и архаичный 3DES.

Т.е. Вы утверждали, что там только 3DES. Я написал, что это не правда. Несмотря ни на какую документацию (которую возможно 100 лет уже не обновляют).
Если угодно вот описание командлета Set-VpnConnectionIPsecConfiguration. Там можно ознакомиться со списком поддерживаемых стандартов.
Благодарю! По этим ссылкам информация представлена определённо в более систематизированном и удобном для восприятия виде чем в описаниях конкретных обновлений на support.microsoft.com.
Скажите пожалуйста, известно ли что-нибудь по поводу сломавшегося IPsec'а? Я смотрю проблема до сих пор не посвилась в «Known issues». Это наводит на мысли, что факт её наличия не признан и решение не ищется.
Так же и по проблеме с Hyper-V интересует. Не знаю правда насколько она массовая. Но вот по IPsec'у в этом точно сомневаться не приходится.
Ну во-первых минус влеплял не я, т.к. если обратите внимание, то у меня карма не позволяет делать что либо подобное.
Во-вторых я предполагаю, что у Вас соединение откатывается на устаревшие протоколы по причине того, что современные не поддерживаются удалённой стороной. Либо вручную что-то наверчено с протоколами. Я честно говоря не вдавался в подробности как именно у MS это работает. Но по умолчанию совершенно точно используются именно те протоколы, что я выше написал. Это я говорю как практик который поднимает эти соединения до собственных роутеров и там, соответственно, я совершенно чётко понимаю какие протоколы разрешены и какие используются в данный момент.
Это не правда.
Там используется SHA1/AES128 (при настройке «шифрование данных: обязательное»), либо SHA1/AES256 (при настройке «шифрование данных: самое стойкое»).
Закрытые важные уязвимости:
CVE-2022-21849 — Windows IKE Extension Remote Code Execution Vulnerability (CVSS 9.8)

Поломался IPsec.
CVE-2022-21901 — Windows Hyper-V Elevation of Privilege Vulnerability (CVSS 9.0)

Поломался Hyper-V.
CVE-2022-21893 — Remote Desktop Protocol Remote Code Execution Vulnerability (CVSS 8.8)
CVE-2022-21850 — Remote Desktop Client Remote Code Execution Vulnerability (CVSS 8.8)

Поломался RDP (см. Known issues)

При изучении остального списка возникают мысли о потенциальных проблемах с Active Directory и еще бог знает с чем. Печально.

Я думаю имелось в виду, что пользователи начнут звонить провайдеру когда у них отвалится VPN до работы. Всё таки Интернет по L2TP/PPTP сейчас уже редкость. Обычно используют либо PPPoE, либо прямое подключение.

По наличию этого бага в Windows 8.1 кто-то может уже прокомментировать?

Во-вторых, проблемы бы не было, если бы владельцы системы «умного дома» воспользовались фичей для защиты контроллеров и установили пароль самостоятельно. Будучи незадействованной, эта функция принесла больше проблем, чем пользы.

Это на самом деле весьма спорное утверждение. Потому что подавляющее большинство обычных людей к паролям относятся примерно так:
1. Ой, здесь надо поставить какой-то пароль
2. Поставлю «123456»
3. Система — не даёт поставить простой пароль
4. Пользователь — ставит какой-то более сложный пароль
5. Проходит 30 минут
6. Пароль успешно забыт (ведь его же всегда можно восстановить через e-mail/телефон, не так ли? сервисы всех приучили к этому)

Я хочу сказать, что если в обслуживающей организации бардак (а чаще всего так и есть), то забыть (здесь подошло бы более жёсткое слово) пароль шансов на порядки больше чем подвергнуться атаке хакеров. А если систему ставил подрядчик без дальнейшего принятия на обслуживание, то они тоже не будут ставить пароль. Потому они его передадут заказчику, а он см. выше. А при таком подходе вендора, когда забытый пароль просто окирпичивает устройство без возможности даже сброса к заводским настройкам, делает ситуацию вдвойне пикантной.
Не ставить пароль это не правильно сточки зрения инфобеза. Но в жизни это именно так и происходит.
И что происходит дальше? Производитель высылает пароль которым можно разблокировать устройство без потери конфига/данных? Ну это тоже такое себе в плане безопасности.
Обычно на подобных девайсах есть аппаратная кнопка позволяющая сбросить пароль вместе с конфигом/данными. Да, тоже не приятно, но хотя бы без демонтажа устройства и отправки его производителю на замену (это конечно бред полный). Некоторые устройства ещё и имеют настройку позволяющую отключить такую возможность если владелец вдруг решил, что оно ему не надо.

Ну так это же не редкость. В чём сарказм и состоял.

Правоохранители не смогли связать эти данные с какой-либо конкретной платформой или компанией. Тем не менее, тот факт, что эти пары логин/пароль были размещены в облачном хранилище неизвестными преступниками...

Почему собственно они решили, что это преступники? Может какой-то сервис хранил там свою базу. Удобно и быстро разворачивается. Всё как они любят.
Никогда не понимал зачем вообще рядовому пользователю иметь возможность добавлять машины в домен. Если такая надобность вдруг возникнет, то администратор мог бы дать такую привилегию осознанно при помощи GPO. Но нет же — это дефолтная настройка [facepalm]. И надо наоборот — отключать эту возможность руками в GPO. Но для этого нужно ещё об этом знать.
Я много лет покупаю в Никсе батарейки Maxell (made in Japan) и очень ими доволен. Цена на данный момент 174 руб за 5 шт (35 руб за штуку). Буду рад видеть их в тесте, по возможности.

Udp: Зашел сейчас на WB и открыл для себя, что у этого бренда есть несколько видов батареек в формфакторе CR2032. Я покупаю те, что в красной упаковке с надписью «For calculator».

На последних версиях андроида, к слову, такое же поведение по умолчанию

Обходное решение — назначить слово типа «щИгёрЖ6В9Т» (все требования соблюдены).

В ПСБ можно отключить всю идентификацию по мобильному телефону/SMS и входить в банкинг по логину/паролю + одноразовый код с пластиковой карточки, которую выдают в отделении (на 100 кодов). За давностью лет не могу правда утверждать, что там при заключении договора не спрашивали кодовое слово, но по крайней мере при входе в ДБО его не требуют.
Я прошу меня правильно понять. Я ничего не имею против космических туристов. Даже если их будет отправлять не частник, а государство в том числе и наше. Это даже хорошо — это позволяет заработать денег и вложить их в дальнейшее развитие технологий.
Но я хочу две вещи:
1) Не надо мне из каждого утюга рассказывать, что это невиданное достижение.
2) Не надо делать это за мои деньги. Логично, что турист должен оплачивать свой полёт из своего кармана, а не из моего.

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность