В выпуск новой версии проекта Sound Open Firmware 2.2 (SOF), изначально созданная Intel для отказа от практики поставки закрытых прошивок для микросхем DSP, связанных с обработкой звука.
Впоследствии проект был передан под крыло Linux Foundation и сейчас развивается при участии сообщества и при участии AMD, Google и NXP.
Ознакомившись с базовыми понятиями об использовании iptables можно приступать к настройке защиты вашего web-сервера.
Изначально они не установлены и имеют режим ACCEPT, убеждаемся в этом командой:
sudo iptables -L -n -v
или
sudo iptables -vnL
В большинстве случаев вывод будет похож на нижеследующий:
Chain INPUT (policy ACCEPT 123K packets, 456M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 789K packets, 901G bytes)
pkts bytes target prot opt in out source destination
Если что-то не так, то изучаем правила и сохраняем их. После чего удаляем все имеющиеся правила, если они есть.
iptables -F
Разрешить SSH доступ во избежание его блокировании и потери контроля над сервером. Любимым решением (по мнению авторов большинства подобных статей) для этого была бы команда:
eth0 нужно заменить на имя вашего рабочего интерфейса
iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
Но разрешая доступ на SSH в самом начале, мы потом не сможем наложить на SSH правила по его защите от перебора паролей (Bruteforce). Почему? Потому, что правила в iptables применяются последовательно! И все другие ограничения которые бы мы наложили на 22 порт ниже текущего правила, уже не имели бы своей силы.
Итак, сначала защита самого SSH потом его доступ, потом остальная конфигурация.
Т.к. каждый раз, после перезагрузки вашего сервера правила iptables будут сбрасываться, то вам нужно настроить их автоматическое сохранение и восстановление при перезагрузке.
Сохранить правила iptables можно в любую доступную папку, но лучше, конечно, использовать для этого системную директорию, например, директорию для конфигурационных файлов /etc/ или под-папку в ней, например, /etc/iptables-config/.
Для сохранения правил межсетевого экрана Netfilter в linux можно использовать пакет iptables-save. Данный пакет записывает текущую конфигурацию в файл с указанным именем. Существуют две версии данного пакета:
Синтаксис команд одинаковый, поэтому мы рассмотрим вариант ipv4.
iptables-save [-m modprobe] [-c] [-t таблица] [-f имя файла]
Возможные опции:
Предварительно необходимо создать директорию /etc/iptables-conf/:
sudo mkdir /etc/iptables-conf/
В самом простом варианте команда будет выглядеть, например, следующим образом:
sudo iptables-save -f /etc/iptables-conf/iptables_rules.ipv4
Вы можете использовать свою папку, имя файла и расширение.
Возможно использование другого, более привычного всем синтаксиса команды:
В данном варианте команды iptables-save выводит оформленные правила в поток вывода на экран STDOUT, который мы перенаправляем в указанный нами файл.
sudo iptables-save > /etc/iptables-conf/iptables_rules.ipv4
Результат этих команд будет одинаковым.
Для ручного восстановления настроек можно использовать вызов утилиты iptables-restore. Она восстанавливает настройки брандмауэра Netfilter с указанного файла или из потока ввода STDIN, если файл не задан явно. Рассмотрим синтаксис iptables-restore:
iptables-restore [-chntvV] [-w секунды] [-W миллисекунды] [-M modprobe] [-T таблица] [имя файла]
Основные опции:
sudo iptables-restore -vV /etc/iptables-conf/iptables_rules.ipv4
Или вариант восстановления правил из файла без сброса содержимого текущих таблиц Netfilter:
sudo iptables-restore -nvV /etc/iptables-conf/iptables_rules.ipv4
Сохраненные правила с помощью утилиты iptables-save можно восстанавливать с помощью скрипта, запускаемого при каждом запуске операционной системы. Для этого необходимо выполнить следующие действия:
Сохранить набор правил межсетевого экрана с помощью команды:
sudo iptables-save > /etc/iptables-conf/iptables_rules.ipv4
Для запуска набора правил при старте операционной системы перед включением сетевого интерфейса мы создаем новый файл с помощью команды:
sudo nano /etc/network/if-pre-up.d/iptables
Заметим — в сети есть много вариантов места размещения скрипта на локальной машине, но я считаю именно размещение в папке if-pre-up.d наиболее верным, так как при этом скрипт будет выполнятся перед включением сетевого интерфейса.
Добавляем в данный файл следующий скрипт:
#!/bin/sh
/sbin/iptables-restore < /etc/iptables-conf/iptables_rules.ipv4
Устанавливаем необходимые права для созданного файла:
sudo chmod +x /etc/network/if-pre-up.d/iptables
Перезагружаем компьютер и проверяем результат для таблицы filter с помощью команды:
sudo iptables -vnL
Для обеспечения безопасности необходимо, чтобы конфигурация iptables применялась до запуска сетевых интерфейсов, сетевых служб и маршрутизации. Если данные условия не будут соблюдены — появляется окно-интервал уязвимости между загрузкой операционной системы и восстановлением правил защиты межсетевого экрана.
Не стоит забывать, что перед использованием нужно осознавать то, что они делают и то, чего они не делают, а вам нужно!
# разрешаем все соединения на петлевом интерфейсе lo
iptables -A INPUT -i lo -j ACCEPT
# разрешаем все установленные и связанные соединения:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#отбрасываем все соединения с значением "INVALID"
iptables -I INPUT -m state --state INVALID -j DROP
#разрешаем входящий ICMP трафик (ping)
iptables -A INPUT -p icmp -j ACCEPT
#разрешаем себе доступ к SSH на порту 22:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#разрешаем себе доступ к FTP на порту 21:
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
#открываем HTTP (80) порт tcp.
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#открываем HTTPS (443) порт tcp.
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
### !!! действие по умолчанию !!! ###
#разрешаем OUTPUT любых пакетов сервером
iptables -P OUTPUT ACCEPT
### !!! действие по умолчанию !!! ###
#запрещаем FORWARD любых пакетов сервером
iptables -P FORWARD DROP
### !!! действие по умолчанию !!! ###
#запрещаем INPUT любых пакетов сервером
iptables -P INPUT DROP
Существует большое количество приложений для создания анимаций, от достаточно простых приложений до достаточно законченных приложений (как в случае с Blender). Но на этот раз мы сосредоточимся на отличный инструмент, предназначенный для создания 2D-анимации, который, на мой взгляд, очень хорошо организован визуально и довольно прост в использовании.
Инструмент, о котором мы сегодня поговорим, называется Карандаш2D, которое является бесплатным программным обеспечением и, прежде всего, с открытым исходным кодом, которое предназначен для создания 2D рисованной анимации.
Представлен OpenReplay недавно который привлек 4,7 миллиона долларов нового финансирования для расширения вашего сообщества, ускорения масштабируемого развертывания и улучшения взаимодействия с пользователем.
Для тех, кто не знает об OpenReplay, им следует знать, что это стартап, который предоставляет инструмент воспроизведения сеанса с открытым исходным кодом для разработчиков, который помогает им устранять неполадки, делая отладку визуальной, то есть, в основном, инструмент позволяет разработчикам воспроизводить ошибку, сохраняя журнал, чтобы они могли определить, где ошибка.
Во время саммита Data + AI Представлены блоки данных через рекламу, что освободит всю структуру хранилища Delta Lake с открытым исходным кодом под контролем Linux Foundation.
Стоит отметить, что Delta Lake является проектом Linux Foundation с октября 2019 года. и именно открытый уровень хранения обеспечивает надежность и производительность озер данных за счет «архитектуры озер», лучших хранилищ данных и озер данных под одной крышей.
За последние три года Lakehouses стал привлекательным решением для дата-инженеров, аналитиков и специалистов по данным, которым нужна гибкость для запуска различных рабочих нагрузок с одними и теми же данными с минимальной сложностью и без дублирования, от аналитики данных до разработки обучающихся машин. . Delta Lake — самый популярный формат для домов у озера в мире, и в настоящее время его загружают более 7 миллионов раз в месяц (и этот показатель продолжает расти).
Проблема ограничения доступа к сайтам, директориям и файлам, которые располагаются на вашем сервере не является редкой и может возникнуть в десятках, если не сотнях случаев: реконструкция или разработка сайта, доступ к которому нужно ограничить его командой до завершения процесса, региональные или локальные проекты, борьба со школохацкерами и т.п.
Открываем конфигурационный файл вашего сайта:
nano /etc/nginx/sites-available/sitename.com
Находим или создаем локейшн, доступ к которому нужно закрыть с определенного ip, например «111.222.333.444»:
location /testdir {
deny 111.222.333.444;
}
После чего нужно не забыть проверить правильность конфигурации командой:
nginx -t
И в обязательном порядке перезагрузить nginx:
sudo servcie nginx restart
Или просто заставить его перечитать конфигурационные файлы:
sudo service nginx reload
Дополнительно вы можете вывести свою страницу ошибки или даже сделать переадресацию на другой сайт:
location /testdir {
error_page 403 = @deny;
deny 111.222.333.444;
}
location @deny {
return 301 http://example.com/comingsoon;
}
Аналогичным образом вы можете отдавать любой HTTP ответ, вместо стандартного «ERROR 403«:
location /testdir {
deny 111.222.333.444;
return 444;
}
Ошибка 444 (No Response) — это пользовательский код состояния, используемый для указания nginx на закрытие соединения без отправки ответа клиенту, чаще всего используется для отклонения вредоносных или искаженных запросов.
В зависимости от определенного IP-адреса NGINX может выполнять различные действия, а не только запрет доступа. Например, перенаправление.
В данном примере мы перенаправляем всех посетителей по пути https://$host$request_uri, кроме запросов с IP-адреса 111.222.333.444.
location / {
...
if ($remote_addr != 111.222.333.444) {
return 301 https://$host$request_uri;
}
...
}
Аналогичным образом вы можете отправить шуточный код ошибки «HTTP 418» I’m a teapot (Я — чайник). Этот код был представлен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Ожидается, что этот код не будет поддерживаться реальными серверами. Как бы то ни было, реализации существуют. Сервер HTTP Nginx в своей конфигурации использует этот код для имитации поведения goto-like.
deny 111.222.333.444;
deny 111.222.333.555;
deny 111.222.333.666;
deny 111.222.333.777;
1 апреля 1998 года Internet Engineering Task Force (IETF, «Целевая группа по инженерному обеспечению Интернета) представила «протокол для контроля, мониторинга и диагностики кофемашин». В документе среди прочего описывались и ошибки. Проблема за номером 418 описывалась так: если кто-то попытается сварить кофе в чайнике, последний вежливо, но твердо сообщит: «Я – чайник. Ошибка 418».
Шутка прижилась (по крайней мере, в узких кругах). Например, у Google даже сегодня есть соответствующая страница google.com/teapot
В данной ситуации локейшн не представляет ничего особенного и составляется по следующему принципу.
Для запрета доступа с одного диапазона (111.222.111.1-111.222.111.254) ip:
location /testdir {
deny 111.222.111.0/24;
}
Для запрета доступа с нескольких диапазонов ip адресов:
location /testdir {
deny 111.222.111.0/24;
deny 111.222.222.0/24;
}
Вот мы и подошли к более интересному случаю, когда мы можем заблокировать на одном сайте, в нескольких сайтах или же на большом количестве сайтов множество ip адресов и диапазонов сетей, которые у нас расположены в некотором файле «testdir_ip_deny.txt«, расположенном в папке «/etc/nginx/«
location /testdir {
include /etc/nginx/testdir_ip_deny.txt
}
Содержимое файла «testdir_ip_deny.txt» может выглядеть следующим образом:
deny 111.555.111.0/24;
deny 111.222.333.444;
deny 111.222.333.555;
deny 111.222.333.666;
deny 111.222.333.777;
deny 111.666.222.0/24;
deny 111.333.333.888;
deny 111.444.333.999;
deny 111.222.321.666;
deny 111.222.456.777;
В таком виде nginx может обработать десятки тысяч ip адресов и диапазонов ip сетей.
Аналогичным образом вы можете заблокировать доступ ко всем сайтам и всем локейшинам nginx, не прописывая правила блокировки во всех конфигах сайтов.
Для этого достаточно создать файл ip_deny_to_all.conf в директории конфигурационных файлов (/etc/nginx/conf.d) nginx:
nano /etc/nginx/conf.d/ip_deny_to_all.conf
B вставить в него произвольный список запретов:
...
deny 111.666.222.0/24;
deny 111.333.333.888;
...
include добавлять никуда не нужно, т.к. все конфигурационные файлы (*.conf) из данной директории автоматически подключаются в основной конфиг в секцию HTTP, проверить это вы можете открыв соответствующий файл:
nano /etc/nginx/nginx.conf
И найдя следующий код:
http {
...
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Таким образом вы сможете заблокировать или разрешить доступ ко всем сайтам, учитывая содержимое файла /etc/nginx/conf.d/ip_deny_to_all.conf
Таким образом вы можете составить несколько списков, в том числе и списки по странам (вместо использования NGINX GeoIP Module), взяв их, например, на одном из следующих сайтов:
https://www.countryipblocks.net/acl.php (может быть недоступен с ip адресов РФ и РБ)
http://ipverse.net/ipblocks/data/countries/xx.zone (пример: xx – ru)
Диапазоны IP-адресов по странам
Major IP Addresses Blocks By Country
На деле это редко когда может быть актуальным, т.к. тратит ресурсы сервера: канал и процессорное время и правильнее использовать блокировку при помощи ipset или iptables!