Можно удалить только одну цепочку из 0
2001:0DB8:010F:0001:0000:0000:0000:0ACD => полный адрес 2001:DB8:10F:1:0:0:0:ACD => сокращенный (можно убрать 0 слева) 2001:DB8:10F:1::ACD => сокращенный (можно убрать цепочку 0 только один раз)
Unicast – адресная доставка хосту
Multicast – группе хостов, которые это поддерживают
Anycast – отправка пакета на кучу хостов, но отвечает – ближний
Broadcast – отправка пакетов всем хостам
В этой статье я бы хотел привести примеры настройки NAT на ОС FreeBSD и провести некоторое сравнение способов, которые, по моему мнению, наиболее часто используются.
Из хендбука:
Демон преобразования сетевых адресов (Network Address Translation) во FreeBSD, широко известный как natd(8), является демоном, который принимает входящие IP-пакеты, изменяет адрес отправителя на адрес локальной машины и повторно отправляет эти пакеты в потоке исходящих пакетов. natd делает это, меняя IP-адрес отправителя и порт таким образом, что когда данные принимаются обратно, он может определить расположение источника начальных данных и переслать их машине, которая запрашивала данные изначально.
Для работы natd нужен ipfw.
В ядре:
#Поддержка ipfw options IPFIREWALL options IPFIREWALL_VERBOSE options «IPFIREWALL_VERBOSE_LIMIT=100» #DIVERT пакетов приходящих на интерфейс для NAT options IPDIVERT
В /etc/rc.conf добавить
gateway_enable=«yes»
или в /etc/sysctl.conf добавить
net.inet.ip.forwarding=1.
em0 – внешний интерфейс
192.168.0.0/24 – внутренняя сеть
200.200.200.200 – внешний адрес
Также в /etc/rc.conf добавить:
natd_enable=«YES»
natd_interface=«em0»
natd_flags=””
В фаервол добавляем правила для divert:
/sbin/ipfw add divert natd ip from 192.168.0.0/24 to any out via em0
/sbin/ipfw add divert natd ip from any to 200.200.200.200 in via em0
Более подробно описано в Хендбуке.
В ядре:
options IPFILTER options IPFILTER_LOG
или подгрузить как модуль и не трогать ядро.
В /etc/rc.conf добавить
gateway_enable=«yes»
или в /etc/sysctl.conf добавить
net.inet.ip.forwarding=1.
Также в /etc/rc.conf добавить:
ipnat_enable=«YES» #Включаем ipnat
ipnat_program=”/sbin/ipnat” #Путь к ipnat
ipnat_rules=”/etc/ipnat.rules” #Правила
ipnat_flags=”” #С какими параметрами стартовать
Для ведения логов в syslog.conf добавить:
local0.* /var/log/ipmon.log
и запустить утилиту мониторинга работы IPFilter — ipmon с ключами -Dvas
-D – запуститься демоном
-v – детализировать
-a – отслеживать все устройства IPFilter
-s – через syslog
Если:
em0 – внешний интерфейс
192.168.0.0/24 – внутренняя сеть
200.200.200.200 – внешний адрес
То пример правил для Нат будет выглядеть так:
map em0 from 192.168.0.0/24 to any -> 200.200.200.200/32
Или без конкретизации адресов назначения:
map em0 192.168.0.0/24 -> 200.200.200.200/32
Если адрес динамический то можно сделать так:
map em0 192.168.0.0/24 -> 0.0.0.0/32
Некоторые полезные команды при работе с ipnat:
Перезагрузка ipnat:
/etc/rc.d/ipnat restart
Общая статистика роботы Нат:
ipnat –s
Список активных правил и список активных в данный момент сеансов:
ipnat –l
Перечитать конфиг:
ipnat -CF -f /etc/ipnat.rules
-C — очищает таблицу правил.
-F — удаляет записи из таблицы трансляций.
Больше об ipnat и IPFilter в целом можно узнать из:
ipnat(1), ipnat(5), ipnat(8), ipf(5), ipf(8), ipfstat(8), ipftest(1), ipmon(8)
Более подробно здесь.
В ядре:
device pf # Включаем PF OpenBSD packet-filter firewall device pflog # Поддержка логов pf
В /etc/rc.conf добавить
gateway_enable=«yes»
или в /etc/sysctl.conf добавить
net.inet.ip.forwarding=1.
Также в /etc/rc.conf добавить:
pf_enable=«YES»
pf_rules=”/etc/pf.conf”
pf_program=”/sbin/pfctl”
pf_flags=””
pflog_enable=«YES»
pflog_logfile=”/var/log/pf.log”
pflog_program=”/sbin/pflogd”
pflog_flags=””
Пример самого правила:
em0 – внешний интерфейс
192.168.0.0/24 – внутренняя сеть
200.200.200.200 – внешний адрес
В /etc/pf.conf:
nat on em0 from 192.168.0.0/24 to any -> (em0)
В ядре:
options NETGRAPH options NETGRAPH_IPFW options LIBALIAS options NETGRAPH_NAT …и другие опции нетграфа если надо
Или просто подгрузить модули:
/sbin/kldload /boot/kernel/ng_ipfw.ko
/sbin/kldload /boot/kernel/ng_nat.ko
em0 – внешний интерфейс
192.168.0.0/24 – внутренняя сеть
200.200.200.200 – внешний адрес
Создание НАТ ноды:
ngctl mkpeer ipfw: nat 60 out
ngctl name ipfw:60 nat
ngctl connect ipfw: nat: 61 in
ngctl msg nat: setaliasaddr 200.200.200.200
В ipfw добавляем строчки для перенаправления трафика в созданную ноду:
/sbin/ipfw add netgraph 61 all from any to 200.200.200.200 in via em0
/sbin/ipfw add netgraph 60 all from 192.168.0.0/24 to any out via em0
далее
sysctl net.inet.ip.fw.one_pass=0
Все написанное оформить виде скрипта и засунуть в /usr/local/etc/rc.d с правами запуска для автозагрузки.
Более подробно здесь.
Поддержка ipfw nat появилась начиная с версии FreeBSD 7.0
В ядро:
options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=50 options IPFIREWALL_NAT options LIBALIAS
В /etc/rc.conf добавляем
firewall_enable=«YES» firewall_nat_enable=«YES» firewall_type="/etc/firewall" gateway_enable=«YES»
В /etc/sysctl.conf добавить:
net.inet.ip.fw.one_pass=1
em0 – внешний интерфейс
192.168.0.0/24 – внутренняя сеть
200.200.200.200 – внешний адрес
Пример:
/sbin/ipfw add nat 1 config log if em0 reset same_ports
/sbin/ipfw add nat 1 ip from 192.168.0.0/24 to not table\(10\) via em0
/sbin/ipfw add nat 1 ip from any to 200.200.200.200 via em0
Где table 10 – не идет через нат
Некоторую статистику можно посмотреть так:
ipfw nat 1 show
Следует сказать, что ipfw, natd, ipf, ipnat отлично уживаются вместе. При этом нужно помнить особенности фильтров: ipfw срабатывает по первому совпадению, а ipf (без опции quick в правиле) – по последнему. Ну и всегда следует иметь в виду порядок прохождения пакета через фильтры. Так, если поддержка ipf собрана в ядре, то независимо от того, как запущен ipfw, в первую очередь пакеты будут проходить через правила ipf, а ipfw получит на вход только то, что будет им пропущено. Если же ipfw собран в ядре, а ipf подгружен как модуль, то правом первенства будет пользоваться ipfw.
Если рассматривать разницу и особенности то можно отметить следующее:
Natd:
— Подыхает становится не эффективен, когда трафик превышает 40-50 мегабит
— Реализация в виде демона
— Сложности при работе на нескольких интерфейсах
+ Простота настройки
+ Функциональность, гибкость
IPnat:
+ Простота настройки
+ «близость» к ядру
— При очень больших нагрузках нужен тюнинг
ng_nat:
— Сравнительно сложная настройка
— Не умеет redirect_port
+ Реализирован через libalias в ядре
+ Потребляет сравнительно немного ресурсов
Ipfw nat:
+ Скорость работы
+ Гибкость
+ Реализирован через libalias в ядре
UPD от nightfly:
— невозможность нормально без тонны алиасов натить из под пула
— невнятная статистика
+ наконец перестало течь
+ в отличии от иных умеет активное фтп изкоробки что позволяет не держать рядом фтп прокси
+ не страдает детскими болезнями типа приколов с одновременными pptp сквозь нат
Pf nat:
+ Скорость работы
+ Использование макросов для написания правил
— Проблемы с smp
Я не буду отмечать никакой из выше описанных вариантов ввиду того, что тема немного холиварная, и мнения читателей могут не совпадать с моим. Я только попытался описать примеры настройки и сделать некоторое сравнение множества методов организации NAT на ОС FreeBSD. Также я не стал описывать матчасть по NAT, потому, что она есть здесь.
Когда на компьютере работает только один человек, ему проще войти в систему без ввода пароля каждый раз.
Воспользуемся горячими клавишами: “Win+R”, затем в строку поиска стартового экрана нужно ввести netplwiz, затем внимательно изучаем пользователей компа, выбираем нужное имя и снимает галочку в строке “Требовать ввод имени пользователя и пароля” и внизу нажимаем кнопку ОК.
Следом за этим всплывет новое окно, где попросят для выбранного пользователя указать пароль с подтверждением, затем на кнопку ОК.
Все, теперь можно в Виндовс 8.1 входить без ввода пароля после выхода из системы или после перезагрузки.
UPD. Начиная с версии Windows 10 (20H1) произошло изменение, при котором отсутствует флажок “Требовать ввод имени пользователя и пароля”.
Чтобы исправить это нужно в разделе реестра внести изменение:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device
параметр DevicePasswordLessBuildVersion принимает два значения: 0 – выключено, 2 – включено.
После этого строка с настройкой появится.
https://www.outsidethebox.ms/20445/
Многим обладателям флешек довелось столкнуться с проблемой, когда на USB флешке папки и файлы становятся невидимыми. Вроде как на флешке они имеются, да и место занимают, но не отображаюся.
Всему виной является троян Trojan.Win32.Hider.z. Он устанавливает на файлах и папках атрибут скрытый и при этом делает его недоступным. Папки и файлы можно отобразить, только в том случае, если в “Параметрах папок” отключить опцию “Скрывать защищенные системные файлы”.
В большинстве случаев заражению подвергаются флешки. Папки в корневом каталоге флешки становятся скрытыми, создаются .exe файлы, которое повторяют имена скрытых папок. Скрытые папки можно перемещать, но сделать их «видимыми» обычным способом нельзя.
Для того, что бы снять неактивный атрибут скрытый, с папки либо с файла, нужно проделать следующие действия:
RPM (Redhat Package Manager) – это мощный менеджер пакетов, который может быть использован для сборки, установки, инспекции, проверки, обновления и удаления отдельных программных пакетов. Пакет состоит из набора файлов и информации о пакете, включающей название, версию и описание пакета.
RPM спроектирован так, что предоставляет мощную систему запросов. Вы можете искать в вашей базе данных информацию о пакете или просто об определенных файлах. Вы также можете легко определить, к какому пакету принадлежит файл, и откуда он появился. Сами файлы RPM являются сжатыми архивами, но вы можете запрашивать отдельный пакет очень легко и быстро, потому что к пакету добавлен дополнительный двоичный заголовок со всем, что вам может быть необходимо знать в несжатой форме. Это позволяет производить быстрые запросы.
Другое мощное свойство – это проверка пакетов. Если вы беспокоитесь о том, что вы удалили важный файл из некоторого пакета, просто проверьте это. Вы будете оповещены о любых аномалиях. С этой точки вы можете переустановить пакет, если это необходимо. Любые конфигурационные файлы будут сохранены.
RPM является очень мощным, гибким и удобным менеджером пакетов, который многие начинающие админы почему то игнорируют. Конечно, у него тоже есть свои недостатки, но у кого их нет? 😉 В этой статье, я попытаюсь доказать, что использование rpm облегчает, и без того не легкую, жизнь сисадмина :). А также избавляет его от многих проблем, которые возникнут при установке ПО из исходных кодов.
Из названия менеджера (Redhat Package Manager) понятно, что я буду рассматривать redhat подобные дистрибутивы CentOS, WhiteBox, Fedora Core, Mandrake, ALT Linux, ASP Linux, RHEL, SuSe и т.д., т.к. например в debian или gentoo используется совершенно другой формат пакетов и менеджеры у них соответственно другие. Хотя и на любых других дистрибутивах следует использовать их родные менеджеры пакетов.
Пожалуй наиболее частой операцией является установка/удаление пакетов. Рассмотрим каждый из случаев.
# mount /media/cdrom # cd /media/cdrom/CentOS/RPMS # rpm -ivh squid-2.5.STABLE6-3.4E.3.i386.rpm предупреждение: squid-2.5.STABLE6-3.4E.3.i386.rpm: подпись DSA V3: NOKEY, key ID 443e1821 Подготовка... ########################################### [100%] 1:squid ########################################### [100%]
Теперь мы можем проверить установлен ли у нас пакет
# rpm -q squid squid-2.5.STABLE6-3.4E.3
Процедура удаления выполняется также легко, как и процедура установки. Разница состоит лишь в том, что нам не надо указывать путь и полное имя пакета. Достаточно указать лишь его имя, т.е. squid, хотя если вы укажите squid-2.5.STABLE6 или squid-2.5.STABLE6-3.4E.3, то ошибки не будет и пакет также удалится.
# rpm -e squid
Вообще то при удалении, необходимо указывать имя пакета, которое хранится в базе данных rpm. Если вы не знаете точного имени, то можно воспользоваться следующей командой и выяснить имя соответствующего пакета.
# rpm -qa | grep -i mysql MySQL-server-4.1.9-0 MySQL-devel-4.1.9-0 MySQL-shared-compat-4.1.9-0 MySQL-client-4.1.9-0
Данная команда выведет список всех пакетов, в названии которых встречается слово mysql, без учета регистра. Если вы захотите удалить, например mysql-devel, то необходимо будет полностью указывать имя пакета, т.е. MySQL-devel, а не MySQL.
Обратите внимание, что регистр здесь имеет значение. Иначе при попытке удалить пакет, вы получите следующее сообщение
# rpm -e mysql-devel ошибка: пакет mysql-devel не установлен
А с учетом регистра пакет удалится без проблем
# rpm -e MySQL-devel
Обновление пакета. Рассмотрим случай, когда у вас в системе уже установлена предыдущая версия пакета, и вы хотите обновить его.
# rpm -q squid squid-2.5.STABLE6-3.4E.3
Можно конечно удалить старый пакет и установить новый. Но здесь тоже может быть не все так гладко, от данного пакета могут зависеть другие, установленные пакеты и тогда вы не сможете его удалить. Точнее сможете, но только с ключом –nodeps, который следует использовать ОЧЕНЬ ОСТОРОЖНО и только, если вы точно знаете, что делаете. Другой способ при установке воспользоваться ключом -U (upgrade).
Также полезно использовать ключ –test, с этим ключом будет имитироваться процесс установки/обновления пакета, т.е. файлы устанавливаться не будут. Если будут найдены, какие то ошибки или неудовлетворенные зависимости, то вам об этом будет выдано сообщение. Если никаких сообщений не будет, то можно спокойно устанавливать пакет
На время обновления пакета, наверное, лучше остановить squid во избежание конфликтов
# service squid stop Останавливается squid: . [ ОК ]
Производим непосредственное обновление пакета.
# rpm -Uvh squid-2.5.STABLE11-2.athlon.rpm Подготовка... ########################################### [100%] 1:squid предупреждение: /etc/squid/squid.conf создан как /etc/squid/squid.conf.rpmnew ########################################### [100%]
Из сообщения мы видим, чтобы не перезаписать наш текущий конфигурационный файл – squid.conf, rpm сохранил новый файл под именем squid.conf.rpmnew. Все же перед обновлением рекомендую копировать текущие конфигурационные файлы в отдельную папку во избежание всякого рода неприятностей.
Проверяем версию squid
# rpm -q squid squid-2.5.STABLE11-2
Как видим, squid у нас успешно обновился. Запускаем squid
# service squid start Запускается squid: . [ ОК ]
Узнать список всех установленных пакетов в системе можно с помощью следующей команды
# rpm -qa redhat-logos-1.1.25-1.centos4.3 basesystem-8.0-4 glibc-2.3.4-2 chkconfig-1.3.11.2-1 ... ... ... apache-1.3.33-1 cyrus-sasl-plain-2.1.20-4 openssl-0.9.7e-3 curl-devel-7.13.1-1
Также еще одной полезной возможностью является проверка целостности пакета. Вы в любой момент времени можете проверить, все ли файлы существуют в системе.
# rpm -V squid
Если не будет никаких сообщений, то значит, целостность пакета не нарушена. Для проверки работоспособности данной функции я специально удалю два файла принадлежащих пакету squid и выполню проверку пакета еще раз.
# rm -f /etc/squid/squid.conf /etc/squid/mime.conf # rpm -V squid missing c /etc/squid/mime.conf missing c /etc/squid/squid.conf
Как видно из сообщения он указывает, что отсутствуют два файла, которые я удалил. Если вы хотите проверить целостность всех пакетов, установленных в системе, то необходимо указать ключ -Va.
Еще одной полезной функцией, предоставляемой rpm, является отображение информации о пакете. Допустим, вы хотите узнать, для чего предназначен этот пакет не устанавливая его. Получить информацию о пакете можно с помощью следующей команды
# rpm -qpi MySQL-devel-4.1.9-0.i386.rpm Name : MySQL-devel Relocations: (not relocatable) Version : 4.1.9 Vendor: MySQL AB Release : 0 Build Date: Чтв 13 Янв 2005 06:35:22 Install Date: (not installed) Build Host: build.mysql.com Group : Applications/Databases Source RPM: MySQL-4.1.9-0.src.rpm Size : 6912539 License: GPL Signature : DSA/SHA1, Чтв 13 Янв 2005 17:06:48, Key ID 8c718d3b5072e1f5 Packager : Lenz Grimmer URL : http://www.mysql.com/ Summary : MySQL - Development header files and libraries Description : This package contains the development header files and libraries necessary to develop MySQL client applications. For a description of MySQL see the base MySQL RPM or http://www.mysql.com
Также с помощью rpm вы можете получить список файлов принадлежащих данному пакету, а также пути, куда они были установлены. Для получения данной информации необходимо выполнить следующую команду
# rpm -ql rpm-build /usr/bin/rpmbuild /usr/lib/rpm/brp-compress /usr/lib/rpm/brp-python-bytecompile /usr/lib/rpm/brp-redhat /usr/lib/rpm/brp-sparc64-linux ... ... ... /usr/src/redhat/RPMS/i686 /usr/src/redhat/RPMS/noarch /usr/src/redhat/SOURCES /usr/src/redhat/SPECS /usr/src/redhat/SRPMS
Если вы хотите просмотреть список файлов, предоставляемых данным пакетом, но при этом не хотите устанавливать сам пакет, то выполните следующую команду.
# rpm -qpl /media/cdrom/CentOS/RPMS/linuxdoc-tools-0.9.20-14.i386.rpm /usr/bin/linuxdoc /usr/bin/rtf2rtf /usr/bin/sgml2html /usr/bin/sgml2info /usr/bin/sgml2latex ... ... ... /usr/share/man/man1/sgmlsasp.1.gz /usr/share/texmf/tex/latex/misc/linuxdoc-sgml.sty /usr/share/texmf/tex/latex/misc/linuxdoctr-sgml.sty /usr/share/texmf/tex/latex/misc/null.sty /usr/share/texmf/tex/latex/misc/qwertz.sty
Иногда, бывает необходимо узнать, к какому пакету принадлежит определенный файл и здесь вам опять поможет rpm. Для получения этой информации необходимо выполнить следующую команду.
# rpm -qf /usr/sbin/dmidecode kernel-utils-2.4-13.1.48
Из вывода видно, что файл dmidecode принадлежит пакету kernel-utils-2.4-13.1.48. Хоть я и перешел на freebsd, но все-таки система портов, к сожалению пока не предоставляет таких гибких средств управления пакетами и запросами, как rpm.
А теперь, представьте себе, что вы устанавливали бы все из исходников, при этом вы автоматически лишаетесь всех вышеописанных преимуществ. Для того, чтобы удалить необходимую программу вам необходимо помнить куда вы ее поставили и потом вручную удалять все файлы. При установке программы вам каждый раз придется собирать ее заново.
При конфигурировании программы можно воспользоваться ключом –prefix и указать путь для установки, но это тоже не является выходом из ситуации, т.к. все файлы будут установлены в одну директорию. Конечно, можно воспользоваться и другими ключами, такими как –mandir, –datadir, –infodir, –libdir, –includedir и другими. Но я считаю, что это не лучший выход из ситуации.
При использовании rpm всех этих проблем не существует и все «части» программы (конфигурационные файлы, исполняемые файлы, файлы помощи, скрипты и т.д.) будут установлены в соответствующие папки (прочитайте man hier для ознакомления с иерархией файловой системы). А обновление программ, установленных из исходников, превращается в настоящую муку.
Также, очень часто, при установке программ из исходников вы лишаетесь еще одного преимущества – это скрипты, для автоматического запуска программ при загрузке ОС, которые располагаются в папке /etc/init.d/. Управлять автозагрузкой необходимых программ очень удобно с помощью утилиты chkconfig. В принципе можно и самому написать необходимый скрипт, но зачем это делать, когда это уже сделали для вас?
В целях безопасности перед установкой или обновлением пакетов следует проверять их на подлинность, чтобы быть уверенным, что вы действительно устанавливаете необходимый вам пакет. Для этого существует два способа – проверка GPG подписи и md5 суммы. Рассмотрим каждый из них.
Для того, чтобы проверить GPG подпись необходимо вызвать rpm с ключом –check-sig.
# mount /media/cdrom # cd /media/cdrom/CentOS/RPMS/ # rpm --checksig squid-2.5.STABLE6-3.4E.3.i386.rpm squid-2.5.STABLE6-3.4E.3.i386.rpm: (SHA1) DSA sha1 md5 (GPG) НЕ ОК (ОТСУТСТВУЮТ КЛЮЧИ: GPG#443e1821)
Как видно из сообщения, у нас отсутствует открытый ключ GPG, и соответственно мы не можем проверить подпись. Для исправления этой ситуации необходимо импортировать ключ GPG в нашу базу данных с помощью следующей команды
# rpm --import /media/cdrom/RPM-GPG-KEY
На всех дисках с дистрибутивами должен идти GPG ключ, с помощью которого мы можем проверить все пакеты входящие в этот дистрибутив. После импорта ключа повторим проверку rpm пакета.
# rpm --checksig squid-2.5.STABLE6-3.4E.3.i386.rpm squid-2.5.STABLE6-3.4E.3.i386.rpm: (sha1) dsa sha1 md5 gpg ОК
Как видно, из сообщения, у нас действительно оригинальный (не измененный) пакет и его можно безопасно устанавливать. Но что делать, если вы скачиваете пакет с сайта производителя ПО? Очень часто производители также выкладывают открытые GPG ключи на сайтах. В данном случае необходимо выполнить аналогичную процедуру, т.е. импортировать ключ в базу данных, а затем проверить соответствующий пакет.
Если все-таки нет GPG ключа, то проверить сохранность пакета можно по т.н. контрольной сумме. Перед установкой пакета, следует сравнить текущую сумму с указанной на сайте, откуда вы скачивали данный rpm пакет. Узнать контрольную сумму можно с помощью следующей команды
# md5sum postfix-2.2.8-1.2.src.rpm 985be6c349f062c5245a5a3272c2ac2c postfix-2.2.8-1.2.src.rpm
Если md5 сумма совпадает, значит у вас действительно оригинальный пакет и теперь можно приступить к его непосредственной установке. Если сумма не совпадает, то возможно при закачке файл был поврежден или это совсем не тот файл, который вам нужен ;). В данном случае лучше не устанавливать файл. Если у вас вообще нет никакой возможности проверить подлинность того или иного пакета, то я рекомендовал бы не устанавливать данный пакет вообще. Иначе при установке такого пакета вы можете установить себе в систему т.н. rootkit о последствиях я думаю говорить не надо :).
Надеюсь мне удалось убедить вас, что rpm является действительно мощным, гибким и удобным менеджером пакетов. Используя который ваша система всегда будет согласована и работать, как часы.
А когда после прочтения второй части статьи вы научитесь собирать свои собственные пакеты, то думаю, что вы полюбите его еще больше, и будете использовать только rpm (или ваш штатный менеджер пакетов).
Блокировка спамеров (IP-адреса) на этапе connect:
hostlist bad_hosts = 1.2.3.0/24 : 2.3.0.0/16 (или файл с адресами) acl_smtp_connect = acl_check_connect acl_check_connect: deny message = brrr...? hosts = +bad_hosts accept
Блокировка e-mail адресов:
#Запрещаю e-mail адреса из чёрного списка deny senders = /usr/local/etc/exim/deny_senders message = "Ваш адрес: $sender_address в черном списке" logwrite = Rejected from $sender_address to $local_part@$domain by blacklist.
Очень много правил и настроек по этой ссылке Полезные скрипты/настройки для exim
Exim error 0200100D – can’t receive email outside of localhost
# ls -ld /var/cpanel/ssl/exim drwxr-xr-x 2 root root 4096 Dec 29 2009 /var/cpanel/ssl/exim/ The directory should be 755 file permissions. If it is 700 or lower, then there will be an issue.
Настройка брандмауэра windows из командной строки
ПРИМЕР PS C:\Windows\system32> netsh advfirewall firewall add rule name="HTTP-block" protocol=TCP localport=4427 action=block dir=IN remoteip=87.255.33.131 netsh advfirewall firewall show rule name="HTTP-block" netsh advfirewall firewall delete rule name="HTTP-block"
В Windows server 2008 (R2), а также в обычных Windows vista, 7, 8 есть встроенный брандмауэр (firewall). В этой статье расмотрим несколько примеров как создавать правила из командной строки, также эти команды можно использовать при написании своих пакетных сценариев cmd, bat, powershell.
Все команды нужно выполнять из командной строки cmd запущенной с правами администратора.
Включить брандмауэр:
netsh advfirewall set allprofiles state on
Выключить брандмауэр:
netsh advfirewall set allprofiles state off
Включение отдельных профилей:
netsh advfirewall set domainprofile state on netsh advfirewall set privateprofile state on netsh advfirewall set publicprofile state on
Выключение отдельных профилей:
netsh advfirewall set domainprofile state off netsh advfirewall set privateprofile state off netsh advfirewall set publicprofile state off
Запретить все входяшие соединения и разрешить все исходяшие:
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound
Разрешить входящие TCP и UDP соединения для 80 порта:
netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=allow dir=IN netsh advfirewall firewall add rule name="HTTP" protocol=UDP localport=80 action=allow dir=IN
Запретить входящие на 80 порт:
netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=block dir=IN netsh advfirewall firewall add rule name="HTTP" protocol=UDP localport=80 action=block dir=IN
Открыть диапозон портов для исходящего UDP трафика
netsh advfirewall firewall add rule name="Port range" protocol=UDP localport=5000-5100 action=allow dir=OUT
netsh advfirewall firewall delete rule name="HTTP"
Правила можно ограничивать для работы только с одним ip:
netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=allow dir=IN remoteip=192.168.0.1
Или ограничивать по подсетями причем можно использовать разный синтаксис:
netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=block dir=IN remoteip=192.168.0.0/24 netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=allow dir=IN remoteip=192.168.0.50-192.168.0.70 netsh advfirewall firewall add rule name="HTTP" protocol=TCP localport=80 action=block dir=IN remoteip=localsubnet
Разрешить соединения для программы MyApp.exe
netsh advfirewall firewall add rule name="My Application" dir=in action=allow program="C:\MyApp\MyApp.exe" enable=yes
Параметры можно соединять в довольно сложные цепочки:
netsh advfirewall firewall add rule name="My Application" dir=in action=allow program="C:\MyApp\MyApp.exe" enable=yes remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet profile=domain
В данном случае мы создали правило для программы, которое работает при если компьютер подключен к доменну организации (profile=domain) и определенны три диапозона ip адресов.
Подробней о настройках брандмауэра можно прочитать на сайте микрософта там же есть отличия от сторого синтаксиса который использовался на Windows XP и Windows server 2003:
http://support.microsoft.com/kb/947709
Часть примеров были взяты из статьи на английском языке:
http://itblog.gr/213/configuring-windows-firewall-from-the-command-line/
| Модель OSI | ||||
|---|---|---|---|---|
| Уровень (layer) | Тип данных (PDU[1]) | Функции | Примеры | |
| Host layers |
7. Прикладной (application) | Данные | Доступ к сетевым службам | HTTP, FTP, SMTP |
| 6. Представительский (представления) (presentation) | Представление и шифрование данных | ASCII, EBCDIC, JPEG | ||
| 5. Сеансовый (session) | Управление сеансом связи | RPC, PAP | ||
| 4. Транспортный (transport) | Сегменты (segment)/ Дейтаграммы (datagram) |
Прямая связь между конечными пунктами и надежность | TCP, UDP, SCTP | |
| Media[2] layers |
3. Сетевой (network) | Пакеты (packet) | Определение маршрута и логическая адресация | IPv4, IPv6, IPsec, AppleTalk |
| 2. Канальный (data link) | Биты (bit)/ Кадры (frame) |
Физическая адресация | PPP, IEEE 802.2, Ethernet, DSL, ARP, L2TP | |
| 1. Физический (physical) | Биты (bit) | Работа со средой передачи, сигналами и двоичными данными | USB, витая пара, коаксиальный кабель, оптический кабель | |
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают.
Безопасный SSL протокол размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, IMAP, LDAP, Telnet и т.д.) и транспортным протоколом TCP/IP. Создавая своего рода заслонки с обеих сторон, он защищает и передает данные на транспортный уровень. Благодаря работе по многослойному принципу, SSL протокол может поддерживать много разных протоколов программ-клиентов.
Работу протокола SSL можно разделить на два уровня.
Первый уровень – слой протокола подтверждения подключения (Handshake Protocol Layer). Он состоит из трех подпротоколов: протокол подтверждения подключения (Handshake Protocol), протокол изменения параметров шифра (Change Cipher Spec Protocol) и предупредительный протокол (Alert protocol).
Второй уровень – это слой протокола записи. На рис.1 схематически изображены уровни слоев SSL
1. Подтверждение подключения. Этот подпротокол используется для согласования данных сессии между клиентом и сервером. В данные сессии входят:
* идентификационный номер сессии;
* сертификаты обеих сторон;
* параметры алгоритма шифрования, который будет использован;
* алгоритм сжатия информации, который будет использоваться;
* «общий секрет», применён для создания ключей; открытый ключ
2. Изменения параметров шифрования. Этот подпротокол используется для изменения данных ключа (keyingmaterial), который используется для шифрования данных между клиентом и сервером. Данные ключа – это информация, которая используется для создания ключей шифрования. Подпротокол изменения параметров шифрования состоит из одного единственного сообщения. В этом сообщении сервер говорит, что отправитель хочет изменить набор ключей. Дальше, ключ вычисляется из информации, которой обменялись стороны на уровне подпротокола подтверждения подключения.
3. Предупреждение. Предупредительное сообщение показывает сторонам изменение статуса или о возможной ошибке. Существует множество предупредительных сообщений, которые извещают стороны, как при нормальном функционировании, так и при возникновении ошибок. Как правило, предупреждение отсылаются тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Подпротокол подтверждения подключения обеспечивает реализацию многих функций безопасности. Он производит цепочку обмена данными, что в свою очередь начинает проверку подлинности сторон и согласовывает шифрование, алгоритмы хеширования и сжатия.
Для определения подлинности участников обмена данных, протокол подтверждения подключения использует сертификат стандарта Х.509. Это является доказательством для одной стороны, так как помогает подтвердить подлинность другой стороны, которая владеет сертификатом и секретным ключом. Сертификат – это цифровой способ идентификации, который выпускает центр сертификации. В сертификате содержится идентификационная информация, период действия, публичный ключ, серийный номер, и цифровые подписи эмитента.
Сертификационный центр – это третья сторона, которой по умолчанию доверяют обе стороны. При попытке установить подключение в режиме SSL сессии, сертификационный центр проверяет инициатора (обычно в этой роли выступает пользователь, компьютер клиента), а затем выдает ему сертификат. Если необходимо, сертификационный центр обновляет или конфискует сертификаты. Проверка подлинности проходит по схеме:
* клиенту предоставлен сертификат сервера;
* компьютер клиента пытается сопоставить эмитента сертификата сервера со списком доверительных сертификационных центров;
* если эмитент сертификата – доверительный сертификационный центр, то клиент связывается и этим центром и проверяет, является ли сертификат настоящим, а не подделанным;
* после проверки сертификата у сертификационного центра, клиент принимает сертификат как свидетельство подлинности сервера.
Существует два основных способа шифрования данных: симметричный ключ (еще называется «общий секретный ключ») и ассиметричный ключ (второе название «открытый ключ» или «схема открытый-секретный ключ»). Протокол SSL использует как симметричные, так и ассиметричные ключи для шифрования данных.
SSL-ключ – это зашифрованные данные, которые используются для определения схемы шифрования данных во время сессии. Чем длиннее ключ, тем труднее его взломать. Как правило, алгоритмы ассиметричных ключей более стойкие их практически невозможно взломать.
Симметричный ключ. При шифровании симметричным ключом, используется один и тот же ключ для шифрования данных. Если две стороны хотят обмениваться зашифрованными сообщениями в безопасном режиме, то обе стороны должны иметь одинаковые симметричные ключи. Шифрование симметричным ключом обычно используется для шифрования большого объема данных, так как это процесс проходит быстрее, чем при ассиметричном шифровании. Обычно используются алгоритмы DES (Data Encryption Standard – стандарт шифрования данных), 3-DES (тройной DES), RC2, RC4, и AES (Advanced Encryption Standard – современный стандарт шифрования).
Ассиметричный ключ. Шифрование с применением ассиметричного (открытого) ключа использует пару ключей, которые оба были получены, пройдя целый комплекс математических вычислений. Один из ключей используется в качестве открытого, как правило, сертификационный центр публикует открытый ключ в самом сертификате владельца (обычно это является заголовком (subject)). Секретный ключ держится в тайне и никогда никому не окрывается. Эти ключи работают в паре: один ключ используется для запуска противоположных функций второго ключа. Так, если открытый ключ используется чтоб шифровать данные, то расшифровать их можно только секретным ключом. Если данные шифруются секретным ключом, то открытый ключ должен это расшифровывать. Такая взаимосвязь позволяет, используя схему шифрования открытым ключом, делать две важные вещи. Во-первых, любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, у которого есть секретный ключ. Во-вторых, если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. Самый распространенный алгоритм, который используется при шифровании с ассиметричными ключами – RSA (назван в честь разработчиков Rivest, Shamir, Adleman).
Протокол SSL использует шифрование с открытым ключом для того, чтоб подтвердить клиенту подлинность сервера, и наоборот. Шифрование открытым ключом также используется для определения ключа сессии. Ключ сессии используется симметричными алгоритмами для шифровки большого объема данных. Это объединяет ассиметричное шифрование (для проверки подлинности) и быстрое симметричное шифрование объемных данных (что не требует больших вычислительных ресурсов и больших затрат времени).
Во время подтверждения подключения согласовывается также и хэш-алгоритм. Хэш–функция – это односторонняя математическая функция, которая принимает на входе сообщение произвольной длинны и вычисляет из него строку фиксированной длины. Хеш-значение играет роль идентификационной отметки, «отпечаток сообщения». Как и отпечатки пальцев уникальны для каждого человека, хеш-значения тоже уникальны. Кроме того, как отпечатки пальцев значительно меньше, чем сам человек, так и хеш-значение намного меньше оригинального сообщения. Хэширование используется для обеспечения целостности передачи данных. Самыми популярными хэш-алгоритмами являются MD5 (Message Digest 5 – дайджест сообщения, 5 версия) и SHA-1 (Standard Hash Algorithm – стандартный алгоритм хэширования). MD5 создает 128 битное хэш-значение, а SHA-1 создает 160 битное хэш-значение. Есть также новые, более устойчивые алгоритмы хэширования: WHIRLPOOL, SHA-512, SHA-384, HAVAL, Tiger(2).
Результатом работы хэш-алгоритма выступает значение, которое используется для проверки целостности переданных данных. Это значение создается с использованием либо MAC либо HMAC. MAC – Message Authentication Code – код проверки сообщения. Он использует отображающую функцию и предоставляет данные в виде значений фиксированного размера, а затем – хэширует само сообщение. MAC гарантирует, что данные не были изменены во время передачи. Разница между MAC и цифровой подписью состоит в том, что цифровая подпись это также способ подтверждения подлинности. SSL использует MAC.
HMAC – Hashed Message Authentication Code – хэшированный код проверки сообщения. HMAC похож на MAC, но при этом используется хэш-алгоритм вместе с общим секретным ключом. Общий секретный ключ прикрепляется к данным, которые хэшируются. Это позволяет сделать хэширование более безопасным, так как обе стороны должны иметь одинаковые секретные ключи для подтверждения подлинности данных. HMAC используется только протоколом TLC.
Протокол на уровне слоя записи получает зашифрованные данные от программы-клиента и передает его на транспортный слой. Протокол записи берет данные, разбивает на блоки размером, который подходит криптографическому алгоритму, использует MAC (или HMAC) и потом шифрует (расшифровывает) данные. При этом используется информация, которая была согласованна во время протокола подтверждения данных. В некоторых случая на этом уровне проходит сжатие (распаковка) данных.
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
