Всю жизнь был фанатом Apple'овских клавиатур. Причем использовал "полноразмерные" версии с дополнительным цифровым блоком, единственное неудобство - это то, что на них не было кнопки Insert, которую пришлось мапить на F13, чтобы хоть как-то пользоваться Insert'ом. Нравились они мне исключительно за небольшой ход клавиш. Недавно по совету знакомых решил попробовать механику NuPhy Air75 V2. Оказалась очень даже интересной. Умеет как по проводу, так и по Bluetooth, плюс в комплекте идет специальный ресивер для третьего режима связи на 2.4 GHz. При этом по Bluetooth используется три канала, т.е. можно спейрить её с тремя разными устройствами, например, телефоном, ноутбуком и стационарным ПК и в процессе работы переключаться между ними с помощью Fn + <номер_устройства>. В целом достаточно удобная штука, но после Apple'овской ножничной низкопрофильной клавиатуры ощущения абсолютно другие.
Можно ради интереса провести эксперимент, зарегистрировать новый аккаунт Google и попробовать привязать к нему российский номер телефона. Если SMS вдруг не придет, значит у Google действительно имеют место быть проблемы с отправкой сообщений на российские номера. Ну а вообще конечно рекомендации правильные - везде где только можно следует постепенно уходить от использования номера телефона в качестве второго фактора и использовать что-то более надёжное - TOTP, аппаратные ключи, passkey'и и т.п., благо что сервисы Google это позволяют.
По-поводу TigthtVNC - как сказал @Stkn по-умолчанию действительно loopback connections запрещены, поэтому либо поставить соответствующую галку в настройках сервера, либо просто запускать websockify.exe, используя адрес в LAN (т.е. lan_ip:5900). Плюс, у меня даже после этого постоянно возникала ошибка: "Client must support 'binary' or 'base64' protocol". Решил следующим образом:
При сдаче теста в заданиях где требуется рассчитать маску / определить увидят ли друг-друга хосты, находящиеся в определенных подсетях, можно использовать калькулятор IP или при сдаче обязательно считать «в уме»?
Вот как раз второй пункт и кажется наиболее очевидным решением. Т.е. чтобы оградить пользователей от нежелательного контента, достаточно сделать общероссийский сервис, по принципу того же Яндекс.DNS, подключившись к которому каждый пользователь сможет стать «белым и пушистым», т.е. перестать видеть нежелательный контент. Это действительно получится «безопасный интернет» на добровольной основе. Плюс активная реклама этого сервиса в социальных сетях, по ТВ и т.п. Т.е. чтобы пользователи сознательно приняли это решение и пользовались фильтрами, те же, кому это попросту ненужно — не использовали бы этот сервис. Однако, почему-то бюджет тратится не на развитие каких-то сервисов и не на повышение грамотности пользователей в целом, а на какие-то мифические запреты… Ок. Запустили «черный список» сайтов, создали структуру по контролю за этим и т.д. и т.п., но по факту все введенные ограничения эфемерны. На мой взгляд логичнее было бы подойти к решению вопроса «безопасности в интернет» несколько с другой стороны.
Эээммм… возможно комментарий покажется глупым, но что странного в том что Telegram синхронизировал со своими серверами контакты с чужой SIM-карты установленной в телефон? Хорошо, предположим что это не так явно… но можно привести простую аналогию. Например, на телефоне с установленным и активированным на наш номер Telegram'ом мы по каким-то причинам удаляем собственный Google аккаунт и вместо него добавляем аккаунт друга на время. Что при этом происходит? Правильно, записная книжка синхронизируется с аккаунтом Google, а уже оттуда контакты «расхватывают» и все остальные приложения, в том числе и Telegram. Такое поведение скорее всего покажется всем естественным. Так почему же синхронизация контактов в Telegram с аккаунтом Google кажется нам само-собой разумеющимся, а когда источник контактов другой (SIM-карта, вместо аккаунта Google), то чем-то из ряда вон выходящим?
p.s. Естественно, что нужно какое-то средство управления «оффлайн-контактами» в Telegram (т.е. контактами, которые уже были отосланы на сервера Telegram, но еще ни разу не воспользовавшиеся мессенджером, т.е. не имеющими собственного аккаунта), но большой проблемой это не назовешь. Т.к. топикстартер самостоятельно установил в телефон чужую SIM-карту на которой уже содержались контакты. Для тех кому такое поведение не нравится — никто не мешает собрать свою версию из исходников, которая не будет иметь доступа к контактам и не будет синхронизировать их.
Возможно определенная доля истины в ваших словах есть, т.е. я, например, допускаю что часть людей вообще не пользуется этими социальными сетями, так же, как я, например, не использую Facebook (не люблю его за «навязчивость» в отношении рассылок, «поиска друзей» и другие моменты), но в данном случае, согласитесь, аудитория этих ресурсов в Украине довольно большая. И если для ВК, ОК, к примеру, в качестве альтернативы можно назвать тот же Facebook, а для сервисов предоставляемых Mail.Ru и Яндексом — тот же Google (хотя тут надо понимать что Яндекс и Mail.Ru — это не только почта, но еще и куча востребованных сервисов), то в сфере бизнеса, например, того же 1С — особенных альтернатив в Украине нет (если я ошибаюсь, поправьте меня). И что делать предпринимателям в данной ситуации — не совсем понятно.
А retransmission пакеты не приходят? Т.е. если например сделать wget http://yandex.ru и посмотреть тем же Wireshark'ом ответ? Т.е. вполне возможно что первым приходит «поддельный» ответ от оборудования провайдера, а следом уже нормальный ответ от серверов Яндекса. Но т.к. «поддельный» ответ пришел быстрее, то система «воспринимает» именно его.
С EmerDNS как раз все понятно. Непонятно каким образом это будет способствовать получению доступа к заблокированным сайтам, особенно в варианте (который наиболее вероятен), когда доступ будет блокироваться не на уровне DNS, а по URL в случае с HTTP и по IP в случае с HTTPS. В любом случае тема DNS на BlockChain'е достаточно интересная, особенно для тех, кто никогда не сталкивался с подобным.
Вопрос следует поставить не так, а скорее, какой процент украинского бизнеса использует в работе конфигурации 1С разработанные для Украины. В моем понимании — это очень большой процент, а альтернатив как-то на ум не приходит.
Ссылки на соответствующие патчи для всех ОС приводили выше в виде текстовика. Я просто сделал wget -i urls.txt и скачал их все «про запас» на съемный HDD. Абсолютно все приведенные ссылки рабочие.
В новостях вообще много что пишут, только сейчас смотрел какой-то YouTube ролик, RIP с ТВ, где «многоуважаемый эксперт» (специально найденный редакцией телеканала) рассказывал что-то вроде: да, этот вид угроз, трояны-шифровальщики достаточно не нов и работает по хорошо отлаженной и давно известной схеме и в качестве рекомендаций что-то вроде: «Здесь человеческий фактор играет существенную роль. Здесь важно не открывать какие-то ссылки и письма, которые пришли неизвестно от кого». Это-то и так понятно, а вот рассказать о пути проникновения, о незакрытой уязвимости и т.п. — про это ни слова.
p.s. Я к тому что разные СМИ будут спекулировать на этой теме еще ой как долго… и ракурсы в которых все это можно преподнести достаточно разнообразны. Вплоть до «вторжения инопланетян» ;)
«При обработке этого адреса первоначально будут отправлены запросы на порты 139 (NetBIOS Session) или 445 (Microsoft-DS Active Directory, Windows shares). Если эти порты будут закрыты, то жертва отправит NetBIOS Name Service (NBNS) NBSTAT сообщение на 137 порт, тем самым открывая UDP-тоннель и позволяя злоумышленнику слать запросы прямиком жертве, минуя NAT и Firewall.»
Чисто теоретически — возможны любые варианты. Исход с «прорывом» окружения VirtualBox рассматривается скорее всего как менее вероятный, однако, при таком эксперименте лично я бы настроил сетевой адаптер виртуальной машины так, чтобы он вообще не имел доступа к локальной сети, т.е. только вовне. Например, если предположить что после заражения уязвимая машина начинает сканировать и локальную сеть в поисках уязвимых ПК — то результат подобного эксперимента предсказуем. В случае же когда виртуальная машина будет иметь только доступ к WAN и больше ни к чему — такой исход сведен к минимуму. Ну и плюс, кто его знает что там придумали авторы вымогателя. Например в целях затруднения анализа он вообще может не запускаться в виртуальном окружении, определить что процесс запущен под VirtualBox, VMWare или другими средствами виртуализации достаточно просто.
5 копеек в тему: в моей сети все машины за NAT'ом, естественно что снаружи 135, 137, 139 и 445 закрыты. Но где-то с полгода назад, прочитал здесь же или на Хабре об интересном методе атаки (подробности, номер уязвимости и т.п., к сожалению не вспомню, если кому-то тема близка — дополнят), смысл которой заключался в том, что при посещении определенных web-ресурсов подверженные уязвимости ПК сами открывали исходящее соединение во вне на один из портов 135, 137, 139, 445 (по-моему уязвимость носила название BadTunnel), после чего устанавливался UDP туннель (если память не подводит, то частично эксплуатация этой уязвимости была связана с WPAD) и если машина была уязвима, то весь ее трафик мог быть перенаправлен через сервер злоумышленников. Поэтому еще тогда я запретил любые исходящие во вне, т.е. вне диапазона локальных подсетей на 135-139,445 TCP + UDP. Так что «кризис MS17-010» прошел для меня незаметно.
Всю жизнь был фанатом Apple'овских клавиатур. Причем использовал "полноразмерные" версии с дополнительным цифровым блоком, единственное неудобство - это то, что на них не было кнопки Insert, которую пришлось мапить на F13, чтобы хоть как-то пользоваться Insert'ом. Нравились они мне исключительно за небольшой ход клавиш. Недавно по совету знакомых решил попробовать механику NuPhy Air75 V2. Оказалась очень даже интересной. Умеет как по проводу, так и по Bluetooth, плюс в комплекте идет специальный ресивер для третьего режима связи на 2.4 GHz. При этом по Bluetooth используется три канала, т.е. можно спейрить её с тремя разными устройствами, например, телефоном, ноутбуком и стационарным ПК и в процессе работы переключаться между ними с помощью Fn + <номер_устройства>. В целом достаточно удобная штука, но после Apple'овской ножничной низкопрофильной клавиатуры ощущения абсолютно другие.
Можно ради интереса провести эксперимент, зарегистрировать новый аккаунт Google и попробовать привязать к нему российский номер телефона. Если SMS вдруг не придет, значит у Google действительно имеют место быть проблемы с отправкой сообщений на российские номера. Ну а вообще конечно рекомендации правильные - везде где только можно следует постепенно уходить от использования номера телефона в качестве второго фактора и использовать что-то более надёжное - TOTP, аппаратные ключи, passkey'и и т.п., благо что сервисы Google это позволяют.
https://rawcdn.githack.com/andreacorbellini/ecc/865b8f9e79ed94a9d004a9b553f4b3add55878be/interactive/modk-add.html - можно использовать сервис https://raw.githack.com/ . Исходники скриптов визуализации тут - https://github.com/andreacorbellini/ecc .
По-поводу TigthtVNC - как сказал @Stkn по-умолчанию действительно loopback connections запрещены, поэтому либо поставить соответствующую галку в настройках сервера, либо просто запускать websockify.exe, используя адрес в LAN (т.е. lan_ip:5900). Плюс, у меня даже после этого постоянно возникала ошибка: "Client must support 'binary' or 'base64' protocol". Решил следующим образом:
Воспользовался рекомендациями отсюда - https://stackoverflow.com/questions/15962359/websockify-error-client-must-support-binary-or-base64-protocol и заменил в двух местах noVNC-master\core\rfb.js и noVNC-master\core\websock.js параметр this._wsProtocols и protocols на массив ['binary', 'base64'] .
Выбрал порт отличный от 5091 для websockify.
После этих двух изменений, все сразу запустилось. Использовавшая версия TightVNC - tightvnc-2.8.59-gpl-setup-64bit.
p.s. Естественно, что нужно какое-то средство управления «оффлайн-контактами» в Telegram (т.е. контактами, которые уже были отосланы на сервера Telegram, но еще ни разу не воспользовавшиеся мессенджером, т.е. не имеющими собственного аккаунта), но большой проблемой это не назовешь. Т.к. топикстартер самостоятельно установил в телефон чужую SIM-карту на которой уже содержались контакты. Для тех кому такое поведение не нравится — никто не мешает собрать свою версию из исходников, которая не будет иметь доступа к контактам и не будет синхронизировать их.
p.s. Я к тому что разные СМИ будут спекулировать на этой теме еще ой как долго… и ракурсы в которых все это можно преподнести достаточно разнообразны. Вплоть до «вторжения инопланетян» ;)
«При обработке этого адреса первоначально будут отправлены запросы на порты 139 (NetBIOS Session) или 445 (Microsoft-DS Active Directory, Windows shares). Если эти порты будут закрыты, то жертва отправит NetBIOS Name Service (NBNS) NBSTAT сообщение на 137 порт, тем самым открывая UDP-тоннель и позволяя злоумышленнику слать запросы прямиком жертве, минуя NAT и Firewall.»
p.s. Как видите, «в кучу» я ничего не собирал…