Блог ни о чём, заметки с тегом: сеть

Игры с keepalived

Sun, 25 Dec 2022 22:00:09 +0300

В продолжение поста о системном демоне Keepalived, позволяющем организовать отказоустойчивость сервиса и балансировку нагрузки. Возник вопрос — как узнать, какая нода в каком состоянии запущена? Для этого я создал две ВМ, к примеру:
d1 IP=172.16.32.31/24
d2 IP=172.16.32.32/24

Конфигурация d1: Показать

global_defs {
   notification_email { root@localhost }
   router_id PD
    vrrp_garp_master_refresh 30
    vrrp_garp_master_refresh_repeat 2
}
vrrp_instance TEST {
    state MASTER
!    state BACKUP
    interface <интерфейс>
    virtual_router_id 101
    priority 103
!    priority 102
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass <пароль>
    }
    virtual_ipaddress { 172.16.32.30/24 dev <интерфейс> label <интерфейс>:vrrp }
    notify /opt/notify.sh
}

Конфигурация d2: Показать

global_defs {
   notification_email { root@localhost }
   router_id PD
    vrrp_garp_master_refresh 30
    vrrp_garp_master_refresh_repeat 2
}
vrrp_instance TEST {
!    state MASTER
    state BACKUP
    interface <интерфейс>
    virtual_router_id 101
!    priority 103
    priority 102
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass <пароль>
    }
    virtual_ipaddress { 172.16.32.30/24 dev <интерфейс> label <интерфейс>:vrrp }
    notify /opt/notify.sh
}

Для контроля текущей конфигурации (состояния) демона keepalived используется скрипт /opt/notify.sh: Показать

#!/bin/bash
echo $1 $2 is in $3 state > /var/run/keepalive.$1.$2.state

Ещё полезный скрипт-однострочник:: Показать

conf=/etc/keepalived/keepalived.conf && vip=$(expr "$(cat $conf)" : '.*\bvirtual_ipaddress\s*{\s*\(.*\)/*}') && vip=`expr "$vip" : '\([^ ]*\)' | sed 's/\./\\\\./g'` && if ip addr | grep -q "$vip"; then echo Primary; else echo Secondary; fi

Банк HSBC приобрёл виртуальный участок земли

Wed, 16 Mar 2022 22:53:13 +0300

HSBC, один из крупнейших в мире международных поставщиков банковских и финансовых услуг, и метавселенная Sandbox, сегодня объявили о новом партнёрстве, «которое откроет множество возможностей для виртуальных сообществ по всему миру для взаимодействия с глобальными поставщиками финансовых услуг и спортивными сообществами в метавселенной».

Показать

Партнёрство между Sandbox и HSBC приведёт к тому, что глобальный поставщик финансовых услуг приобретёт участок земли, виртуальную недвижимость в метавселенной, которая будет использована для привлечения и общения с энтузиастами спорта, киберспорта и игр.

The Sandbox Game — это многопользовательская онлайн игра, использующая технологию блокчейна с элементами децентрализованных финансов (DeFi) и незаменяемых токенов (NFT). Sandbox — это целая игровая метавселенная, в которой игроки могут покупать и продавать «земли», создавать и реализовывать свои «активы» — NFT-токены, а также участвовать в управлении проектом, определяя вектор его дальнейшего развития. В отличие от многих игр, в The Sandbox нет заранее определенного игрового мира и заранее продуманного сценария. При этом, помимо создания и добавления своих объектов в игровой мир, пользователи могут заработать на продаже своих творений.

«Метавселенная — это то, как люди будут работать с Web3, следующим поколением Интернета, используя иммерсивные технологии, такие как дополненная реальность, виртуальная реальность и расширенная реальность» — заявил Суреш Баладжи, директор HSBC по маркетингу Азиатско-Тихоокеанский региона.

Сумма сделки не раскрывается. Интересен тот факт, что не так давно банк HSBC запрещал своим клиентам покупать акции Microstrategy (разработчика ПО, который все свои ликвидные средства инвестировала в криптовалюту) как высокорисковые, а руководители финансового гиганта неоднократно заявляли, что «крипта — это не наше».

P. S. Применительно к реалиям сегодняшнего дня и местоположению — ждите разгонов протестов в метавселенных...

Источники:
The Sandbox
iXBT

Let’s Encrypt отзывает 2 млн сертификатов

Thu, 27 Jan 2022 12:48:23 +0300

Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, объявил о досрочном отзыве около двух миллионов TLS-сертификатов, что составляет около 1% от всех активных сертификатов данного удостоверяющего центра. Отзыв сертификатов инициирован из-за выявления несоответствия требованиям спецификации в применяемом в Let’s Encrypt коде с реализацией расширения TLS-ALPN-01 (RFC 7301, Application-Layer Protocol Negotiation). Несоответствие было связано с отсутствием некоторых проверок, выполняемых в процессе согласования соединений на базе TLS-расширения ALPN, применяемого в HTTP/2. Детальная информация об инциденте будет опубликована после завершения отзыва проблемных сертификатов.

Показать

26 января в 03:48 (MSK) проблема была устранена, но все сертификаты, при выдаче которых для верификации использовался метод TLS-ALPN-01, решено признать недействительными. Отзыв сертификатов начнётся 28 января в 19:00 (MSK). До этого времени пользователям, использующим метод проверки TLS-ALPN-01, рекомендуется успеть обновить свои сертификаты, иначе они досрочно будут признаны недействительными.

Соответствующие уведомления о необходимости обновления сертификатов отправлены на email. Пользователей, применяющих для получения сертификата инструментарии Certbot и dehydrated, при использовании настроек по умолчанию проблема не затронула. Метод TLS-ALPN-01 поддерживается в пакетах Caddy, Traefik, apache mod_md и autocert. Проверить корректность своих сертификатов можно через поиск идентификаторов, серийных номеров или доменов в списке проблемных сертификатов.

Так как изменения затрагивают поведение при проверке методом TLS-ALPN-01, для продолжения работы может требоваться обновление ACME-клиента или изменение настроек (Caddy, bitnami/bn-cert, autocert, apache mod_md, Traefik). Изменения сводятся к использованию версий TLS не ниже 1.2 (клиенты теперь не смогут использовать TLS 1.1) и прекращению поддержки OID 1.3.6.1.5.5.7.1.30.1, идентифицирующего устаревшее расширение acmeIdentifier, поддерживаемое только в ранних черновиках спецификации RFC 8737 (при формировании сертификата теперь допускается только OID 1.3.6.1.5.5.7.1.31, а клиенты использующие OID 1.3.6.1.5.5.7.1.30.1 не смогут получить сертификат).

Источники:
https://www.opennet.ru/opennews/art.shtml?num=56588
https://community.letsencrypt.org/t/2022-01-25-issue-with-tls-alpn-01-validation-method/170450

Настройка высокой доступности через keepalived в Debian

Sun, 19 Dec 2021 00:13:58 +0300

Keepalived — системный демон на Linux-системах, позволяющий организовать отказоустойчивость сервиса и балансировку нагрузки. Отказоустойчивость достигается за счет «плавающего» IP-адреса, который переключается на резервный сервер в случае отказа основного. Для автоматического переключения IP-адреса между серверами keepalived используется протокол VRRP (Virtual Router Redundancy Protocol), стандартизированный в RFC 2338 (https://www.ietf.org/rfc/rfc2338.txt).

Показать

Оглавление
Принципы работы протокола VRRP
Общий алгоритм работы
Установка и настройка keepalived
Результат
Источники

Принципы работы протокола VRRP

Теория и основные определения протокола VRRP:
VIP — Virtual IP, виртуальный IP адрес, который может автоматически переключаться между серверами в случае сбоев;
Master — сервер, на котором в данный момент активен VIP;
Backup — серверы, на которые переключится VIP в случае сбоя мастера;
VRID — Virtual Router ID, серверы, объединённые общим виртуальным IP (VIP), образуют так называемый виртуальный роутер, уникальный идентификатор которого, принимает значения от 1 до 255. Сервер может одновременно состоять в нескольких VRID, при этом для каждого VRID должны использоваться уникальные виртуальные IP-адреса;
Virtual MAC — виртуальный MAC-адрес (0000.5E00.01xx, где xx — номер группы VRRP).
Перейти к оглавлению.

Общий алгоритм работы:

Master-сервер с заданным интервалом отправляет VRRP пакеты на зарезервированный адрес multicast (многоадресной, когда отправитель один, а получателей может быть много) рассылки 224.0.0.18, а все backup-серверы слушают этот адрес.

Если backup-сервер не получает пакеты VRRP, то он начинает процедуру выбора master и, если он переходит в состояние master по приоритету, то активирует VIP и отравляет gratuitous ARP (особый вид ARP ответа, который обновляет MAC таблицу на подключенных коммутаторах, чтобы проинформировать о смене владельца виртуального IP адреса и MAC-адреса для перенаправления трафика).

Перейти к оглавлению.

Установка и настройка keepalived

Установку и настройку я провёл на однотипных серверах в виде виртуальных машин Virtualbox d1 и d2 с установленной системой Debian версии 11.1.0. В качестве IP-адресов серверов используются 10.9.1.16/24 — для сервера d1, 10.9.1.61/24 — для сервера d2. В качестве виртуального IP-адреса, который будет автоматически переключаться между серверами в случае сбоев, используется адрес 10.9.1.6/24.

N. B. Символ комментария в конфигурационном файле keepalived — это ВОСКЛИЦАТЕЛЬНЫЙ ЗНАК (!).

N. B. 2 <интерфейс> — сетевой интерфейс хостов d1 и d2.

N. B. 3 В примере приведена конфигурация без дополнительных проверок статусов каких-либо служб d1 и d2.

На машинах d1 и d2:

1 — на сетевом интерфейсе <интерфейс> настраиваю IP-адрес 10.9.1.16/24 на машине d1 и 10.9.1.61/24 на машине d2 соответственно;
2 — устанавливаю необходимые пакеты:

apt-get update
d1 # apt-get install linux-headers-$(uname -r)

3 — устанавливаю Keepalived:

apt-get install keepalived

4 — настраиваю Keepalived:

на машине d1: Показать

cat <<EOF >>/etc/keepalived/keepalived.conf
global_defs {}
vrrp_instance d1 {
    state MASTER
    interface <интерфейс>
    virtual_router_id 101
    priority 101
    advert_int 1
    virtual_ipaddress {
        10.9.1.6/24
    }
}
EOF

на машине d2: Показать

cat <<EOF >>/etc/keepalived/keepalived.conf
global_defs {}
vrrp_instance d2 {
    state BACKUP
    interface <интерфейс>
    virtual_router_id 101
    priority 101
    advert_int 1
    virtual_ipaddress {
        10.9.1.6/24
    }
}
EOF

5 — запускаю демон keepalived:

systemctl start keepalived

N. B. 4 Если в системе используется брандмауэр, необходимо разрешить протокол VRRP в нём. На примере iptables — необходимо добавить в цепочки INPUT и OUTPUT следующие правила:

iptables -I INPUT -p vrrp -j ACCEPT
iptables -I OUTPUT -p vrrp -j ACCEPT

N. B. 5 Для настройки записи лога службы keepalived в отдельный файл необходимо создать файл /etc/syslog.d/10-keepalived.conf с таким содержимым:

if $programname contains 'keepalived' then /var/log/keepalived.log
if $programname contains 'keepalived' then stop

Затем перезагрузить rsyslog:

systemctl restart rsyslog

N. B. 6 Для ротации новых логов создать файл /etc/logrotate.d/keepalived с таким содержимым:

/var/log/keepalived.log {
        weekly
        rotate 8
        compress
        delaycompress
        missingok
        notifempty
}

N. B. 7 Включить автозапуск службы keepalive:

systemctl enable keepalived

Перейти к оглавлению.

Результат

На рисунке приведён результат отключения линка на сетевом интерфейсе на сервере d2 (до отключения функционировал в режиме master). Видно, что виртуальный IP-адрес 10.9.1.6 остаётся доступным: Показать

Перейти к оглавлению.

Источники

https://ru.wikipedia.org/wiki/VRRP
https://winitpro.ru/index.php/2019/09/09/keepalived-ha-balansirovka-plavayushhiy-ip-adres/
https://tecadmin.net/setup-ip-failover-on-ubuntu-with-keepalived/
Перейти к оглавлению.

DMCA теперь разрешает перепрошивку роутеров

Fri, 29 Oct 2021 19:38:44 +0300

Правозащитные организации Software Freedom Conservancy (SFC) и Electronic Frontier Foundation (EFF) добились внесения поправок в «Закон об авторском праве в цифровую эпоху» (DMCA, Digital Millennium Copyright Act), добавляющих прошивки к маршрутизаторам в список исключений, на которые не распространяются ограничения DMCA.

Раз в три года в Библиотеке Конгресса США созывается специальная комиссия, которая в ходе публичных слушаний принимает решение о пересмотре списка исключений с описанием ситуаций к которым закон DMCA не может быть применим. Данный список формируется для защиты от возможных злоупотреблений и необоснованных ограничений, которые могут продвигаться под прикрытием DMCA, не являясь при этом объектом нарушения авторских прав.

Показать

Утверждённые в этом году исключения разрешают установку альтернативных прошивок на маршрутизаторы и другие сетевые устройства (в том числе совершая jailbreak и обходя привязки к прошивкам с DRM). Исключение даёт пользователю возможность продлить жизненный цикл своего устройства после истечения срока поддержки производителем, установив альтернативную прошивку, такую как OpenWrt.

Также одобрены исключения, позволяющие легально проводить исследования прошивок устройств с целью выявления и подтверждения возможного нарушения копилефт-лицензий, требующих открытия производных работ. Исключение действует для всех типов устройств, кроме игровых консолей.

Ранее действующие исключения, связанные с разрешением разблокирования, смены прошивки, ремонта и установки приложений, независимо от того одобрены они производителем или нет, ранее действующие для смартфонов (jailbreak), планшетов и прочих мобильных устройств, расширены в отношении возможности замены программной начинки умных телевизоров.

Расширены категории устройств для которых действуют исключения, позволяющие самостоятельно проводить ремонт. Проект Right to Repair добивается предоставления исключений для ремонта любых устройств и в этом году удалось приблизится к намеченной цели. Одобрены поправки, разрешающие диагностику, техническое обслуживание и ремонт любых потребительских устройств, включая электронные книги, проигрыватели дисков и умные динамики, а также ремонт транспортных средств, морских судов и медицинских устройств. Для медицинских устройств разрешён как ремонт так и извлечение данных, хранящихся на собственном устройстве, независимо от того имплантировано устройство или нет.

Продлены исключения, связанные дешифровкой материалов c DVD, Blu-Ray и online-сервисов, которые используются для составления ремиксов с включением в них отдельных отрывков видео. Из действия DMCA также выведены компьютерные игры и игровые консоли, производители которых прекратили поддержку своих продуктов (любители компьютерных игр могут легально вносить изменения в старые игровые приложения и прошивки игровых консолей для обхода привязок к внешним игровым сервисам и серверам аутентификации). Продлены исключения, позволяющие использовать альтернативные материалы в 3D-принтерах.

Не был удовлетворён запрос на включение исследований соблюдения конфиденциальности в продлённое исключение, разрешающее исследователям безопасности анализировать программные продукты с целью выявления уязвимостей и самостоятельно исправлять найденные уязвимости. Комиссия заключила, что в подобном изменении нет необходимости, так как исследования конфиденциальности подпадают под определение исследований безопасности и принятия отдельного исключения для них не требуется.

Не одобрены были и поправки, допускающие ремонт игровых консолей (ремонт игровых консолей ограничен возможностью самостоятельной замены оптических накопителей) и устройств с прошивками, применяемыми в коммерческих или промышленных целях за исключением транспортных средств и медицинских устройств. Например самостоятельный ремонт и изменение настроек робота-пылесоса считается нелегальным.

Из нерешённых проблем также отмечается отсутствие исключений для распространения инструментов, используемых для ремонта — поставка утилит, обходящих блокировки производителей по-прежнему считается нелегальной. Отмечается, что комиссия не имеет полномочий принять исключение по этому вопросу, так как он требует реформирования законодательства. Таким образом складывается ситуация, что пользователь получил право самостоятельно изменить прошивку и обойти привязку к периферийным устройствам на своём Xbox, но распространение кода для осуществления таких действий является незаконным.

Источники:
https://public-inspection.federalregister.gov/2021-23311.pdf
https://www.opennet.ru/opennews/art.shtml?num=56066
https://sfconservancy.org/news/2021/oct/28/2021-DMCA-final-exemptions-win/

Компания Intel развивает протокол HTTPA, дополняющий HTTPS

Wed, 27 Oct 2021 16:17:46 +0300

Инженеры из компании Intel предложили новый протокол HTTPA (HTTPS Attestable), расширяющий HTTPS дополнительными гарантиями безопасности произведённых вычислений. HTTPA позволяет гарантировать целостность обработки запроса пользователя на сервере и убедиться в том, что web-сервис заслуживает доверия и работающий в TEE-окружении (Trusted Execution Environment) на сервере код не был изменён в результате взлома или диверсии администратора.

Показать

HTTPS защищает передаваемые данные на этапе передачи по сети, но не может исключить нарушение их целостности в результате атак на сервер. Изолированные анклавы, создаваемые при помощи таких технологий, как Intel SGX (Software Guard Extension), ARM TrustZone и AMD PSP (Platform Security Processor), дают возможность защитить важные вычисления и снизить риск утечек или изменения конфиденциальной информации на конечном узле.

HTTPA для гарантирования достоверности переданной информации позволяет задействовать предоставляемые в Intel SGX средства аттестации, подтверждающие подлинность анклава, в котором произведены вычисления. По сути HTTPA расширяет HTTPS возможностью удалённой аттестации анклава и позволяет проверить то, что он выполняется в подлинном окружении Intel SGX и web-сервису можно доверять. Протокол изначально развивается как универсальный и помимо Intel SGX может быть реализован и для других TEE-систем.

Помимо штатного для HTTPS процесса установки защищённого соединения, HTTPA дополнительно требует согласования сессионного ключа, заслуживающего доверия. Протокол вводит в обиход новый HTTP-метод «ATTEST», который позволяет обрабатывать три типа запросов и ответов:

«preflight» для проверки, поддерживает ли удалённая сторона аттестацию анклавов;
«attest» для согласования параметров аттестации (выбор криптографического алгоритма, обмен уникальными для сеанса случайными последовательностями, генерация идентификатора сеанса и передача клиенту открытого ключа анклава);
«trusted session» — формирование сессионного ключа для доверительного обмена информацией. Сессионный ключ формируется на основе ранее согласованной предварительной секретной последовательности (pre-session secret), сформированной клиентом с использованием полученного от сервера открытого ключа TEE, и сгенерированных каждой стороной случайных последовательностей.

HTTPA подразумевает, что клиент заслуживает доверия, а сервер нет, т. е. клиент может использовать данный протокол для верификации вычислений в TEE-окружении. При этом HTTPA не гарантирует, что производимые в процессе работы web-сервера остальные вычисления, производимые не в TEE, не были скомпрометированы, что требует применения отдельного подхода к разработке web-сервисов. Таким образом, в основном HTTPA нацелен на использование со специализированными сервисами, к которым предъявляются повышенные требования к целостности информации, такие как финансовые и медицинские системы.

Для ситуаций когда вычисления в TEE должны быть подтверждены как для сервера, так и для клиента предусмотрен вариант протокола mHTTPA (Mutual HTTPA), выполняющий двухстороннюю верификацию. Данный вариант более усложнённый из-за необходимости двустороннего формирования сессионных ключей для сервера и клиента.

Источники:http://www.opennet.ru/opennews/art.shtml?num=56050
https://arxiv.org/pdf/2110.07954.pdf

TLS 1.0 и 1.1 официально признаны устаревшими

Wed, 24 Mar 2021 12:38:42 +0300

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, опубликовал RFC 8996, официально переводящих протоколы TLS 1.0 и 1.1 в разряд устаревших технологий.

Спецификация TLS 1.0 была опубликована в январе 1999 года. Спустя семь лет было выпущено обновление TLS 1.1 с улучшениями безопасности, связанными с генерацией векторов инициализации и добавочного заполнения. По данным сервиса SSL Pulse по состоянию на 16 января протокол TLS 1.2 поддерживают 95.2% web-сайтов, допускающих установку защищённых соединений, а TLS 1.3 — 14.2%. Соединения по TLS 1.1 допускают 77.4% HTTPS-сайтов, а TLS 1.0 — 68%. Примерно 21% из первых 100 тысяч сайтов, отражённых в рейтинге Alexa, до сих пор не используют HTTPS.

Главными проблемами TLS 1.0/1.1 является отсутствие поддержки современных шифров (например ECDHE и AEAD) и наличие в спецификации требования по поддержке старых шифров, надёжность которых на современном этапе развития вычислительной техники поставлена под сомнение (например, требуется поддержка TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, для проверки целостности и аутентификации используется MD5 и SHA-1). Поддержка устаревших алгоритмов уже приводила к появлению таких атак, как ROBOT, DROWN, BEAST, Logjam и FREAK. Тем не менее, данные проблемы непосредственно не являлись уязвимостями протокола и закрывались на уровне его реализаций. В самих протоколах TLS 1.0/1.1 отсутствуют критические уязвимости, которые можно использовать для осуществления практических атак.

Факап года в самом начале

Wed, 06 Jan 2021 22:57:51 +0300

В открытый доступ попало полное содержимое внутреннего Git-репозитория компании Nissan North America. Причиной утечки стал запущенный компанией Git-сервер на базе платформы Bitbucket, для доступа к которому использовалась выставленная по умолчанию учётная запись с именем «admin» и паролём «admin».

В том числе были получены исходные тексты мобильных приложений, диагностических утилит, сервисов NCAR/ICAR, информационной системы для взаимодействия с дилерами, портала для управления логистикой, серверных бэкендов, внутренних информационных систем, автомобильных сервисов, а также различных программ для работы с клиентами, маркетинга и управления продажами. Анализ полученного кода уже позволил выявить в коде диагностической системы ASIST шифрование пароля устаревшим алгоритмом RC4 с жёстко прошитым ключом «Amalesh».

Источники:
http://www.opennet.ru/opennews/art.shtml?num=54366
https://www.zdnet.com/article/nissan-source-code-leaked-online-after-git-repo-misconfiguration/

Обнаружена уязвимость в чипах Qualcomm и MediaTek с WPA2

Sat, 08 Aug 2020 10:17:47 +0300

Исследователи из компании Eset выявили новый вариант (CVE-2020-3702) уязвимости Kr00k, применимый к беспроводным чипам Qualcomm и MediaTek. Как и первый вариант, которому были подвержены чипы Cypress и Broadcom, новая уязвимость позволяет дешифровать перехваченный Wi-Fi трафик, защищённый с использованием протокола WPA2.

Напомним, что уязвимость Kr00k вызвана некорректной обработкой ключей шифрования при отсоединении (диссоциации) устройства от точки доступа. В первом варианте уязвимости при отсоединении выполнялось обнуление сессионного ключа (PTK), хранимого в памяти чипа, так как дальнейшая отправка данных в текущем сеансе производиться не будет. При этом оставшиеся в буфере передачи (TX) данные шифровались уже очищенным ключом, состоящим только из нулей и, соответственно, могли быть легко расшифрованы при перехвате. Пустой ключ применяется только к остаточным данным в буфере, размер которого составляет несколько килобайт.

Показать

Ключевым отличием второго варианта уязвимости, проявляющейся в чипах Qualcomm и MediaTek, является то, что вместо шифрования нулевым ключом данные после диссоциации передаются вообще не зашифрованными, несмотря на то, что флаги шифрования устанавливаются. Из протестированных на наличие уязвимости устройств на базе чипов Qualcomm отмечены D-Link DCH-G020 Smart Home Hub и открытый маршрутизатор Turris Omnia. Из устройств на базе чипов MediaTek протестирован маршрутизатор ASUS RT-AC52U и IoT-решения на базе Microsoft Azure Sphere, использующие микроконтроллер MediaTek MT3620.

Для эксплуатации обоих вариантов уязвимостей атакующий может отправить специальные управляющие кадры, вызывающие диссоциацию, и перехватить отправляемые следом данные. Диссоциация обычно применяется в беспроводных сетях для переключения с одной точки доступа на другую во время роуминга или при потере связи с текущей точкой доступа. Диссоциацию можно вызвать отправкой управляющего кадра, который передаётся в незашифрованном виде и не требует аутентификации (атакующему достаточно достижимости Wi-Fi сигнала, но не требуется подключение к беспроводной сети). Проведение атаки возможно как при обращении уязвимого клиентского устройства к неуязвимой точке доступа, так и в случае обращения не подверженного проблеме устройства к точке доступа, на которой проявляется уязвимость.

Уязвимость затрагивает шифрование на уровне беспроводной сети и позволяет проанализировать лишь устанавливаемые пользователем незащищённые соединения (например, DNS, HTTP и почтовый трафик), но не даёт возможность скомпрометировать соединения с шифрованием на уровне приложения (HTTPS, SSH, STARTTLS, DNS over TLS, VPN и т. п.). Опасность атаки также снижает то, что за раз атакующий может расшифровать только несколько килобайтов данных, которые находились во время отсоединения в буфере передачи. Для успешного захвата отправляемых через незащищённое соединение конфиденциальных данных, атакующий либо должен точно знать момент их отправки, либо постоянно инициировать отсоединение от точки доступа, что бросится в глаза пользователю из-за постоянных перезапусков беспроводного соединения.

Проблема устранена в июльском обновлении проприетарных драйверов к чипам Qualcomm и в апрельском обновлении драйверов для чипов MediaTek. Исправление для MT3620 было предложено в июле. О включении исправлений в свободный драйвер ath9k у выявивших проблему исследователей информации нет. Для тестирования устройств на подверженность обоих вариантов уязвимости подготовлен скрипт на языке Python.

Дополнительно можно отметить выявление исследователями из компании Сheckpoint шести уязвимостей в DSP-чипах Qualcomm, которые применяются на 40% смартфонов, включая устройства от Google, Samsung, LG, Xiaomi и OnePlus. До устранения проблем производителями детали об уязвимостях не сообщаются. Так как DSP-чип представляет собой «чёрный ящик», который не может контролировать производитель смартфона, исправление может затянуться и потребует координации работ с производителем DSP-чипов.

DSP-чипы используются в современных смартфонах для совершения таких операций как обработка звука, изображений и видео, в вычислениях для систем дополненной реальности, компьютерного зрения и машинного обучения, а также в реализации режима быстрой зарядки. Среди атак, которые позволяют провести выявленные уязвимости, упоминаются: Обход системы разграничения доступа — незаметный захват данных, таких как фотографии, видео, записи звонков, данные с микрофона, GPS и т. п. Отказ в обслуживании — блокирование доступа ко всей сохранённой информации. Скрытие вредоносной активности — создание полностью незаметных и неудаляемых вредоносных компонентов.

Источники
https://www.opennet.ru/opennews/art.shtml?num=53512
https://blog.checkpoint.com/2020/08/06/achilles-small-chip-big-peril/

Установка ownCloud для минфина

Fri, 24 Apr 2020 11:13:24 +0300

Оглавление
Постановка задачи
Общие данные
Установка ownCloud
Настройка WEB-сервера
Завершение настройки ownCloud
Брендирование сервиса
Настройка сервиса SAMBA и ввод сервера в домен Windows
Результат

Постановка задачи
Для организации обмена рабочими файлами поставлены задачи:

установить и настроить сервис WebDAV — аналог Dopbox’а, но функционирующего без ограничений на количество подключаемых устройств (бесплатная учётная запись Dropbox позволяет использовать не более трёх устройств);
обеспечить работу клиентов сервиса на различных платформах пользователей;
предусмотреть возможность подключения сетевой папки с рабочими файлами как сетевого диска;
обеспечить доступ к рабочим файлам из локальной вычислительной сети и информационно-телекоммуникационной сети интернет.

↑ Перейти к оглавлению.

Общие данные
Делал на Debian’е версии 10.3.0 (netinstall) по этому мануалу. Последний октет IP-адреса системы — 36, статический. Установленная версия ownCloud — 10.4.0.4. Пароль пользователя user — стандартный (буду обозначать его STD_PASS), пароль root — такой же, как у user’а. Сначала сделал на реальной машине, затем — на ней же в Виртуалбоксе (для проверки скорости повторного развёртывания сервиса и возможности подключения отдельного образа или физического диска для данных), потом в Hyper-V на виндовом сервере.

Определяюсь со следующими необходимыми в работе переменными: домен Windows — <DOMAIN>, доменное имя узла — cloud.minfin.rk.gov.ru, учётная запись администратора ownCloud — <owncloud-minfin-admin>/<STD_PASS>; каталог с данными пользователей ownCloud — <owncloud-data-dir>. Настройки базы данных: название базы данных — <owncloud-db>; пользователь базы данных — <owncloud-database-admin>, его пароль — <STD_PASS>; узел — <узел>.
↑ Перейти к оглавлению.

Установка ownCloud
От рута установил пакет sudo:

su -
# apt install sudo
# exit

Пользователю, под которым производится установка, настроить получение прав суперпользователя (sudo). Устанавливаю необходимые пакеты:

sudo apt install wget gnupg openssl
sudo apt install apache2 mariadb-server mariadb-client
sudo apt install php7.3 libapache2-mod-php7.3 php7.3-{mysql,intl,curl,json,gd,xml,mb,zip}

Разрешаю запуск службы WEB-сервера при старте системы и запускаю её:

sudo systemctl enable apache2
sudo systemctl start apache2

Создаю базу и натягиваю для неё разрешения:

sudo mysql -u root -p
MariaDB [(none)]> CREATE DATABASE <owncloud-db>;
MariaDB [(none)]> GRANT ALL ON <owncloud-db>.* TO '<owncloud-database-admin>'@'<узел>' IDENTIFIED BY '<STD_PASS>';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> EXIT;

Добавляю ключ репозитория ownCloud:

sudo wget https://download.owncloud.org/download/repositories/10.4.0/fresh/Debian_10/Release.key
sudo apt-key add Release.key
sudo rm Release.key

Добавляю источник ownCloud в настройки пакетного менеджера, обновляю кеш менеджера пакетов и устанавливаю ownCloud:

sudo echo 'deb https://download.owncloud.org/download/repositories/10.4.0/fresh/Debian_10/ /' > /etc/apt/sources.list.d/owncloud.list
sudo apt-get update
sudo apt-get install owncloud-files

↑ Перейти к оглавлению.

Настройка WEB-сервера
Правлю файл настроек WEB-сервера:

sudo rm /etc/apache2/sites-enabled/000-default.conf
sudo nano /etc/apache2/sites-available/owncloud.conf
sudo ln -s /etc/apache2/sites-available/owncloud.conf /etc/apache2/sites-enabled/000-default.conf

Наполняю /etc/apache2/sites-available/owncloud.conf таким содержимым:

<VirtualHost *:80>
ServerName cloud.minfin.rk.gov.ru
Alias / "/var/www/owncloud/"
<Directory /var/www/owncloud/>
  Options +FollowSymlinks
  AllowOverride All
 <IfModule mod_dav.c>
  Dav off
 </IfModule>
 SetEnv HOME /var/www/owncloud
 SetEnv HTTP_HOME /var/www/owncloud
</Directory>

Разрешаю модуль WEB-сервера и перезапускаю его службу:

sudo a2enmod rewrite mime unique_id
sudo systemctl restart apache2

↑ Перейти к оглавлению.

Завершение настройки ownCloud
Переношу каталог с данными пользователей ownCloud за пределы директории WEB-сервера:

sudo mkdir /var/<owncloud-data-dir>
sudo chown www-data /var/<owncloud-data-dir>
sudo mv /var/www/owncloud/data/ /var/<owncloud-data-dir>/

Для настройки доступа в файле /var/www/owncloud/config/config.php в массиве trusted_domains добавляю доверенные домены:

0 => '<внутренний IP-адрес сервера>',
1 => 'cloud.minfin.rk.gov.ru',

Небольшой offtop/workaround: если в файле /var/www/owncloud/config/config.php в массиве trusted_domains добавить

2 => $_SERVER['HTTP_HOST'],

то можно не париться с запоминанием FQDN сервера ownCloud.

При заходе на <внутренний IP-адрес сервера> через браузер открывается страница завершения установки и окончательной настройки ownCloud. Указываю следующие данные:

Учётная запись администратора — <owncloud-minfin-admin>/<STD_PASS>;
Каталог с данными — <owncloud-data-dir>.
Настройка базы данных:
пользователь — <owncloud-database-admin>;
пароль — <STD_PASS>;
база данных — <owncloud-db>;
сетевой узел — <узел>.

Подсунул пути к сертификатам в конфиг-файл апача /etc/apache2/sites-enabled/ssl.conf, он принял такой вид:

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName cloud.minfin.rk.gov.ru
DocumentRoot /var/www/owncloud
ErrorLog ${APACHE_LOG_DIR}/ssl-error.log
CustomLog ${APACHE_LOG_DIR}/ssl-access.log combined
SSLEngine on
SSLCertificateFile /путь/к/файлу/certificate.crt
SSLCertificateKeyFile/путь/к/файлу/private.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
</VirtualHost>
</IfModule>

В файле /var/www/owncloud/.htaccess пишу правило для перенаправления с http на https:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://cloud.minfin.rk.gov.ru/$1 27 [R,L]

↑ Перейти к оглавлению.

Брендирование сервиса
Выполняю небольшое брендирование:
В файле /var/www/owncloud/core/css/styles.css в разделе #body-login меняю фоновую картинку и её расположение (за основу взял фоновую картинку с официального сайта):

background-image: url('../img/background-minfin-white.jpg');
background-position: top 50%;

Сама картинка такая: Показать

В файле /var/www/owncloud/lib/private/legacy/defaults.php меняю заголовки страниц:

$this->defaultTitle = 'Файлообменный ресурс Министерства финансов Республики Крым';
$this->defaultBaseUrl = 'https://cloud.minfin.rk.gov.ru';
$this->defaultSyncClientUrl = 'https://cloud.minfin.rk.gov.ru/install/#install-clients';

Делаю резервную копию файла /var/www/owncloud/core/img/favicon.ico и заливаю в качестве значка веб-сайта вот этот.
↑ Перейти к оглавлению.

Настройка сервиса SAMBA и ввод сервера в домен Windows
По этому мануалу устанавливаю всё для samba’ы и ввожу систему в домен Active Directory:

sudo apt install samba samba-client smbclient
sudo apt install realmd sssd sssd-tools adcli krb5-user packagekit samba-common samba-common-bin samba-libs
smbpasswd -a <user>
nano /etc/samba/smb.conf

В файле /etc/pam.d/common-session должна быть строка

session optional        pam_mkhomedir.so skel=/etc/skel umask=077

Опрашиваю домен:

realm discover <DOMAIN>

Выполняю ввод системы в домен:

realm join --user=user <DOMAIN>

Тест пользователя:

id user@<DOMAIN>

В файле /etc/sssd/sssd.conf меняю строку на

use_fully_qualified_names = False

Рестартую сервис:

systemctl restart sssd

↑ Перейти к оглавлению.

Расшариваю директорию с файлами ownCloud для монтирования сетевого диска на рабочих станциях Windows-пользователей. Для этого :
↑ Перейти к оглавлению.

Результат

↑ Перейти к оглавлению.