По-поводу 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» прошел для меня незаметно.
«Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации.»
Если заказчик подразумевал под предметом исполнения договорных обязательств установку типовой конфигурации без какой-либо ее модификации, то к чему вообще были доработки? Нестыковка какая-то. Т.е. если заказчик утверждал что ему была нужная типовая конфа без доработок, то фактически она у него уже была и предмет спора как таковой не существовал.
Либо в приведенном абзаце что-то напутано, либо я чего-то не так понял.
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. Как видите, «в кучу» я ничего не собирал…
«Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации.»
Если заказчик подразумевал под предметом исполнения договорных обязательств установку типовой конфигурации без какой-либо ее модификации, то к чему вообще были доработки? Нестыковка какая-то. Т.е. если заказчик утверждал что ему была нужная типовая конфа без доработок, то фактически она у него уже была и предмет спора как таковой не существовал.
Либо в приведенном абзаце что-то напутано, либо я чего-то не так понял.
Без него компилятор ругался на std::generate_n… а в optimised.c добавил:
Может быть есть и более «красивое» решение для сборки под MSVC…