Перейти к содержимому
Local

bot

Сitizens
  • Публикации

    1 392
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    1

Последний раз bot выиграл 22 октября 2010

Публикации bot были самыми популярными!

Репутация

57 Очень хороший

1 подписчик

О bot

  • Звание
    Site Team
  • День рождения 1 июня

Информация

  • Пол
    Не определился

Посетители профиля

12 888 просмотров профиля
  1. Уряд затвердив єдині правила розміщення будинкових телекомунікаційних мереж та доступу провайдерів до інфраструктури будинків. Прийняті рішення спрямовані на імплементацію Директиви 2002/19/ЄС про доступ до електронних комунікаційних мереж та пов’язаного оснащення. Про це повідомив Віце-прем’єр-міністр – Міністр регіонального розвитку, будівництва та ЖКГ України Геннадій Зубко, коментуючи прийняття відповідних урядових постанов. «Ми наводимо порядок у розміщенні телекомунікаційних мереж у будинках (як у вже збудованих, так і новому будівництві) за стандартами ЄС. Встановлюємо прозорі правила взаємодії власника та провайдера, дерегулюємо умови доступу провайдерів до споживача», - зазначив Геннадій Зубко. За словами урядовця, це стосується розміщення, модернізації, експлуатаційного та технічного обслуговування засобів телекомунікацій та порядку взаємодії власника інфраструктури об’єкта будівництва і замовника доступу (провайдерів). Зокрема визначається порядок звернення замовника до власника інфраструктури щодо отримання доступу до інфраструктури будинкової розподільної мережі (БРМ), строк розроблення та видачі технічних умов з доступу, порядок розроблення і погодження проектної документації, строки укладення договору та умови його розірвання, порядок та умови припинення користування елементами інфраструктури БРМ, демонтажу технічних засобів телекомунікацій, розміщених без укладання договору з доступу до інфраструктури БРМ тощо. 18 липня на засіданні Уряду були прийняті постанови «Про затвердження Правил надання доступу до інфраструктури об’єкта будівництва» та «Про затвердження Правил надання доступу до інфраструктури будинкової розподільної мережі». Источник: kmu
  2. Британский провайдер широкого вещания завершил построение безопасного интернет соединения с квантовым распределением ключей (КРК), которое, по их утверждению, не подвергается взлому хакерами. Высокоскоростное волоконное соединение с квантовой защитой, протяженностью в 75 миль, построено в Великобритании наибольшей компанией-провайдером услуг доступа в интернет. Частицы света, фотоны, несут ключи шифрования по тому же соединению, по которому выполняется и передача данных. Система мгновенно оповещает об утечке таких фотонов из соединения, и о том, что ключи стали непригодны - при взаимодействии с ключами похититель их изменяет и они уже не могут использоваться перехватчиком – траффик мгновенно становится искаженным. Такое соединение “невозможно взломать виртуально,” сказал Гевин Паттерсон, исполнительный директор компании BT, при объявлении о запуске соединения на выставке, посвященной Интернету вещей Internet of Things World Europe, прошедшей в Лондоне в июне этого года. Канал, построенный компанией BT и партнерами, является первым реальным каналом высокоскоростной сети с квантовой защитой в Великобритании, заявили представители BT в новом релизе. Волоконный канал проходит от Инженерного факультета Кембриджского университета до лаборатории компании BT в Саффолке. Оборудование предоставлено компаниями ID Quantique и ADVA optical networks. По словам экспертов, связанные криптографические ключи, такие, как используются при квантовом распределении ключей, не пробиваемы. Это происходит потому, что части субатомных частиц настолько плотно расположены друг от друга, что постоянно ударяются друг о друга, где бы в пределах канала они не находились. Это значит, что специалист, управляющий сетью в любой момент способен заметить происходило ли вмешательство или потеря данных по изменению криптографических ключей. Любое прерывание будет хорошо и быстро замечено и о нем будет распространено оповещение. Дополнительным преимуществом является и то, что измененный ключ использоваться больше не может. В компании BT говорят, что уже настроили сеть для демонстрации возможностей безопасности конечным пользователям. Однако, канал компании BT - это не первое соединение с КРК. В Джинане, провинция Шаньдун в Китае, подобный проект запустили в мае 2017 года, а также еще одна такая сеть есть в Испании. В Кебмриджском университете Великобритании, где расположен один из концов канала квантовой сети, также находится Хаб Квантовых Коммуникаций (Quantum Communications Hub) - консорциум из 8 университетов Великобритании, предприятий частного сектора и рабочей группы, сотрудничавшей с компанией BT. По заявлениям консорциума, они запустили распределитель на основе квантовых соединений в трех местах их города в июне. Говорят, что Квантовые Коммуникации способны выполнять сверх-безопасную передачу данных по нескольким каналам в 100 Гигабит, а также генерировать фотонные ключи на скорости от 2 до 3 Мбит/с. При этом, компания BT утверждает, что их канал передает данные со скоростью в 500 Гбит/с. Использование фотонов для защиты сетей Фотоны, используемые для квантового распределения, скорее всего в будущем станут причиной ухода от защиты сетей и могут стать ключевым элементом в грядущей эре квантовых компьютерных технологий. Частицы света хорошо подходят для подвижных кубитов (переносящих квантовую информацию), ведь они могут проходить расстояния и работать с изготовленными чипами, объясняют в Университете Мериленда в новой статье о их достижениях в области протонных квантовых компьютерных технологий. В университете говорят, что им удалось изобрести первый одно-фотонный транзистор из полупроводникового кристалла — другими словами – фотонный транзистор. Обычные транзисторы - это маленькие маршрутизаторы, которые повсеместно используются в компьютерных технологиях. В новом фотонном транзисторе переключения напрямую взаимодействуют друг с другом, и могут «достигать экспоненциального ускорения для некоторых задач». Сами по себе фотоны не взаимодействуют, а отталкиваются. “Около 1 миллиона таких новых транзисторов смогут уместиться в кристаллике соли. Они очень быстрые и способны вырабатывать 10 миллиардов фотонных кубитов за каждую секунду,» рассказывают в университете. «Технологии квантовых коммуникаций начинают играть важнейшую роль в защите данных и самих соединений,» эти слова доктора Грегоар Риборди, глава компании IDQ приводятся на сайте, посвященном проекту компании BT. Мы находимся на пороге «эры, когда квантовые компьютеры придут на помощь такой уязвимой сейчас криптографии». Источник: networkworld
  3. Корпорация Intel продолжает расширять ассортимент процессоров Coffee Lake в конструктиве LGA1151. На этот раз пришёл черёд серверных решений линейки Xeon E-2100, которые должны найти применение в рабочих станциях начального уровня. Их характеристики перекликаются с таковыми у чипов Intel Core 8-го поколения, разве что сделан акцент на поддержке ECC-памяти и совместимости только с материнскими платами на базе чипсета C246. Серию возглавляет 6-ядерный Intel Xeon E-2186G с номинальной частотой 3,8 ГГц. Данный CPU располагает двухканальным контроллером памяти DDR4-2666, 12 МБ кэш-памяти третьего уровня, интегрированным видеоядром HD Graphics P630 и контроллером PCI Express 3.0 на 16 линий. Имеется поддержка технологии Hyper-Threading, а частота нагруженного ядра в boost-режиме может повышаться вплоть до 4,7 ГГц. Уровень TDP новинки составляет 95 Вт, рекомендованная цена — 450 долларов. Краткие технические характеристики остальных моделей Intel Xeon E-2100 приведены в таблице ниже. Что касается набора системной логики Intel C246, то он перенял технические характеристики у чипсетов 300-й серии. Данный набор микросхем в силах обеспечить работу 24 линий интерфейса PCI-E 3.0, до шести портов USB 3.1 Gen2, до десяти USB 3.1 Gen1 и до восьми SATA 6 Гбит/с. Кроме того, имеется поддержка интегрированного беспроводного адаптера Intel Wireless-AC (CNVi). Источник: overclockers
  4. неужто ДТЭК локал читает
  5. bot

    iptables 1.8.0

    Спустя два с половиной года с момента формирования прошлой стабильной ветки 1.6.x представлен iptables 1.8.0, новый значительный релиз инструментария для управления пакетным фильтром Linux. Основные изменения: Обеспечено явное разделение классического фронтэнда iptables и нового фронтэнда, построенного поверх инфраструктуры пакетного фильтра nftables и позволяющего мигрировать на технологии nftables, продолжив использовать привычные инструменты и синтаксис iptables. Классический фронтэнд теперь поставляется с явным указанием в имени исполняемых файлов слова "-legacy", например iptables-legacy и iptables-legacy-save, а файлы фронтэнда на базе nftables вместо "-compat" теперь заканчиваются на "-nft", например, iptables-nft. При запуске iptables с командой '--version' выдаётся информация о типе фронтэнда (например "iptables v1.8 (legacy)" или "iptables v1.8 (nf_tables)"); Дистрибутивам рекомендуется устанавливать по умолчанию классический фронтэнд для стабильных выпусков, а в экспериментальных версиях предлагать команды на базе nftables в качестве альтернативы c созданием симлинков iptables, ip6tables, iptables-restore и т.п., указывающих на xtables-nft-multi. В качестве плюсов применения варианта на базе nftables отмечается отсутствие необходимости применения опции "--wait" для решения проблем с одновременным запуском, поддержка мониторинга набора правил при помощи сторонних фоновых процессов, предоставление возможностей для отладки правил (xtables-monitor --trace в сочетании с iptables-действием TRACE) и возможность добавления/удаления правил не меняя внутреннее состояние таких критериев как ограничения и квоты; Применяемый для IPv6 критерий (match) 'srh' теперь может применяться для сопоставления с прошлым, следующим и последним идентификатором сеанса (SID); В действии (target) CONNMARK обеспечена поддержка операций битового сдвига для критериев restore-mark, set-mark и save-mark; В DNAT теперь допустимо использовать сдвинутые диапазоны portmap (входящие обращения к портам (например, 5000-5100) теперь можно перенаправить в иной диапазон портов (2000-2100), в то время как раньше поддерживалось перенаправление только совпадающих диапазонов портов или нужно было перечислять по одному порту в правиле); В бэкенд nf_tables добавлены новые команды: xtables-monitor - отображает изменения в наборе правил и информацию о трассировке пакетов для отладки правил. ebtables - функциональность для замены утилиты ebtables; arptables - функциональность для замены утилиты arptables; Добавлено семейство утилит 'translate' (ip6tables-translate, ip6tables-restore-translate, iptables-restore-translate, iptables-translate) для преобразования синтаксиса iptables в родные наборы правил nftables, воспринимаемые утилитой nft. changelog: https://netfilter.org/projects/iptables/files/changes-iptables-1.8.0.txt Источник: Opennet
  6. Концепция развития IEEE Wi-Fi предполагает продолжение развития стандарта 802.11 с его вариантами ax, WiGig и ad. Пока она не является знаковым запуском хайп-цикла для сегмента сотовой связи—от 3G до 4G до 5G—к Wi-Fi, но эта отрасль стойко усиливает возможности повсеместного подключения и имеет вполне выполнимый план развития мест, где сеть Wi-Fi будет расширяться в ближайшие годы. На сегодняшний день, самый передовые Wi-Fi-устройства в основном работают на так называемой версии Wave 2 стандарта IEEE’s 802.11ac. Версия Wave 2, по сравнению с Wave 1, способна увеличить скорость до 2,34 Гб/с, а также поддерживает работу MU-MIMO. Ниже приведена таблица, представленная компанией Cisco, из нее видно какие именно улучшения влечет за собой Wave 2 по сравнению с предыдущими версиями спецификаций стандарта 802.11. Адлан Феллах, глава фирмы Maraverdis, специализирующейся на аналитике Wi-Fi-систем, в разговоре с RCR Wireless News, рассказал о том, с чем столкнется Wi-Fi после Wave 2. “На этой неделе, инженеры организации, выпускающей спецификации IEEE ожидали получить зеленый свет для первого издания стандарта 802.11ax, которое после двух неудачных попыток послужит основой для следующей волны развития Wi-Fi сетей. Также, как и 11n, стандарт 11ax достаточно сложен и имеет крайне амбициозные цели. Его целью является увеличение показателей использования данных реальными пользователями на 30%, при 4-кратном уменьшении времени ожидания. Также, ожидается, что он позволит пропускать до 4 раз больше данных в том же диапазоне, что и 11ac. С целью обеспечить предложение объемом в 75% к дате принятия редакции стандарта – 1 июля, точки доступа, соответствующие спецификациям этого издания, ожидаются в продаже уже в последнем квартале этого года. Однако, поздний старт означает, что для того, чтобы развить масштабы, технологии придется ждать до 2019 года.” Quantenna, Intel, Qualcomm и другие компании уже представили чипы для работы по предварительному стандарту 11ax, их разработка заняла около 18 месяцев. А японский оператор мобильной связи KDDI уже представил точки доступа, поддерживающие данный стандарт, их производит компания NEC на базе чипа Qualcomm IPQ8078. “Следующим важным шагом для Wi-Fi Alliance (WFA), организации, выполняющей сертификацию и иногда вносящей дополнения в стандарты 802.11, - это произвести проверку возможности взаимодействия и выполнить программы сертификации для версии 11ax. Ожидается, что эти мероприятия пройдут осенью 2019 года. Но работы по подготовке к их проведению уже ведутся с использованием представленных чипов. Альянс WFA недавно проголосовал за то, чтобы принять спецификацию WPA3, - то есть последнюю версию расширений безопасности для Wi-Fi, как обязательную часть при сертификации стандарта 11ax. “Стандарт 802.11ad работает на частоте 60 ГГц (миллиметровые волны), которые делают соединение очень быстрым, но неспособным преодолевать такие сплошные препятствия как стены, столы и книжные шкафы. И это, безусловно перекрывает его высочайшие возможности в диапазоне. Действительно, WiGig (Wi-Fi 802.11ad) был разработан для высокоскоростных соединений на малых расстояниях, как например соединение CE-устройств, расположенных близко – например, телеприставка 4K передает по беспроводной сети немерцающие 4K-видео на телевизор, при таком соединении возможно обеспечить скорость передачи данных до 7 Гб/с. Тем не менее, версия ad не отделилась только потому, что ее рынок достаточно узкий. Не так много людей, которым нужны скорости в несколько гигабит при малых сетях, кроме тех, у кого идет беспроводная передача потоковых видео.” Источник: rcrwireless
  7. Тестирование Linux на DROP сетевых пакетов. Разные методы и их эффективность. Тесты синтетические, но от этого не становятся менее интересными. Пример от Cloudflare. Для иллюстрации производительности методов будут продемонстрированы некоторые цифры. Тесты синтетические, т.е. не на реальной сети с реальными пользователями и трафиком, так что не воспринимайте цифры слишком серьезно. Будет использоваться один из Intel серверов c 10Gbps сетевым интерфейсом. Детали железа не особо важны, т.к. тесты будут показывать вопросы, связанные с операционкой, а не с ограничениями по железу. Что происходит при тестировании: передача большого количества мелких UDP пакетов, достигая уровня в 14Mpps этот трафик направляется на единственный CPU на сервере измеряется количество пакетов, обработанных ядром на этом CPU Мы не пытаемся максимизировать ни скорость приложения в юзерспейсе (userspace), ни количество пакетов. Вместо этого мы пытаемся показать узкие места самого ядра. Синтетический трафик пытается максимально нагрузить conntrack - используется рандомный IP адрес источника и порт. Tcpducmp будет выглядеть примерно следующим образом: $ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234 IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16 IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16 IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16 IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16 IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16 IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16 IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16 IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16 IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16 IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16 На другой стороне все пакеты будут направлены на одну очередь прерываний (RX), т.е. на один CPU. Делается это через ethtool: ethtool -N ext0 flow-type udp4 dst-ip 198.18.0.12 dst-port 1234 action 2 Оценочное тестирование всегда довольно сложное. Когда мы готовили тесты, мы обнаружили, что любые активные сырые сокеты (raw socket) сильно влияют на производительность. Это вполне очевидно, но легко не учесть. Перед тестами убедитесь, что у вас не запущен, к примеру, tcpdump. $ ss -A raw,packet_raw -l -p|cat Netid State Recv-Q Send-Q Local Address:Port p_raw UNCONN 525157 0 *:vlan100 users:(("tcpdump",pid=23683,fd=3)) В конце концов мы отключили Intel Turbo Boost: echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo Это классная функция, и увеличивает производительность по крайней мере на 20%, но она также очень сильно влияет на разброс показаний при замерах. Со включенным бустом разброс достигал +-1.5%. С выключенным - 0.25%. 1. Отброс/DROP пакетов в приложении Начинаем с доставки пакетов к приложению и отбрасывании их уже с помощью него. Чтобы убедиться, что файервол не влияет на это делаем так: iptables -I PREROUTING -t mangle -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I INPUT -t filter -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT Код приложения - обычный цикл, который получает данные и сразу же их отбрасывает (в юзерспейсе): s = socket.socket(AF_INET, SOCK_DGRAM) s.bind(("0.0.0.0", 1234)) while True: s.recvmmsg([...]) Код приложения: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/recvmmsg-loop.c $ ./dropping-packets/recvmmsg-loop packets=171261 bytes=1940176 Тут мы получаем жалкие 175kpps: $ mmwatch 'ethtool -S ext0|grep rx_2' rx2_packets: 174.0k/s Железо нам дает 14Mpps, но мы не можем обработать это ядром на одном CPU с одной очередью прерываний. mpstat это подтверждает: $ watch 'mpstat -u -I SUM -P ALL 1 1|egrep -v Aver' 01:32:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 01:32:06 PM 0 0.00 0.00 0.00 2.94 0.00 3.92 0.00 0.00 0.00 93.14 01:32:06 PM 1 2.17 0.00 27.17 0.00 0.00 0.00 0.00 0.00 0.00 70.65 01:32:06 PM 2 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 01:32:06 PM 3 0.95 0.00 1.90 0.95 0.00 3.81 0.00 0.00 0.00 92.38 Как видите, код приложения не является узким местом, используя 27% системы + 2% юзерспейса на CPU #1, в то время как SOFTIRQ на CPU #2 сжирает 100% ресурсов. Кстати, использовать recvmmsg(2) довольно важно в наши пост-Спектровые дни (Spectre + Meltdown все же помнят?). Системные вызовы теперь требуют больше ресурсов. Мы используем ядро 4.14 с KPTI и retpolines: $ tail -n +1 /sys/devices/system/cpu/vulnerabilities/* ==> /sys/devices/system/cpu/vulnerabilities/meltdown <== Mitigation: PTI ==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <== Mitigation: __user pointer sanitization ==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <== Mitigation: Full generic retpoline, IBPB, IBRS_FW 2. Отключение conntrack Мы специально выбрали рандомные IP адреса и порты при тестировании для того чтобы нагрузить conntrack. Это можно проверить, посмотрев на заполненность conntrack таблицы: $ conntrack -C 2095202 $ sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_max = 2097152 И, конечно же, conntrack будет кричать в dmesg: [4029612.456673] nf_conntrack: nf_conntrack: table full, dropping packet [4029612.465787] nf_conntrack: nf_conntrack: table full, dropping packet [4029617.175957] net_ratelimit: 5731 callbacks suppressed Для ускорения наших тестов, давайте его отключим: iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK Запускаем тест: $ ./dropping-packets/recvmmsg-loop packets=331008 bytes=5296128 Теперь наше приложение получает 333kpps вместо 175kpps. P.S. с SO_BUSY_POLL можно добиться 470kpps, но об этом в другой раз. 3. BPF дропание на сокете Далее мы подумали - зачем этот трафик вообще нужен на юзерспейсе? Мы можем с помощью setsockopt(SO_ATTACH_FILTER) присоединить классический BPF фильтр к SOCK_DGRAM сокету и отбрасывать пакеты на уровне ядра (kernel space). Код: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/bpf-drop.c Тест: $ ./bpf-drop packets=0 bytes=0 С таким подходом (у классического BPF схожая производительность с eBPF) у нас получилось 512kpps. При этом экономится CPU, т.к. не нужно дергать приложение в юзерспейсе. 4. DROP с помощью iptables после роутинга В качестве следующего теста мы решили отбрасывать пакеты в цепочке INPUT в iptables: iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP Conntrack отключен в предыдущем правиле. Эти два правила в файерволе дали нам 608kpps. $ mmwatch 'iptables -L -v -n -x | head' Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 605.9k/s 26.7m/s DROP udp -- * * 0.0.0.0/0 198.18.0.12 udp dpt:1234 5. DROP с помощью iptables в таблице PREROUTING Т.е. отбрасываем пакеты пока они не попали в роутинг: iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j DROP Получаем 1.688mpps Довольно существенный прирост при использовании таблички "raw". Не совсем понятно почему такой прирост, возможно потому, что у нас сложный роутинг или баг в настройке сервера. 6. DROP с помощью nftables перед conntrack Т.к. iptables доживает свои дни, то теперь можно пользоваться nftables. Видео, объясняющее почему nftrack лучше: https://www.youtube.com/watch?v=9Zr8XqdET1c nft add table netdev filter nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; } nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop Счетчики можно пронаблюдать так: $ mmwatch 'nft --handle list chain netdev filter input' table netdev filter { chain input { type filter hook ingress device vlan100 priority -500; policy accept; ip daddr 198.18.0.0/24 udp dport 1234 counter packets 1.6m/s bytes 69.6m/s drop # handle 2 ip6 daddr fd00::/64 udp dport 1234 counter packets 0 bytes 0 drop # handle 3 } } Получили 1.53mpps. Это немного медленнее iptables, хотя должно быть наоборот. В любом случае nftables рулит. 7. Отбрасывание пакетов в tc ingress Неожиданным фактом стало то, что tc (traffic control) ingress обрабатывается перед PREROUTING. Т.е. можно управлять трафиком еще раньше. Синтаксис довольно неудобный, поэтому рекомендуется использовать скрипт: https://github.com/netoptimizer/network-testing/blob/master/bin/tc_ingress_drop.sh tc qdisc add dev vlan100 ingress tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop проверяем: $ mmwatch 'tc -s filter show dev vlan100 ingress' filter parent ffff: protocol ip pref 4 u32 filter parent ffff: protocol ip pref 4 u32 fh 800: ht divisor 1 filter parent ffff: protocol ip pref 4 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 1.8m/s success 1.8m/s) match 00110000/00ff0000 at 8 (success 1.8m/s ) match 000004d2/0000ffff at 20 (success 1.8m/s ) match c612000c/ffffffff at 16 (success 1.8m/s ) action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 1.0/s sec Action statistics: Sent 79.7m/s bytes 1.8m/s pkt (dropped 1.8m/s, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Получили 1.8mppps на одном CPU. 8. XDP_DROP https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/ С помощью XDP - eXpress Data Path мы можем запустить eBPF код прямо в сетевом драйвере. Т.е. перед тем как skbuff выделяет память. Обычно в XDP две части: eBPF код, загруженный в ядро юзерспейсный загрузчик, который загружает код в нужную сетевую карту и управляет им Написание загрузчика довольно трудное занятие, поэтому мы решили воспользоваться новой iproute2 фичей: ip link set dev ext0 xdp obj xdp-drop-ebpf.o https://cilium.readthedocs.io/en/latest/bpf/#iproute2 Исходник программы: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/xdp-drop-ebpf.c Программа парсит IP пакеты и ищет заданные параметры: IP транспорт, UDP протокол, сеть, порт: if (h_proto == htons(ETH_P_IP)) { if (iph->protocol == IPPROTO_UDP && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 // 198.18.0.0/24 && udph->dest == htons(1234)) { return XDP_DROP; } } XDP программа должна быть скомпилена с современным clang, который умеет делать BPF байткод. После этого загружаем и проверяем XDP программу: $ ip link show dev ext0 4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:8a:59:8e brd ff:ff:ff:ff:ff:ff prog/xdp id 5 tag aedc195cc0471f51 jited И смотрим цифры в статистике интерфейса (ethtool -S) $ mmwatch 'ethtool -S ext0|egrep "rx"|egrep -v ": 0"|egrep -v "cache|csum"' rx_out_of_buffer: 4.4m/s rx_xdp_drop: 10.1m/s rx2_xdp_drop: 10.1m/s Итого получаем 10Mpps на одном CPU. Источник: cloudflare
  8. Проэксплуатировать уязвимость чрезвычайно просто – достаточно использовать cURL-запрос с 29-ю буквами А. В Сети в открытом доступе опубликован эксплоит для серьезной уязвимости в серверах Hewlett Packard Integrated Lights-Out 4 (HP iLO 4). Устройства HP iLO пользуются большой популярностью у малого и среднего бизнеса, так как карты iLO могут встраиваться в обычные компьютеры. Они обеспечивают отдельное соединение по Ethernet и работают на базе проприетарной технологии управления встроенным сервером, обеспечивающей функции внеполосного управления, благодаря чему системные администраторы могут управлять компьютером удаленно. В частности, карты iLO позволяют удаленно устанавливать прошивку, сбрасывать настройки сервера, управлять консолью, просматривать логи и пр. Проэксплуатировав уязвимость в картах iLO (CVE-2017-12542), злоумышленники могут проникнуть в сети множества компаний и получить доступ к строго конфиденциальной информации и интеллектуальной собственности. Проблема была обнаружена в феврале прошлого года и исправлена производителем в августе с выходом версии прошивки iLO 4 2.54, поэтому сисадминам, регулярно устанавливающим патчи, беспокоиться не о чем. Уязвимость связана с обходом аутентификации и позволяет удаленно получить доступ к консоли HP iLO. Получив доступ, злоумышленники могут похитить незашифрованные пароли, выполнить вредоносный код и даже заменить прошивку iLO. Проблема затрагивает версию прошивки серверов HP iLO 4 2.53 и более ранние. Другие поколения, такие как iLO 5, iLO 3 и пр., уязвимости не подвержены. Проэксплуатировать уязвимость чрезвычайно просто – достаточно использовать cURL-запрос с 29-ю буквами А: curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA". В связи с этим проблема получила 9,8 балла из 10 по шкале оценивания опасности уязвимостей. PoC-эксплоиты для CVE-2017-12542 можно скачать здесь и здесь. Модуль Metasploit доступен здесь . Источник: securitylab
  9. Быстрая установка, безопасная работа, простота обновления, невероятная легкость использования и поддержки, - все эти свойства snap-приложений представляют огромный шаг вперед для разработки и установки ПО на Linux. Начиная с Ubuntu, а сейчас уже получив распространение и в Arch Linux, Debian, Fedora, Gentoo Linux и openSUSE, такие приложения дают множество преимуществ по сравнению с традиционными пакетами ПО. В отличие от стандартных пакетов ПО, snap-приложения: Более простые для разработки программистами; Быстрее устанавливаются; Автоматически обновляются; Автономны; Изолированы от других приложений; Более безопасны; Стабильны (их работа не нарушается другими приложениями); Итак, что же такое snap-приложения? Изначально, snap-приложения были разработаны компанией Canonical для использования в Ubuntu. Этот сервис должен был называться "snappy", сама технология "snapcraft", фоновый процесс - “snapd” а пакеты - “snaps”, однако все это стало новым способом подготовки и установки приложений для Linux. Есши вы считаете, что приставка “snap” говорит о некоторой упрощенности в разработке приложений и процессе их установки? Это абсолютно так! Snap-приложения кардинально отличаются от других пакетов Linux. Другие пакеты в основном представляют собой архивы файлов, которые при установке помещают файлы в несколько директорий (/usr/bin, /usr/lib, и пр.). К тому же, другие инструменты и библиотеки, от которых зависит пакет, также необходимо установить или обновить, иначе возможен конфликт с более ранней версией. Snap-приложение, напротив, устанавливается как один независимый файл, включающий необходимые библиотеки и другие нужные файлы. Его работа не будет влиять на работу других приложений, или менять какие-либо ресурсы, от которых также зависят и другие приложения. При разработке snap-приложения, все источники, необходимые для его работы, включаются в один файл. Такое приложение также изолированно от всей системы, обеспечивая тем самым то, что при изменении snap-приложения, остальные файлы системы не будут подвергаться каким-либо изменениям. Это также затрудняет доступ других программ к данным такого приложения. Другим важным отличием является то, что snap-приложения не могут являться частью пакетов программ, они рассматриваются и устанавливаются по отдельности, поговорим об этом чуть подробнее. Snap-приложения начали свое существования как Клик-пакеты (Click packages) - новый формат пакетов, разработанный для Ubuntu Mobile - а затем уже стали snap-приложениями. Как работают snap-приложения? Snap-приложения работают посредством множества дистрибутивов Linux таким образом, который иногда называют “дистро-агностикой” “distro-agnostic” , он дает разработчикам выйти за рамки своих представлений о совместимости ПО и предварительно установленных библиотек системы. Пакет snap-приложения уже содержит все, что ему нужно для запуска – сжатое, готовое к использованию. По сути, такими (сэатыми) они и остаются. Это позволяет им занимать мало места на диске, не смотря на их автономность. Работа таких приложений относительно незаметна. Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее. Если все же такие приложения присутствуют в вашей системе, для того, чтобы их найти вам нужно будет прописать в строке поиска /snap/bin. Если вы используете для работы оболочку bash users, эта строка будет добавлена автоматически. $ echo $PATH /home/shs/bin:/usr/local/bin:/usr/sbin:/sbin:/bin:/usr/games:/snap/bin Проблемы не возникнут даже при автоматическом обновлении. Запущенное snap-приложение продолжает свою работу даже во время обновления. Просто, более новая версия станет активна при следующем запуске. Почему такие приложения более безопасны? Одной из причин повышения безопасности является то, что эти программы имеют существенно более ограниченный доступ к ОС, чем стандартные пакеты ПО. Они находятся в песочницах и контейнерах и не имеют широкого доступа к системе. Как snap-приложения помогают разработчикам? Они проще в разработке. Snap-приложения позволяют разработчикам больше не думать о необходимости разработки множества дистрибутивов и версий, которые могут понадобиться пользователям. Они просто помещают в пакет snap-приложение и все, что может понадобиться для его работы. Упрощение длительного процесса разработки С точки зрения разработчиков, запускать приложения в разработку довольно трудно. Сообщество открытого кода способно на такое только в ответ на давление по поводу выпуска новых релизов. К тому же, разработчики могут использовать новые библиотеки, не принимая во внимание то, что целевой дистрибутив ссылается на более старые библиотеки. И, даже если они пока новички в разработке snap-приложений, наверстать упущенное они смогут уже за неделю. Говорят, что обучение разработке snap-приложений намного легче, чем изучение новых языков. И, конечно, компаниям, выполняющим поддержку дистрибутива не будет нужно проводить каждое приложение через процесс разработки. Таким образом, выигрывают все. Пользу snap-приложений также оценят и системные администраторы, особенно то, что эти программы на наносят вред системе и не приводят к необходимости разбираться в дебрях поддержки. Имеет ли ваша система snap-приложения? Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее. Проверка работы: $ ps -ef | grep snapd root 672 1 0 Jun22 ? 00:00:33 /usr/lib/snapd/snapd где лежит запускающий файл: $ which snap /usr/bin/snap какие snap запущены: $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core minecraft latest 11 stable snapcrafters - Куда установлены snap'ы? Обычно это /var/lib/snapd/snaps. Пакеты поставляются как файлы со .snap расширением $ sudo find / -name "*.snap" /var/lib/snapd/snaps/canonical-livepatch_39.snap /var/lib/snapd/snaps/canonical-livepatch_41.snap /var/lib/snapd/snaps/core_4571.snap /var/lib/snapd/snaps/minecraft_11.snap /var/lib/snapd/snaps/core_4650.snap Установка snap'а $ sudo snap install hello hello 2.10 from 'canonical' installed $ which hello /snap/bin/hello $ hello Hello, world! проверяем: $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core hello 2.10 20 stable canonical - minecraft latest 11 stable snapcrafters - Для удаления есть snap remove Для обновления - snap refresh Для списка доступных - snap find Небольшая предыстория Идея snap-приложений родилась у Марка Ричарда Шаттерворта (Mark Richard Shuttleworth), основателя и директора компании Canonical Ltd., выпустившей операционную систему Ubuntu на основе Linux-based и имеющей десятилетия опыта работы с ней. Одной из составляющих мотивации был уход от возможных ошибок при установке – впервые эти программы были использованы на телефонах. Упрощение процесса разработки, простота техподдержки и повышение безопасности системы не оставили шансов забросить эту идею. источник: networkworld
  10. bot

    Squid 4.1 stable

    После трёх лет разработки представлен стабильный релиз прокси-сервера Squid 4.1, готовый для промышленного использования (выпуски 4.0.x имели статус бета-версий). После придания ветке 4.x статуса стабильной, в ней отныне будут производиться только исправления уязвимостей и проблем со стабильностью, также допускается внесение небольших оптимизаций. Разработка новых возможностей будет производиться в новой экспериментальной ветке 5.0. Пользователям прошлой стабильной ветки 3.5 рекомендуется спланировать переход на ветку 4.1. Основные новшества Squid 4: В соответствии с требованиями RFC 6176 прекращено использование устаревшей версии протокола SSLv2 при согласовании защищённых соединений. Поддержка SSLv3 пока сохранена, но объявлена устаревшей и рекомендована для отключения (tls-options=NO_SSLv3); Реализована возможность установки безопасных соединений с сервисами, используя протокол ICAP поверх TLS. Шифрованный вариант ICAP доступен через URL icaps:// и сетевой порт 11344; Добавлена директива url_lfs_rewrite для перенаправления всех запросов к файлам, которые присутствуют в заданном каталоге, через локальный HTTP-сервер; Добавлена директива on_unsupported_protocol при помощи котороой можно организовать проброс через прокси трафика, отличного от HTTP; Реализована опция "queue-size=N" для настройки максимального размера очереди к обработчикам (helper); В директиве external_acl_type добавлена возможность использования кодов форматирования вывода для лога (logformat); Добавлена экспериментальная поддержка сборки с библиотекой GnuTLS вместо OpenSSL (при сборке с GnuTLS пока не поддерживаются режим SSL-Bump и генерация сертификатов); Переименованы обработчики, связанные с TLS/SSL (вместо ssl_ теперь используется префикс tls_); На смену аутентификатору basic_msnt_multi_domain_auth, зависящему от Samba, пришёл basic_smb_lm_auth; Добавлена директива url_rewrite_timeout; Транзакции в логе теперь отражаются с точностью до долей миллисекунд; Добавлена опция "ext_kerberos_ldap_group_acl -n" для отключения автоматического применения SASL/GSSAPI; В обработчике security_file_certgen появился режим хранения сертификата только в оперативной памяти; Добавлена поддержка HTTP-заголовка "Expect: 100-continue"; Изменён механизм параллельного запуска обработчиков. Из-за возможности организации DoS-атак вместо применения массивов для инициирования запуска параллельных каналов теперь следует использовать очереди запросов со специальным 64-разрядным идентификатором; Значение по умолчанию в ACL localnet (внутренние блоки IP-адресов, такие как 192.168.0.0) приведено в соответствие с RFC 6890; Добавлены настройки request_start_timeout и pconn_lifetime для задания таймаутов для постоянно поддерживаемых соединений; В web-интерфейс cachemgr добавлен блок статистики для срабатываний шаблонов refresh_pattern в контексте отдельных правил; Кодовая база переведена на использование стандарта C++11; Переработан код HTTP-парсера; Улучшена поддержка распараллеливания на многопроцессорных и многоядерных системах. Задействованы атомарные операции C++11. Обеспечено корректное автоопределение модулей ввода/вывода IpcIo и Mmapped, что позволило расширить спектр систем, на которых по умолчанию применяется хранилище кэша Rock; Функции обработки сигналов вынесены из основного фонового процесса в управляющий процесс, PID которого теперь записывается в файл squid.pid. Данное изменение позволило обеспечить интеграцию с внешними системами управления фоновыми процессами, такими как Upstart и systemd; В исполняемом файле squid добавлена поддержка длинных параметров командной строки (--foo). Например, добавлен параметр "--foreground" для запуска основного процесса без перехода в фоновый режим (например, удобно применять вместе с опцией "-z" чтобы дождаться завершения инициализации кэша, а не возвращать управление сразу); Прекращена поддержка директивы cache_peer_domain, обработчика basic_msnt_multi_domain_auth, опций refresh_pattern ignore-auth и ignore-must-revalidate, а также встроенного парсера ESI (Edge Side Includes), вместо которого следует использовать парсеры из библиотек libxml2 или libexpat. Источник: Opennet
  11. Верховная Рада приняла изменения в закон «О рекламе» (относительно использования отдельных элементов благоустройства и контактной сети при осуществлении рекламной деятельности) (№3454). По информации издания ZN.ua, за это решение проголосовали 226 народных депутатов из 329, зарегистрированных в сессионном зале. Законом устанавливается, что размещение рекламы и/или рекламных средств на поддерживающих, опорных и других элементах контактной сети, на средствах и оборудовании (в том числе опорах) наружного освещения запрещается. Закон вступает в силу со дня, следующего за днем его опубликования. Как отмечается в пояснительной записке, в результате принятия этого законопроекта использование объектов благоустройства, как это и предусматривается действующим законодательством, «будет происходить в соответствии с их функциональным назначением для обеспечения благоприятных условий жизнедеятельности человека». Кроме того, отмечается в документе, будет ограничено «тотальное господство в городском пространстве рекламоносителей, которое приводит к визуальному засорению улиц и площадей». Это будет способствовать сохранению аутентичности и пространственной композиции архитектурных ансамблей и объектов культурного наследия, повышению туристической привлекательности, улучшению ситуации в сфере безопасности дорожного движения, считают авторы законопроекта. После принятия закона между депутатами возник спор: речь шла о необходимости учета поправки фракции «Самопомочи», согласно которой размещение рекламы на самих опорах наружного освещения разрешалось. Председатель ВР Андрей Парубий предложил депутатам повторно проголосовать за этот закон, поскольку, по его словам, якобы было зафиксировано неперсональное голосование, но они не поддержали это предложение Источник: Politolog
  12. симантековская онлайн проверка на наличие гадости на роутере http://www.symantec.com/filtercheck/
  13. Некоммерческая организация Wi-Fi Alliance опубликовала новейшую версию протокола безопасности Protected Access (WPA). В настоящее время актуальной версией протокола для сертифицированных устройств является WPA2, и организация продолжит его поддержку еще несколько лет до полного перехода на WPA3. По подсчетам Wi-Fi Alliance, новая версия протокола получит широкое распространение не ранее конца 2019 года. WPA3 был впервые анонсирован в январе текущего года. Целью его создания является усиление защиты данных и совершенствование механизмов аутентификации. Протокол обеспечивает два режима работы – персональный (Personal) и корпоративный (Enterprise). В перечень ключевых функций персонального режима входит защита от online-атак по словарю и подбора пароля методом перебора, даже если пользователь установил ненадежный пароль. На случай компрометации пароля в новой версии протокола предусмотрена усиленная защита коммуникаций. Корпоративный режим предоставляет 192-битное шифрование для сетей, требующих наибольшей защиты (например, компьютерных сетей правительственных организаций и банков), а также улучшает «гибкость» и устойчивость сетей для реализации инструментов шифрования. Оба режима запрещают использование устаревших протоколов и требуют применения технологии Protected Management Frames (PMF), обеспечивающей защиту от перехвата и подделывания трафика. WPA3 автоматически шифрует все соединение с самого начала его установления даже в сетях общественного пользования. Однако следует помнить, что это не гарантирует стопроцентной защиты, поскольку злоумышленники могут настроить вредоносную точку доступа и попросту отключить функцию без ведома пользователей. Источник: securitylab
  14. Компания GIGABYTE анонсировала систему H261-Z60 — четырёхузловой сервер в форм-факторе 2U, построенный на аппаратной платформе AMD EPYC. Каждый из четырёх узлов новинки допускает установку двух чипов EPYC 7000 с количеством ядер до 32. Таким образом, в общей сложности в сервере могут быть задействованы восемь процессоров. Для установки модулей оперативной памяти DDR4-2666/2400/2133 у каждого из узлов есть 16 разъёмов. Возможно применение решений RDIMM и LRDIMM ёмкостью до 64 Гбайт. Каждый узел снабжён двумя портами 1GbE LAN и портом управления Management LAN, двумя слотами PCIe x16 Gen3, двумя портами USB 3.0 и аналоговым разъёмом D-Sub. В систему H261-Z60 можно установить в общей сложности 24 накопителя типоразмера 2,5 дюйма. Это могут быть жёсткие диски или твердотельные решения с интерфейсом SAS/SATA; допускается «горячая» замена. Говорится о совместимости со следующими программными платформами: Windows Server 2012 R2 (x64), Windows Server 2016, Red Hat Enterprise Linux 6.9, Red Hat Enterprise Linux 7.3, SUSE Linux Enterprise Server 11.4, SUSE Linux Enterprise Server 12.2, Ubuntu 16.04, Ubuntu 17.04 и VMware ESXi 6.5. Устройство имеет размеры 440 × 87 × 820 мм и весит 35 кг. Более подробную информацию о сервере можно найти здесь. Источник: servernews
  15. Специалисты компании Nippon Telephone и Токийского технологического института разработали и изготовили опытный образец быстродействующего чипа, предназначенного для организации беспроводного сверхскоростного обмена данными. Данный чип работает в терагерцовом диапазоне, и на частоте в 300 ГГц японским исследователям удалось добиться скорости передачи информации в 100 гигабит в секунду. Терагерцовый диапазон практически не используется в современных коммуникациях, хотя его возможностей вполне достаточно для организации очень быстрой передачи информации. Основным препятствием к появлению коммуникационных систем, работающих в этом диапазоне, является отсутствие необходимых для этого компонентов и готовых узлов. Именно один из таких узлов, радиочастотный смеситель (миксер) и удалось создать японским исследователям. Основой нового устройства являются транзисторы, изготовленные из фосфида индия (Indium phosphide high electron mobility transistor, InP-HEMT), материала, обладающего высоким значением показателя подвижности электронов. Использование таких транзисторов позволило увеличить ширину полосы пропускания, что обычно является большой проблемой при работе в диапазоне 300 ГГц. Помимо этого, использование новых транзисторов позволило увеличить значение соотношения сигнал/шум, и все это вместе обеспечило высочайшую скорость беспроводной передачи данных. Однако, диапазон 300 ГГц не ограничен лишь одной полосой, в нем можно использовать сразу несколько субдиапазонов (каналов) и технологии мультиплексирования, такие, как MIMO и OAM. Это, как ожидают ученые, позволит получить скорость передачи информации на уровне 400 гигабит в секунду, но для этого потребуются дополнительные высокоскоростные чипы, которые также могут быть построены на базе InP-HEMT-транзисторов. И в заключение следует отметить, что данная технология, помимо области беспроводных коммуникаций, может быть успешно использования для проведения съемки в терагерцовом диапазоне, в радарных и других технологиях, которые также работают в данном диапазоне электромагнитного спектра. Источник: dailytechinfo
×