5 февраля 2021 года, спустя 9 лет и 36 дней после выхода версии 1.9 (31 декабря 2011), был анонсирован стабильный выпуск GNU inetutils-2.0
Inetutils — набор сетевых утилит GNU. В него включены: ftp (клиент и сервер), telnet, tftp, hostname, dnsdomainname, ifconfig, logger, ping, ping6, traceroute, whois, syslogd, talk, rlogin, rsh, и другие
( читать дальше... )
>>> Архив info-gnu
Суть произошедшего
В мае 2020 года была обнаружена группа выходных узлов, вмешивавшихся в исходящие соединения. В частности, они оставляли нетронутыми почти все соединения, но перехватывали подключения к небольшому количеству криптовалютных бирж. Если пользователи посещали HTTP-версию сайта (т.е. незашифрованную и неаутентифицированную), вредоносные узлы предотвращали перенаправление на HTTPS-версию (т.е. зашифрованную и аутентифицированную). Если пользователь не замечал подмены (например, отсутствия значка замка в браузере) и начинал пересылать важную информацию, эта информация могла быть перехвачена атакующим.
( читать дальше... )
>>> Блог Tor Project
Всех приветствую.
Столкнулся с необходимостью проверить стойкость веб-форм к прямому перебору. Есть одна единственная форма, без капч, без ханипотов и т.п., голый PHP без JS, но с cookie(уберу потом), метод POST. Какое ПО под Linux лучше всего подойдёт? Как местные админы экспериментируют?
Kali Linux не ставил, с Wi-Fi всё в порядке, я и правда из админского интереса, док-ва на странице профиля.
Можно залить на сервер и проверять localhost, но мне больше интересно, как на это отреагирует onion-сервис.
Спасибо.
Согласно RFC 4880, GnuPG использует симметричный сессионный ключ для шифрования сообщений даже в том случае, если этот сессионный ключ сам шифруется исключительно симметрично.
Это позволяет, например, шифровать сообщение одновременно и паролем, и открытыми ключами, и Диффи-Хеллманом(по схеме ECIES). Я экспериментировал на практике и столкнулся с одной странной особенностью GnuPG — цитирую RFC:
If the Symmetrically Encrypted Data packet is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases.
Тем не менее, сколько я ни искал, так и не нашёл способа задать несколько паролей с помощью gpg. Поиски на официальных ресурсах GnuPG также ни к чему не привели. Не понимаю: это я что-то делаю не так или GnuPG действительно не поддерживает все возможности, описываемые тринадцатилетним RFC 4880, хотя уже сейчас активно стремится соответствовать свежему и ещё не принятому RFC 4880bis?
Как всё же использовать несколько паролей?
Несколько дней назад на платформе Twitter от имени подтверждённых аккаунтов, среди которых Apple, Uber, Чанпэн Чжао (Binance), Виталик Бутерин (Etherium), Чарли Ли (Litecoin) Илон Маск, Барак Обама, Джо Байден, Билл Гейтс, Джефф Безос и другие — были размещены сообщения с адресом bitcoin-кошелька, в которых мошенники обещали удваивать суммы, переведённые на этот кошелёк.
Оригинальное содержание сообщений: «Feeling grateful doubling all payments sent to my BTC address! You send $1,000, I send back $2,000! Only doing this for the next 30 minutes.»
Перевод: «Буду рад удвоить все платежи, отправленные на мой BTC-адрес! Если Вы отправите 1000 долларов, я отправлю 2000 долларов! Но только в течение следующих 30 минут.»
На данный момент (17 июля) адрес мошенников был пополнен на 12.8 BTC (≈ $117 000), с его участием совершено 392 транзакции.
Судя по всему, атаку произвели злоумышленники, тесно связанные с сообществом, специализирующемся на атаках подменой СМС с целью компрометации двухфакторной аутентификации (SIM swap scam). Так, незадолго до массовой рассылки в Twitter, на сайте ogusers.com было опубликовано сообщение, автор которого продавал email-адрес любого аккаунта Twitter за $250.
Несколько позже были взломаны некоторые аккаунты с «примечательными» адресами, один из первых подобных аккаунтов — учётная запись @6 умершего в 2018 году «бездомного хакера» Адриана Ламо. Доступ к аккаунту был получен с помощью административных инструментов Twitter путём отключения двухфакторной аутентификации и подмены адреса электронной почты, используемого для сброса пароля.
Таким же образом был украден аккаунт @b. Украденная учётная запись и административные инструменты Twitter были запечатлены на этом снимке. Все сообщения на самой платформе со снимками инструментов администратора были удалены Twitter. Расширенный снимок панели администратора доступен тут.
Один из пользователей Twitter, @shinji (ныне заблокирован), опубликовал короткое сообщение: «follow @6», а также фото инструментов администратора.
Сохранились архивные записи профиля @shinji незадолго до событий со взломом. Они доступны по этим ссылкам:
Этому же пользователю принадлежат «примечательные» аккаунты Instagram — j0e и dead:
Утверждается, что аккаунты j0e и dead принадлежат печально известному СМС-мошеннику «PlugWalkJoe», который подозревается в проведении крупных атак СМС-подмены в течение нескольких лет. Также утверждается, что он был и возможно остаётся членом группировки СМС-мошенников «ChucklingSquad» и, вероятно, был замешан во взломе аккаунта CEO Twitter Джека Дорси в прошлом году. Взлом аккаунта Джека Дорси был произведён после проведения атаки СМС-подменой на AT&T, ответственна за атаку та же группа «ChucklingSquad»
За пределами сети PlugWalkJoe, судя по всему — 21-летний британский студент Джозеф Джеймс Коннор, на данный момент находящийся в Испании без возможности выезда из-за ситуации с COVID-19.
PlugWalkJoe был объектом расследования, во время которого была нанята следователь для установления связи с объектом. Следователю удалось добиться установления видеосвязи с объектом, переговоры происходити на фоне плавательного бассейна, фото которого позднее было опубликовано от имени Instagram j0e.
Кстати, существует достаточно старый minecraft-аккаунт plugwalkjoe.
Примечание: расследование не окончено. До окончания расследования не следует клеймить кого-либо, поскольку не исключено, что @shinji — лишь подставное лицо.
Первое вредоносное сообщение, ставшее широко известным, было опубликовано 15 июля в 17 часов по UTC от имени Binance, оно имело следующее содержание: «Мы стали партнёрами CryptoForHealth и возвращаем 5000 BTC». В сообщении содержалась ссылка на сайт мошенников, который принимал «пожертвования». Вскоре на официальном сайте Binance было опубликовано опровержение.
Как сообщает служба поддержки Twitter, «Мы обнаружили скоординированную атаку с применением социальной инженерии против наших сотрудников, имеющих доступ к внутренним инструментам и системам. Нам известно, что злоумышленники использовали этот доступ для перехвата контроля над популярными (в том числе подтверждёнными) учётными записями для публикации сообщений от их имени. Мы продолжаем изучать ситуацию и пытаемся определить, какие ещё вредоносные действия были совершены и к каким данным они могли получить доступ.
Как только нам стало известно об инциденте, мы немедленно заблокировали затронутые учётные записи и удалили вредоносные сообщения. Кроме того, мы также ограничили функциональность намного большей группы учётных записей, в том числе всех подтверждённых.
У нас нет никаких доказательств компрометации паролей пользователей. Судя по всему, пользователям не обязательно обновлять пароли.
В качестве дополнительной меры предосторожности и для обеспечения безопасности пользователей, мы также заблокировали все учётные записи, от имени которых были зафиксированы попытки смены пароля за последние 30 дней.»
17 июля служба поддержки опубликовала новые подробности: «По имеющимся данным, примерно 130 аккаутов были так или иначе затронуты злоумышленниками. Мы продолжаем выяснять, были ли затронуты непубличные данные, и опубликуем подробный отчёт, если это произошло.»
Тем временем, акции Twitter обрушились на 3.3%.
Не так давно Европол, NCA, Национальная жандамерия Франции и совместная следственная группа, сформированная при участии Франции и Нидерландов, провели совместную спецоперацию с целью компрометации серверов EncroChat путём «установки технического устройства» на серверы во Франции(1), чтобы получить возможность «вычислять и идентифицировать преступников с помощью анализа миллионов сообщений и сотен тысяч изображений».(2)
Некоторое время спустя после операции, EncroChat, обнаружив вторжение, разослал сообщение пользователям с рекомендацией «немедленно отключить и утилизировать ваши устройства».
Только в Соединённом Королевстве было арестовано 746 подозреваемых, изъято:
EncroChat представлял собой набор ПО и оборудования(модифицированные смартфоны) для организации коммуникаций с «гарантированной анонимностью, сквозным шифрованием, модифицированной платформой Android, двойной операционной системой, „самоуничтожающимися сообщениями“, „кнопкой паники“, уничтожением данных при множестве неверных попыток ввода пароля, secure boot, отключённым ADB и режимом восстановления»(3)
Платформа EncroChat на момент ликвидации насчитываля десятки тысяч пользователей(≈ 60 000) из разных стран, в том числе РФ. Стоимость модифицированных смартфонов составляла £1000, ПО — £1,500 за полугодовой контракт.
>>> Подробности
Продублирую сюда на всякий: Ликвидация EncroChat
Не так давно Европол, NCA, Национальная жандамерия Франции и совместная следственная группа, сформированная при участии Франции и Нидерландов, провели совместную спецоперацию с целью компрометации серверов EncroChat путём «установки технического устройства» на серверы во Франции(1), чтобы получить возможность «вычислять и идентифицировать преступников с помощью анализа миллионов сообщений и сотен тысяч изображений».(2)
Некоторое время спустя после операции, EncroChat, обнаружив вторжение, разослал сообщение пользователям с рекомендацией «немедленно отключить и утилизировать ваши устройства».
Только в Соединённом Королевстве было арестовано 746 подозреваемых, изъято:
EncroChat представлял собой набор ПО и оборудования(модифицированные смартфоны) для организации коммуникаций с «гарантированной анонимностью, сквозным шифрованием, модифицированной платформой Android, двойной операционной системой, „самоуничтожающимися сообщениями“, „кнопкой паники“, уничтожением данных при множестве неверных попыток ввода пароля, secure boot, отключённым ADB и режимом восстановления»(3)
Платформа EncroChat на момент ликвидации насчитываля десятки тысяч пользователей(≈ 60 000) из разных стран, в том числе РФ. Стоимость модифицированных смартфонов составляла £1000, ПО — £1,500 за полугодовой контракт.
P.S. А вот пользовались бы они Tor + PGP не со смартфонов, а с нормального ноутбука со свободной ОС — не поймали бы никогда.
Немного саморекламы: есть анонимный Ящик, работает только через onion-сервис Tor, не требует javascript, cookie и регистрации. Из метаданных только дата отправки сообщения(без часов, минут и секунд) и его размер, всё остальное должен указывать сам пользователь.
Шифровать сообщения пользователь тоже должен сам, а простейшая инструкция есть тут: http://7apievo4h7gelatn.onion/contact.html
Приглашается 
sekreti-gollivuda и все неравнодушные.
Как вы наверняка знаете, сегодня(1 июля уже наступило по МСК) РКН «должен был заблокировать анонимные сети, такие как Tor, I2P...»
Что же, предлагаю обсудить итоги этой блокировки!
Заранее хочу оговориться: я очень надеялся успеть закончить свой сайт полностью, чтобы как можно жёстче простебать паникёров, но несколько форс-мажоров и необходимость администрировать не один десяток(*вставить другие отговорки*), так что прошу строго не судить — материал готовится, я обещал статьи по настройке Tor — они будут. То, что я сейчас выложу, сделано впопыхах, так что прощу простить за возможные глупые ошибки.
Но мы отвлеклись... Так вот, предлагаю объявить сегодняшний выходной день днём анонимных сетей в целом и onionland в частности! Как говорит мой коллега: «An onion a day keeps the bad guys away».
И вам, дорогие друзья, я дарю:
1. Ящик. Это сервис для анонимной и конфиденциальной личной переписки. Доступен только через .onion, не просит включить всякие гадости вроде javascript, cookie, равно как и не требует регистрации:
http://prf6ovijrqcv23rkkih6573em5xuve4dsl65dk5f2kzdjijio6w5uqyd.onion/
Лоровцам разрешаю пользоваться этой штукой как личкой на форуме. Ъ, полностью совместим с консольными браузерами, лично я тестировал с Elinks. Самые ЪЪЪ могут проверить telnet, может даже заработает :^)
Пример оформления подобной «лички» смотрите в моём профиле. Там же найдёте дополнительные инструкции, если нужно.
Только не злоупотребляйте особо, база данных будет очищаться примерно раз в 3 месяца, но при перегрузке может быть очищена раньше. Ъ хранят сообщения только локально, а удалённые хранилища чистят сами.
2. И самое, пожалуй, главное и трудоёмкое — список полезных onion-сервисов, без мошенников, барыг, скриптошкольников и прочего. Вот он тут:
http://7apievo4h7gelatn.onion/nav/onions.txt
Сюда попали только самые «чистые» сервисы. Сейчас в обработке у меня ещё несколько сотен. Сканировать сети вручную — не самое простое дело, однако. Об этом легко забыть без постоянной практики.
И вы, кстати, очень даже можете мне помочь с этим, если хотите внести свою лепту в развитие нормального интернета, без шпионящих и вездесущих сетевых гигантов, с обилием персональных сайтов(!) и прочего добра, казалось бы, давно канувшего в лету.
При чём тут Линукс? А всё просто — вы можете мне помочь, прислав .onion-адрес вашего любимого дистрибутива. *BSD тоже приветствуются. Сейчас именно с Linux в списке туговато.
Присылать лучше в этот самый Ящик. Мой ключ можно взять тут: http://7apievo4h7gelatn.onion/mykey.asc
Да, кстати, горячо приветствую всех сторонников федерализации и/или децентрализации, параноиков и всех, кого волнует анонимность и безопасность, и всемерно советую поднимать onion-сервисы!
Делается это легко, основным сервисам особо не мешает, преспокойно будет работать даже на древнем железе.
Разумеется, подробная инструкция будет скоро доступна у меня на сайте, можно просто подождать. А пока попрошу особо по ссылкам не ходить — всё равно там только 404.
Так что можете присылать любые onion-сервисы, которые, на ваш взгляд, достойны быть известными. И заранее благодарю всех за помощь.
P.S. Для Ъ — в случае с onion-сервисами это не вы ходите по ссылкам, а ссылки ходят по вам.
Приветствую.
Интересует возможность использования (совершенной)прямой секретности с GnuPG(и другими реализациями PGP). GPG удобен своей гибкостью(пусть и требует от пользователя определённого опыта) и тем, что позволяет легко превращать любые данные в base64-шифротекст, предоставляя возможность обмениваться не только текстом, но и медиафайлами и целыми архивами.
Однако асимметричные криптосистемы, поддерживаемые GnuPG, статичны(ECC тоже) и работают только по «классической» схеме с использованием долговременных ключей. Использование постоянных ключей для шифрования подразумевает возможность восстановить переписку при компрометации единственного секретного ключа(дешифруются все сообщения одной стороны, легко предполагается содержание шифротекстов другой), что не позволяет обеспечить ни прямую, ни обратную секретности. Более того, единственный доступный способ аутентификации(ЭЦП) не предполагает отрицаемости сообщений, что ставит под угрозу обе стороны.
Должен уточнить, это вовсе не праздный теоретический интерес, на данный момент завершаются работы над системой обмена сообщениями через Tor, шифрование сообщений в которой возложено целиком на пользователя(защиту от стороннего наблюдателя, конечно, обеспечивает и Tor, но защиту от злого админа(меня) обеспечивают только сами пользователи). Соответственно, теоретические и практические наработки пойдут в руководство пользователя. Ссылку на систему я вам и всем желающим дам чуть позже, как только будет завершено оформление и наполнение сайта(сама система полностью готова).
Какой вариант я рассматриваю сейчас?
Рассмотрим ситуацию с двумя участниками обмена: Алисой(адресант, инициатор) и Бобом(адресат). Пошагово это выглядит так(предполагается использование RSA, но это работает с любым асимметричным алгоритмом, в т.ч. «постквантовым»):
При использовании такого подхода компрометация долговременных ключей раскроет только метаданные(когда и с кем устанавливалось соединение), но не позволит дешифровать основную информацию. Чтобы усложнить анализ содержимого по размеру криптограммы, каждое сообщение дополняется случайным количеством случайных данных в base64. Например так:
#!/usr/bin/env bash
randexp=$(cat /dev/urandom | tr -dc '1-3' | head -c1)
randbyte=$(cat /dev/urandom | tr -dc '0-9' | head -c$randexp)
cat /dev/urandom | head -c$randbyte | base64
Что насчёт анонимных сообщений? Всё просто - используется открытый ключ одной из сторон, но адресант не подписывает сообщение. Известен получатель, но не отправитель. А первоначальный обмен открытыми ключами можно произвести, например, с помощью OnionShare(«Trust» в Web of Trust, КМК, доверия не заслуживает).
Коллега предложил использовать долговременные ключи только для подписи, а ключи для шифрования запрашивать по необходимости, подписывая запрос. На мой взгляд такой подход слабее, а площадь атаки много больше.
На первый взгляд всё красиво, не так ли? Да и всю эту «рутину»(кроме первого шага) можно автоматизировать одним коротким исполняемым файлом.
Тем не менее, какие уязвимости есть у такого подхода? Интересует ваше мнение.
И ещё, GPG при работе с блочными шифрами использует режим CFB. Выглядит неплохо, но распространено утверждение, что CTR для подобных целей подходит намного больше. Так ли это?
Как бы то ни было, заранее спасибо за помощь.
Новая версия Tor Browser доступна для скачивания с с официального сайта, каталога версий и Google Play. Версия для F-Droid будет доступна в ближайшие дни.
В обновление включены серьёзные исправления безопасности Firefox.
Основной упор в новой версии сделан на повышении удобства и облегчении работы с onion-сервисами.
Onion-сервисы Tor - один из самых популярных и простых способов установить оконечное зашифрованное соединение. С их помощью администратор способен обеспечить анонимный доступ к ресурсам и сокрыть метаданные от стороннего наблюдателя. Кроме того, такие сервисы позволяют преодолевать цензуру, одновременно с тем защищая конфиденциальность пользователя.
Теперь, при первом запуске Tor Browser пользователи получат возможность предпочесть использование onion-адреса по умолчанию в случае, если удалённый ресурс предоставляет такой адрес. Ранее некоторые ресурсы автоматически перенаправляли пользователей на onion-адрес при обнаружении Tor, для чего использовалась технология alt-svc. И хотя использование подобных методов актуально и поныне, новая система выбора предпочтений позволит оповещать пользователей о доступности onion-адреса.
( Основные нововведения в версии 9.5: )
>>> Блог проекта Tor
Постарался всё максимально красиво оформить и успеть раньше всех. Дабы не засорять главную страницу и не вынуждать сносить комментарии, думаю, стоит перенести обсуждение оформления новости сюда.
Новость большая, потому мог где-то ошибиться. С радостью исправлю всё, что потребуется.
25 мая 2020 было выпущено очередное обновление маршрутизатора I2P, предназначенного для создания децентрализованной, анонимной и защищённой от цензуры сети, поддерживающей TCP и UDP и способной размещать сервисы любого типа. Плановое обновление подготовлено ровно через три месяца после выхода прошлого. Как и всегда, разработчики рекомендуют как можно скорее обновиться, поскольку это лучший способ гарантировать безопасность и работоспособность сети.
В новой версии реализованы следующие изменения и исправления:
И прочие доработки и улучшения
22 мая 2020 года состоялся выпуск популярного кроссплатформенного свободного BitTorrent-клиента Transmission, поддерживающего, помимо стандартного графического интерфейса, управление через cli и веб и отличающегося скоростью работы и низким потреблением ресурсов.
( читать дальше... )
>>> Подробности
Приветствую. Многим на этом форуме приходилось решать самые разные задачи. Думается, в том числе работать с большим количеством файлов.
Утилиты командной строки в GNU/Linux очень хорошо справляются с поиском текста в файлах, поиском файлов по названию и метаданным и т.п. Но они, к сожалению, совершенно не подходят для работы с файлами, содержащими графическую информацию, такими как документы pdf, фото, картинки, видео и т.п. Особенно тогда, когда речь идёт о десятках тысяч таких файлов, занимающих десятки гигабайт дискового пространства(полные копии целых сайтов, например).
Что я под этим подразумеваю?:
До последнего времени подобные операции приходилось производить на оффтопике. Там даже встроенный(начиная с 7) в проводник поиск позволял довольно удобно работать, например, храня миниатюры в оперативной памяти и только те, которые используются прямо сейчас, а с установкой дополнительного ПО становилось совсем просто.
Сейчас попробовал встроенный в Nautilus поиск и понял, что он однозначно не подходит - нет возможности сортировать результаты поиска, невозможно нормально работать над чем-то ещё, пока идёт поиск и создание миниатюр, собственно сами миниатюры, в огромном количестве записываемые на диск. Всё это сильно нагружает машину.
И если проблему с миниатюрами решить довольно легко(смонтировав папку с ними в tmpfs), то вот с остальным пока беда.
Использовать стороннюю проприетарную ОС ради нескольких программ и держать её на диске, загружая каждый раз для подобных операций - не самое удобное решение. Да и гарантировать защиту от утечек сложнее.
Соответственно, интересует возможное ПО для продвинутой работы с файлами.
Заранее спасибо за помощь.
Tor 0.4.3.5 — первый стабильный выпуск в серии 0.4.3.x. В этой серии добавлены:
Согласно текущей политике поддержки, каждая стабильная серия поддерживается в течение девяти месяцев, либо в течение трёх месяцев с момента выпуска следующей(смотря что дольше). Так, новая серия будет поддерживаться как минимум до февраля 2021.
Ошибки, исправленные в выпуске:
>>> Блог torproject
Что-то в последнее время система так и норовит рассыпаться. Ладно, можно понять, почему clang не хочет «переваривать» переход на python3_7, но вот это:
~ # make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
scripts/Kconfig.include:39: gold linker 'ld' not supported
make[1]: *** [scripts/kconfig/Makefile:73: oldconfig] Ошибка 1
make: *** [Makefile:567: oldconfig] Ошибка 2
Вот уточнение по заветному адресу:
sed -n 38p scripts/Kconfig.include
# Fail if the linker is gold as it's not capable of linking the kernel properУже совсем атас. Вот ума не приложу, ГДЕ он у меня в системе вообще нашёл ld.gold?
Само собой, ни menuconfig, ни nconfig, ни ручное копирование и редактирование .config с попыткой собрать это не работает - абсолютно та же ошибка.
Как системе без ядра-то работать? Тупик, копать дальше некуда, это только у меня или так и должно быть?
В чём суть: у меня в частном секторе стоит уже много лет подряд мощный сидбокс, собранный из списанного серверного оборудования, 24\7 качающий всякую всячину через I2P. IP выделенный, канал высокоскоростной.
Несколько дней назад стал замечать странные периодические просадки скорости с привычных нескольких мегабайт\сек до 200-400 килобайт. Чуть позже просадки стали постоянными, а скорость редко была выше 200 килобайт\сек. До последнего списывал это всё на «самоизоляцию», но сегодняшнее поведение сети едва ли можно объяснить только возросшей нагрузкой.
Дело вот в чём: в начале дня всё было вроде как обычно, но периодически скорость сети падала почти до нуля. Обычно этот спад наблюдался не более 20-30 минут(больно, но терпимо), ничего подозрительного. Но уже со второй половины дня спады стали происходить слишком часто, а недавно я обнаружил, что I2P жалуется на блокировку извне.
Я полностью перезагрузил систему, но это не особо помогло - стало писать, что IPv6 заблокирован, а IPv4 свободен, скорость держится в районе 10-30 килобайт\сек. Тут запахло жареным - это сильно похоже на целенаправленную блокировку со стороны провайдера. Floodfil с маршрутизатора быстро слетел, количество известных участников сети сократилось с 6-8К до 2.5К. Интересно, что Tor работает нормально, никаких просадок и чего-то подозрительного, даже без использования мостов.
Мне вот интересно, было ли у кого тут подобное? Если сможет кто у себя проверить работоспособность сети - буду крайне благодарен.
И всё же, ведь внешне трафик I2P сложно отличить от обычных торрентов, не так ли? Как в таком случае возможна адекватная фильтрация?
23 марта 2020 года Tor Project выпустили обновление Tor Browser до версии 9.0.7, устраняющее проблемы безопасности в маршрутизаторе Tor, и значительно меняющее поведение браузера при выборе наиболее безопасного (Safest) уровня настроек.
Наиболее безопасный уровень подразумевает отключение JavaScript по умолчанию для всех сайтов. Однако, из-за проблемы в дополнении NoScript в настоящий момент это ограничение можно обойти. В качестве временного решения, разработчики Tor Browser сделали невозможным работу JavaScript при выборе наивысшего уровня безопасности.
Это может сломать привычные методы работы с Tor Browser для всех пользователей, включивших наивысший режим безопасности, так как теперь невозможно разрешить использование JavaScript через настройки NoScript.
Если вам необходимо вернуть предыдущее поведение браузера хотя бы на время, то можно сделать это вручную, следующим образом:
Встроенный маршрутизатор сети Tor был обновлён до версии 0.4.2.7. В новой версии были исправлены следующие недостатки:
>>> Блог torproject
Собственно, впервые решил попробовать использовать MAC на домашнем компьютере, ибо нет желания, чтобы браузер и другие приложения с доступом в сеть имели возможность читать что угодно в /home/ и потенциально могли стащить\стереть ключи, памятки, заготовки и т.п.. AppArmor выглядит идеальным вариантом, ибо очень давно с ним знаком, да и особо тонкая настройка не нужна, а более простые системы потенциально ненадёжны(?).
Составил профиль для Firefox, запустил и сразу обнаружил, что при некоторых действиях нагрузка на не самый слабый процессор подскакивает до 30-50%. Вот в порядке убывания нагрузки:
Журналы пустые, никаких предупреждений и запрещённых запросов не наблюдаю, более того - нагрузка не уменьшается в претензионном(complain) режиме.
Не вполне ясно, в какую сторону копать. Казалось бы, проблемы наверняка с графикой, но повышенная нагрузка даже при обновлении страницы заставляет в этом сомневаться.
Вопросы: есть ли у кого-то кроме меня подобные наблюдения при использовании AppArmor? Возможно ли это как-то исправить, или проблема в самом AppArmor(а с SELinux и другими MAC такого нет)?
Встроенный Unix DAC слишком топорный и вынуждает создавать по пользователю на каждое приложение, что неприемлемо(да и корень не защищает никак), соответственно, вопросы актуальны в любом случае.
Спасибо за помощь
Согласно твиту одного из сотрудников организации (Chris Hartjes), недавно Mozilla уволила 70 работников (при общей численности в 1000 человек), в том числе всех главных проектировщиков Mozilla Quality Assurance, основные задачи которого — тестирование новых возможностей и исправление ошибок.
В ответ на это на платформе Twitter уволенными сотрудниками был запущен хэштег #MozillaLifeboat, с помощью которого они могут обмениваться подробностями, а заинтересованные лица могут предлагать вакансии.
Ранее Mozilla уже сообщала о приостановке общественных мероприятий Testday и Bugday, являвшихся частью Mozilla QA. А 15 января 2020 года в официальном блоге Mozilla появилась статья «Подготовка к будущему в Mozilla», согласно которой организация планирует сосредоточиться на внедрении новых технологий:
Работа над созданием новых продуктов, которые бы позволили нам повлиять на будущее сети Интернет, требует от нас изменить наш текущий подход, в том числе выделить средства для этих целей. Мы вносим большой вклад в поддержание инноваций. Для того, чтобы подойти к делу ответственно, мы были вынуждены принять несколько трудных решений, что привело к отсеву ролей в Mozilla, о чём мы объявили сегодня среди сотрудников.
У Mozilla есть чёткое представление о будущих доходах от нашего основного бизнеса. В некотором смысле это осложняет положение, и мы очень обеспокоены тем, как это отразилось на наших коллегах. Тем не менее, чтобы ответственно подходить к расширению инвестиций в инновации, способные улучшить Интернет, мы можем и должны ориентироваться на текущие финансовые ограничения.
Напомню, главный источник доходов Mozilla сегодня — сотрудничество с поисковыми системами, такими как Google, Yandex, Baidu и т.д., устанавливаемыми по умолчанию в браузере Mozilla Firefox. Однако в последнее время организация всерьёз озабочена диверсификацией доходов, что позволит ограничить зависимость от сторонних компаний и позволит смягчить спад доходов, вызванный снижением доли Mozilla Firefox в мире.
| следующие → |