Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.

Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.

Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome

Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.

После чего все это дело настраиваем и радуемся жизни.

Стал ковыряться и обнаружил в логах ipmon интересные записи:
Date em1 @0:38 b LAN_IP,port -> VoIP_server,port PR tcp len 20 60 -S OUT OOW
Date em1 @0:58 b VoIP_server,port -> LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT
Date em1 @0:58 b VoIP_server,port -> GW_LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT

Собственно самое интересно в этом флаг OOW, который переводится как out of window, и является багом фильтарции пакетов для которых правило идет со статусом keep state, то есть в момент установленного уже соединения, которое фаервол должен пропускать, он вдруг решает, что это неожиданный пакет и банит его именно по причине OOW. В моем случае- все эти прохождения пакетов были разрешены, и все блокировки были именно по флагу OOW.
Бороться с этим можно двумя способами: либо пропатчив фаервол, либо исключая из правила флаг keep state. Я предпочел последний, тем более что у меня баг срабатывает только на VOIP трафик, тогда как остальной продолжает ходить с флагом keep state.

Самое унылое во всем этом, что судя по инетам данная проблема была пофиксена еще на версии 1.3b5, тогда как у меня в данный момент используется:
# ipf -V
ipf: IP Filter: v4.1.28 (400)
Kernel: IP Filter: v4.1.28
так что видимо с оказией надо будет подумать об обновлении на текущую версию 5.1.0

Кстати просмотреть пакеты дропающиеся по out of window можно с помощью команды:
# ipmon -oI
Тогда как увидеть список загруженных правил можно с помощью команды:
# ipfstat -nio

# cd /usr/ports/security/openvpn
# make && make install
# make clean
в логе инсталяшки видим напоминалку о том, что надо бы врубить работу пакета в /etc/rc.conf, синтаксис которого описан в файле /usr/local/etc/rc.d/openvpn. В этой связи добавляем в /etc/rc.conf следующие строки:
openvpn_enable=”YES”
openvpn_if=”tun”              # driver(s) to load, set to “tun”, “tap” or “tun tap”
openvpn_configfile=”/usr/local/etc/openvpn/openvpn.conf”
openvpn_dir=”/usr/local/etc/openvpn”
Поскольку указанных директорий и файлов у нас нет, то создаем их:
# mkdir /usr/local/etc/openvpn
# touch /usr/local/etc/openvpn/openvpn.conf
а также всю внутреннюю структуру папки /usr/local/etc/openvpn
# mkdir /usr/local/etc/openvpn/ccd
# mkdir /usr/local/etc/openvpn/keys

Надо отметить, что в работе openvpn использует openssl и его структуру, так что если мы планируем еще тщательнее защищаться, то нам надо весь фарш из папки /etc/ssl переносить в нашу папку /usr/local/etc/openvpn/ , включая как папки certs, crl, serial, private, так и  базы данных сертификатов serial и index.txt. Поскольку я бился на удаленной системе посредством ssh, а переться в офис мне совсем не хотелось, то я оставил все на месте, минимизировав перенастройку openssl.

После этого переходим к созданию сертификатов RSA, для чего следуем в папку /usr/local/share/doc/openvpn/easy-rsa/2.0 где редактируем файл /usr/local/share/doc/openvpn/easy-rsa/2.0/vars где прописываем свои настройки, чтобы этого не делать при создании сертификатов:
export KEY_COUNTRY=”RU”
export KEY_PROVINCE=”RF”
export KEY_CITY=”Moscow”
export KEY_ORG=”Peredelka”
export KEY_EMAIL=”admin@odminblog.ru”
export KEY_CN=vpn-server
export KEY_NAME=odmin_root
export KEY_OU=Adminz

После этого надо дать права на исполнение для некоторых файлов:
# chmod +x whichopensslcnf vars clean-all build-ca pkitool build-key-server build-key build-dh
после чего можно инициировать создание файлов ключей (если вы используете bash, то первую команду можно опустить):
# sh
# . vars
# ./clean-all
# ./build-ca
где собственно в диалоге уже будут прописаны наши данные, так что стоит ограничиваться только нажатием энтера.
Теперь создаем сертификат X.509 для нашего сервера, который мы указали в KEY_CN=vpn-server, при этом нам будет предложено задать пароль для обмена ключами, а также надо отметить, что переменную An optional company name [] следует задавать той же что и была указана для создания корневого сертификата Organization Name (eg, company). После этого подписываем наш сертификат своими силами.
# ./build-key-server vpn-server
Создаем сертификат X.509 для клиентской части, при этом имя клиента KEY_CN мы указываем отличным от имени сервера, например vpn-client.
# ./build-key vpn-client
Теперь генерим ключи Диффи-Холмана, которые будут использоваться при хендшейках и обмене ключами:
# ./build-dh
генерация займет некоторое время, но она идет на автомате. На последок создаем файл для TLS аутентификации:
# openvpn –genkey –secret keys/ta.key
после чего в папке keys смотрим полученные ключики, которые соотносятся следующим образом.

Ключи сервера:
ca.crt , vpn-server.crt , vpn-server.key, dh1024.pem, ta.key
Ключи клиентской части:
ca.crt , vpn-client.crt , vpn-client.key, ta.key
Серверные ключики копируем из папки создания в папку openvpn, созданную нами первоначально  /usr/local/etc/openvpn/keys, после чего переходим к редактированию файла конфигурации /usr/local/etc/openvpn/openvpn.conf
### openvpn.conf  ###
dev tun0
port 5656
proto udp
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/vpn-server.crt
key /usr/local/etc/openvpn/keys/vpn-server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
tls-auth /usr/local/etc/openvpn/keys/ta.key 0
client-config-dir ccd
# задаем подсеть сервера VPN
server 172.16.0.0 255.255.255.0
# Прописываем маршрутизацию на внутреннюю сетку (у меня 192.168.0.0)
push “route 192.168.0.0 255.255.255.0″
# Маршрутизация для клиента
route 172.16.0.0 255.255.255.252
tls-server
tls-timeout 120
comp-lzo
auth MD5
cipher BF-CBC
keepalive 10 120
max-clients 100
user nobody
group nobody
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
#########
Создаем файл c именем клиентского хоста, заданным при генерации сертификата:
# echo “ifconfig-push 172.16.0.2 172.16.0.1″ > /usr/local/etc/openvpn/ccd/vpn-client
при этом у нас получается подсеть для клиента с маской 255.255.255.252 которую мы указывали в файле настроек, так что в нашем случае это будет туннель с клиентской частью 172.16.0.2, серверной частью 172.16.0.1, широковещательным адресом 172.16.0.3 и адресом сетки 172.168.0.0, так что последующих клиентов эта запись будет иметь вид (в файлах для их имён и сертификатов):
ifconfig-push 172.16.0.6 172.16.0.5
ifconfig-push 172.16.0.10 172.16.0.9
ifconfig-push 172.16.0.14 172.16.0.13
если кто не понял то адресация IP идет +4

также создаем файлы журналирования:
# mkdir /var/log/openvpn
# touch /var/log/openvpn/openvpn-status.log
# touch /var/log/openvpn/openvpn.log
Открываем на нашем фаерволе входящий трафик на порт udp/5656 для того чтобы внешние клиенты могли подрубаться к нашему VPN серверу, а также разрешить прохождение трафика через интефрейс OpenVPN и внутресетвой трафик.

Теперь копируем сертификаты клиентской части на внешний носитель, так как они нам буду нужны на локальной машине при настройке удаленного клиента.

Вроде как теперь все должно работать, так что для того чтобы все запустилось- перезапускаем сервер, и настраиваем клиента на локальной машине.
На локальной машине, ставим пакет OpenVPN, который можно взять с офф.сайта. После этого сливаем клиентские файлы: ca.crt , vpn-client.crt , vpn-client.key, ta.key в папочку C:\Program Files\OpenVPN\config (или той куда ставили клиента) и создаем в ней файл клиентских настроек openvpn.ovpn, в который прописываем следующие параметры:
#### openvpn.ovpn ###
dev tun0
proto udp
# внешний IP VPN-сервера
remote X.X.X.X
# порт подключения
port 5656
client
resolv-retry infinite
ca ca.crt
cert vpn-client.crt
key vpn-client.key
tls-client
tls-auth ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
verb 3
#########

После этого запускаем клиента и он автоматом ломится на наш сервак и устанавливает сессию.

Собственно на этом можно было бы закочить, если бы в сети не жили беспокойные парни, которым обязом надо поставить себе Windows 7, да еще и x64. Для запуска OpenVPN под Windows 7 следует ставить версию openvpn-2.1_rc19 (или какую нить другую от _rc15). Выкачиваем её и щелкаем правой кнопкой на инсталлер: Свойства -> Совместимость -> Запустить пакет в режиме Windows Vista , а также выставить галку “Выполнять эту программу от имени администратора“. После этого можно запускать инсталлер, который встанет без проблем, после чего на значке OpenVPN GUI надо будет также выставить, что запускать его следует от админа.

Для особо беспокойных, живущих в режиме параноик-мод, файлы ключиков, можно записать например на шифрованный диск или внешний носитель, и запускать клиент только после того как диск будет подмонтирован, тогда в openvpn.ovpn , пути настроек будут выглядеть следующим образом (сертификаты расположены в папке keys):
ca  “X:\\keys\\ca.crt”
cert “X:\\keys\\vpn-client.crt”
key “X:\\keys\\vpn-client.key”
tls-auth “X:\\keys\\ta.key” 1

При установке клиента под Линух, файл конфигурации клиента openvpn.conf должен лежать в папке /usr/local/etc/openvpn , местоположение ключиков задаем естественно из него.

На тему настройки клиента под Mac я видимо отпишусь позже, так как мне это поставили на вид, но настраивать я не стал, так как макаки у меня под рукой нет, а убивать полдня на поиск имиджа по виртуалку меня заломало. Так что как только мне выдадут подопытную обезьяну, то отпишусь по результатам.

С помощью стандартного сервера доменных имен BIND, настроить такой сервер, на базе любой *nix системы, можно за считанные минуты, но при этом необходимо выполнить некоторое количество телодвижений, которые я и перечислю ниже.

В файл /etc/rc.conf добавляем строку запускающую наш сервер доменных имен:
named_enable=”YES”
Открываем наш файл, отвечающий за локальных резолв /etc/resolv.conf и меняем его содержимое (вероятнее всего там стоит провайдерские DNS), на следующие строки, содержащие ваши домены:
domain  your-domain.ru
search host.your-domain.ru your-domain.ru
nameserver 127.0.0.1
для того чтобы сделать поиск доменных имен по кешу локального сервера.
Проверяем в файле /etc/nsswitch.conf наличие записи
hosts:      files dns
говорящей о том, что при резолве имен сначала будет использоваться информация содержащаяся в файле /etc/hosts, а затем запрашивать у доменных серверов, в соответствии с описанием в файле /etc/resolv.conf
После этого в файл /etc/host.conf добавляем строку
order hosts,bind
которая разрешает ту же последовательность, что и в файле /etc/nsswitch.conf
После этого переходим к настройке основного файла конфигурации любого доменного сервера, а не только кеширующего: /etc/namedb/named.conf. Для начала добавляем и раскомментируем следующие опции, идущие списком после директивы options {
Каждая строка, а также перечисление например IP адресов, должно закрываться символом точки с запятой “;”
Определяем на каких интерфейсах слушать входящие пакеты:
listen-on       { 127.0.0.1; 192.168.0.1; 172.16.0.1; };
Данную строку следует прописывать, если возникают какие то проблемы с фаерволом:
query-source address * port 53;
Также если охота поиграться с безопасностью, то можно озвучить сети, из которых разрешены запросы (сети определяем перед директивой options), а также отрубить фингерпринт и включить обработчик рекурсивных запросов:
acl “our_lanz” { 192.168.0.0/24; };
options {
directory “/etc/namedb”;
allow-recursion { “our_lanz”; };
allow-query {“our_lanz”; };
version “unknown”;
fake-iquery no;
};
Добавляем директивы запросов к DNS провайдера, для того чтобы дергать запросы из них и тем самым облегчить работу сетки:
forwarders {
NS_IP1; NS_IP2;
};
forward first;
На этом в принципе можно и остановиться, ибо все должно уже начать шуршать, после перезапуска сервера доменных имен, но для того чтобы произвести классические действия- идет в описание доменных зон и добавляем локальные зоны:
zone “.” {
type hint;
file “named.root”;
};
zone “0.0.127.in-addr.arpa” {
type master;
file “master/127.0.0″;
};
Надо отметить, что все эти файлы указываются от корневой директории named.conf, так что создаем упомянутый файл /etc/named/master/127.0.0
@               IN      SOA     host.your-domain.ru. hostmaster.your-domain.ru. (
1       ; Serial
8H      ; Refresh
2H      ; Retry
1W      ; Expire
1D)     ; Minimum TTL
NS      host.your-domain.ru.
1                       PTR     localhost.
и проверяем что файл /etc/named/named.root содержит информацию о корневых доменных серверах, в нем на самом деле много инфы, вроде подобного:
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
Теперь радостно перезапускаем наш сервер доменных имен, и можем спокойно тестить или заниматься другими делами.
Тестится естественно через терзания nslookup’a:
# nslookup
Default server: 127.0.0.1
Address: 127.0.0.1#53
> odminblog.ru
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   odminblog.ru
Address: 174.120.3.60

Как видно из Non-authoritative answer сервер берет эти данные из кеша, о чем нас и предупреждает этой надписью.

После внесения изменений в правила фаервола, данные правила можно применить без перезагрузки фаервола, просто перечитав файл правил, причем это может быть как дефолтовый файл, так и рандомный:
# ipf -Fa -f /etc/ipf.rules
где,
-Fa сброс всех правил фаервола.
-f указывает фаайлец с новыми правилами фаервола (так что не ошибитесь, ибо как вы помните фаервол мы собираели с блоком по умолчанию)

Полную статистику работы фаервола с момента загрузки системы  можно просмотреть командой
# ipfstat
При этом ключ -ih выдаст количество входящих пакетов, со статистикой прохождения или блокировок с попаданием в правила,
ключ -oh выдаст туже статистику для исходящих пакетов. Это отличное подспорье в оптимизации работы фаервола, путем помещения наиболее часто используемых правил фаервола наверх таблицы.
Обнулить эту статистику можно командой
# ipf -Z
Просмотреть проходящие пакеты в режиме реального времени, можно командой
# ipmon
собственно её вывод и пишется в логфайл.

При использовании ключа  -n адреса и порты будут преобразованы в хостнеймы и сервисы, что довольно удобно для мониторинга того- кто где сидит в данный момент,
а при использовании ключа -x данные проводящих пакетов будут выводиться в hex-коде, что тоже может доставить много интересных минут сисадмину.
Используя команду ipnat можно просматривать таблицу состояния адрес трансляций:
# ipnat -l выведет все открытые на данный момент трансляции адресов
# ipnat -s выводит статистику работы адрес трансляции
# ipnat -F обнуляет все активные соединения из актуальной таблицы адрес трансляций

У ipnat есть, по умолчанию вшитое, количество возможных открытых сессий, и проверить его можно командой:
# ipf -T list | grep nattable
и вероятнее всего вы получите ответ что максимальное число открытых сессий 30к, что для большой сети не так уж и много, так что увеличить это число можно добавив в файл rc.conf следующую строчку:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000 -E”
и перегрузив ipfilter, тем самым увеличив число сессий до 200к.
Также если ваш ipnat.rules предполагает более 127 правил, которые установлены по умолчанию, вам необходимо  также добавить в переменную ipfilter_flags файла rc.conf ключики ipf_natrules_sz=1023,ipf_rdrrules_sz=1023
Еще один момент касаемый уменьшения таймаута TCP сессии, что также позволит оптимизировать работу NAT, так как многие сессии сохраняются в таблице не смотря на то что соединение уже давно закончилось. Для этого добавляем во флаги, также ключи fr_tcptimeout=180,fr_tcpclosewait=60,\
fr_tcphalfclosed=7200,fr_tcpidletimeout=172800
В итоге на выходе в rc.conf имеем следующее выражение:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000,fr_tcptimeout=180,\
fr_tcpclosewait=60,fr_tcphalfclosed=7200,fr_tcpidletimeout=172800,\
ipf_natrules_sz=1023,ipf_rdrrules_sz=1023 -E”

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

Переведем данное мероприятие сразу же в плоскость экономической выгоды для сисадмина, ибо на мой взгляд, настройка программного брандмауэра находится на втором месте, после лечения компьютера от вирусов, и перед восстановлением данных- по соотношению заработанных средств к затраченному времени. Поскольку на настройку программного фаервола на базе FreeBSD тратится от 6 до 10 часов, с момента как вы включили пустую машину, до момента когда вы можете уже включать данный сервер в разрез сети. Естественно, что поднять сам фаервол займет от силы полтора-два часа на создание и обкатку правил: большую часть времени занимает пересборка и апгрейд системы.

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

Итак- настраиваем программный фаервол на базе FreeBSD.

Ставить буду ipfilter, исключительно по идейным соображениям работы ipfw с NAT и тем что сам функционал ipfilter для меня проще и давно изучен (опять же про установку PF расскажу как нить позже, но его ставить на конторский фаервол усомнился, так как имеются траблы с многопоточностью). Описывать процедуры я буду не полностью, так как, о части работ я уже писал ранее, так что просто отошлю к этим постам.

Для начала поднимаем сервер FreeBSD (я для последнего раза выбрал систему FreeBSD 8.2), на котором проводим обновление системы и дерева портов, после чего раздракониваем нашу систему на предмет повышения безопасности. После этого пересобираем ядро системы, отключая не нужные нам дрова (тут не лишне будет перелопатить dmesg на предмет наличия устройств, чтобы не забанить что-нить архиважное- например IPv4 вместо IPv6), и предварительно включив в ядре поддержку ipfilter:
options     IPFILTER # поддержка IPFilter
options     IPFILTER_LOG # поддержка логирования IPFilter
options     IPFILTER_DEFAULT_BLOCK # блокируем все пакеты по умолчанию
options     IPFILTER_LOOKUP
также, если не добавляли при настройке усиленной системы, то ставим следующие опции ядра
options IPSTEALTH # не увеличивает счетчик TTL при прохождении пакета
options TCP_DROP_SYNFIN # дропаем SYN/FIN пакеты, но не работает вроде как с 7 ветки
options SC_DISABLE_REBOOT # запрет перезагрузки сервера через Ctrl+Alt+Del
options         SOFTUPDATES # включение технологиии softupdate для тюнинга работы системы

По хорошему, перед правкой ядра стоит на всякий случай почитать следующие файлы, хотя бы для повышения личной образованности, а уж в случае наличия ошибок при сборке ядра- однозначно:
/usr/sys/UPDATING
/usr/src/sys/conf/NOTES

Пересборку ядра проводим с включенными опами, только в случае локальной установки, в случае же удаленной установки, от греха- сначала настраиваем правила ipf и врубаем поддержку фаервола в rc.conf, только после чего пересобираем ядро, чтобы не получилось лока фаервола в удаленном офисе, что является классическим косяком удаленного админа.

Затем включаем в системе поддержку фаервола, путем добавления следующих операндов в файл /etc/rc.conf :
######################################
ipfilter_enable=”YES”
ipnat_enable=”YES”
ipfilter_rules=”/etc/ipf.rules”
ipnat_rules=”/etc/ipnat.rules”
gateway_enable=”YES”
icmp_bmcastecho=”YES”
ipmon_enable=”YES”
ipmon_flags=”-D /var/log/ipmon.log &”
########################################

Создаем вышеупомянутые файлы ipf.rules и ipnat.rules , делаем их владельцем root и задаем на них права 644. Затем создаем правило полного доступа для всех в файле /etc/ipf.rules. Естественно что помимо lo0, добавляем все имеющиеся в системе интерфейсы и особенно те, через которые мы и настраиваем сервер- в моем случае это внутренний интерфейс rl0.
#################################
pass in quick on lo0 all
pass out quick on lo0 all
pass out quick on rl0 all
pass in quick on rl0 all
#################################

После этого можем пересобирать ядро и перегружать машину с тем, чтобы инстальнуть новое ядро, а затем, сыграв победное соло на бубне, по корректной загрузке машины, продолжить настройку остальных опций.

Далее несколько подправляем работу ядра через файл настроек  /etc/sysctl.conf для добавления всяческих фич противодействия DoS и DDoS атакам, а также повышению безопасности системы, которые сохраняются, благодаря файлу, в системе и после перезагрузки. Здесь их подробно описывать не буду, а как нить позже приведу полный разбор полетов- пока просто вписываем в указанный файл следующие значения (файл создаем при его отсутствии):

net.inet6.ip6.redirect=0
kern.ipc.somaxconn=32768
net.inet.tcp.blackhole=1
net.inet.udp.blackhole=1
net.inet.tcp.msl=7500
net.inet.tcp.sendspace=32768
net.inet.tcp.recvspace=32768
net.inet.tcp.syncookies=1
net.inet.tcp.log_in_vain=1
net.inet.udp.log_in_vain=1
net.inet.tcp.sack.enable=1
net.link.ether.inet.max_age=1200
net.inet.ip.redirect=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.ip.ttl=64
net.inet.ip.random_id=1
net.inet.ip.forwarding=1
net.inet.ip.check_interface=1
net.inet.icmp.bmcastecho=0
net.inet.icmp.maskrepl=0
net.inet.icmp.maskrepl=0
net.inet.icmp.icmplim=30
net.inet.icmp.icmplim_output=0
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1

net.inet.tcp.drop_synfin=1 # если подключили в ядре опцию TCP_DROP_SYNFIN

Затем настраиваем ротацию логов фаервола, для чего устанавливаем пакет logrotate:
# cd /usr/ports/sysutils/logrotate/
# make && make install && make clean
Создаем и настраиваем конфиг ротации логов:
# cp /usr/local/etc/logrotate.conf.sample /usr/local/etc/logrotate.conf
добавляем в файл logrotate.conf следующие строки
############### logrotate.conf
/var/log/ipmon.log {
Daily # какова периодичность ротации логов
rotate 14 # какое количество логов хранить
missingok # игнорировать отсуствие файла ipmon.log
notifempty #  не обрабатывать лог файл, если он пустой
noolddir # содержать все файлы логов в одном каталоге
compress #  сжимать обработанные логи
postrotate # описание что делать  с ipmon после ротации
/sbin/killall -HUP ipmon # в нашем случае перезапустить ipmon
endscript #  конец описания действия после ротации
} #   конец описания ротации файла протокола ipfilter
###########################

Добавляем наш ротатор логов в крон:
0 1 * * * /usr/local/sbin/logrotate -s /var/lib/logrotate.status /usr/local/etc/logrotate.conf

Создаем сам лог файл через команду
# touch /var/log/ipmon.log
ибо автоматом он не создастся, и с чувством глубокого удовлетворения переходим к настройке правил фаервола и адрес-трансляции пакетов.

Начем с правил NAT ибо их меньше и они проще (предположим что внешний интерфейс fxp0). Надо отметить что правило проксирования исходящих ftp-сессий ставится первым, за ним идут адрес-трансляции для внутренних серверов (адрес Server-FW_external_IP поднимается алиасом на внешнем интерфейсе фаервола), если их необходимо представить в инете, а за ними уже следуют правила ната для сетки:
####### /etc/ipnat.rules #######

map fxp0 internal_NET_IP/24 -> FW_external_IP/32 proxy port ftp ftp/tcp
### Безусловная трансляция на внутренний адрес
map fxp0 Server_exnternal_IP/32  -> Server-FW_external_IP/32
bimap fxp0 Server_external_IP/32 -> Server-FW_external_IP/32
##########
### Редирект порта с внешнего интерфейса фаервола на внутреннюю машину (как пример RDP)
rdr fxp0 external_GW_IP port 3389 -> Server_internal_IP port 3389 tcp
#########
map fxp0 internal_NET_IP/24 -> 0.0.0.0/32
map fxp0 internal_NET_IP/24 -> FW_external_IP/32 portmap tcp/udp 20000:64000 # натим порты
############################

Теперь переходим к настройке самого муторного- правилам фаервола. Помним о том, что в классическом фаерволе перебор правил идет сверху вниз, поэтому все блокировки помещаем вниз, кроме единственных закрывающих атаки cifs. Также разрешаем внутрисетевой трафик в нашей локальной сети, что мы уже определили первыми правилами в самом начале (rl0 у нас внутренний интерфейс):
####### /etc/ipf.rules #######
### Разрешаем внутрисетевой трафик
pass in quick on lo0 all
pass out quick on lo0 all
pass out quick on rl0 all
pass in quick on rl0 all
### Лочим все прорезки в виндовые уязвимости
block in log quick on fxp0 proto tcp from any to any port = 113
block in log quick on fxp0 proto tcp/udp from any to any port = 135
block in log quick on fxp0 proto tcp/udp from any to any port = 136
block in log quick on fxp0 proto tcp/udp from any to any port = 137
block in log quick on fxp0 proto tcp/udp from any to any port = 138
block in log quick on fxp0 proto tcp/udp from any to any port = 139
block out log on fxp0 proto tcp/udp from any to any port = 135
block out log on fxp0 proto tcp/udp from any to any port = 136
block out log on fxp0 proto tcp/udp from any to any port = 137
block out log on fxp0 proto tcp/udp from any to any port = 138
block out log on fxp0 proto tcp/udp from any to any port = 139
block out log on fxp0 proto tcp/udp from any to any port = 445
### Разрешаем NS-запросы из сети
pass out quick on fxp0 proto tcp from any to DNS1 port = 53 flags S keep state keep frags
pass out quick on fxp0 proto udp from any to DNS1 port = 53 keep state keep frags
pass out quick on fxp0 proto tcp from any to DNS2 port = 53 flags S keep state keep frags
pass out quick on fxp0 proto udp from any to DNS2 port = 53 keep state keep frags
### Разрешаем выход пассивного FTP протокола
pass out quick on fxp0 proto tcp from any to any port = 20 flags S keep state keep frags
pass out quick on fxp0 proto tcp from any to any port = 21 flags S keep state keep frags
### Разрешаем работу по ssh на нашем фаерволе на своем порту
pass in quick on fxp0 proto tcp from any to any port = 19212 flags S keep state
### Разрешаем протокол smtp только к почтовому серверу, для предотвращения работы потенциальных спам-ботов
pass out quick on fxp0 proto tcp from any to MAIL_SERVER_IP port = 25 flags S keep state keep frags
#### Разрешаем работу whois из сети
pass out quick on fxp0 proto tcp from any to any port = 43 flags S keep state keep frags
#### Разрешаем просмотр сайтов по http
pass out quick on fxp0 proto tcp from any to any port = 80 flags S keep state keep frags
### Получаем почту по pop3
pass out quick on fxp0 proto tcp from any to any port = 110 flags S keep state keep frags
### Разрешаем работу по протоколу https
pass out quick on fxp0 proto tcp from any to any port = 443 flags S keep state keep frags
pass out quick on fxp0 proto tcp from any to any port = 591 flags S keep state keep frags
### Разрешаем работу по FTP в пассивном режиме, когда сервер выбирает порт для работы
pass out quick on fxp0 proto tcp from any to any port > 1023 flags S keep state keep frags
# Разрешаем работу traceroute
pass out quick on fxp0 proto udp from any to any port 33434 >< 33525 keep state keep frags
# Разрешаем пинг во вне
pass out quick on fxp0 proto icmp from any to any keep state keep frags
### Разрешаем вход внутрь сетки по RDP
pass in log quick on fxp0 proto tcp from any to RDP_Server_IP port = 3389 flags S keep state keep frags
### Разрешаем из сети работу линейки
pass out quick in fxp0 proto tcp/udp from Client_IP to  217.117.182.1 port > 10 keep state
pass in quick on fxp0 proto tcp/udp from  217.117.182.1 to GW_internal_IP port > 10 keep state
pass out quick in fxp0 proto tcp/udp from any to any port = 2106 keep state
pass in quick on fxp0 proto tcp/udp from any to any port = 2106 keep state
### Обрабатываем работу icmp протокола
pass in on fxp0 proto icmp from any to any icmp-type echo
pass in on fxp0 proto icmp from any to any icmp-type echorep
pass in quick on fxp0 proto icmp from any to any icmp-type 3 keep state keep frags
pass in quick on fxp0 proto icmp from any to any icmp-type 11 keep state keep frags
block return-icmp (3) in proto udp from any to any port > 30000
block return-icmp (3) in on fxp0 proto icmp from any to any icmp-typenunreach code 3
block in proto icmp all
### Блокируем все остальное
block out log first quick on fxp0 all
block in quick on fxp0 from 192.168.0.0/16 to any    #RFC 1918 private IP
block in quick on fxp0 from 172.16.0.0/12 to any     #RFC 1918 private IP
block in quick on fxp0 from 10.0.0.0/8 to any        #RFC 1918 private IP
block in quick on fxp0 from 127.0.0.0/8 to any       #loopback
block in quick on fxp0 from 0.0.0.0/8 to any         #loopback
block in quick on fxp0 from 169.254.0.0/16 to any    #DHCP auto-config
block in quick on fxp0 from 192.0.2.0/24 to any      #reserved for docs
block in quick on fxp0 from 204.152.64.0/23 to any   #Sun cluster interconnect
block in quick on fxp0 from 224.0.0.0/3 to any       #Class D & E multicast
block in log quick on fxp0 all with frags
block in log quick on fxp0 proto tcp all with short
block in log quick on fxp0 all with opt lsrr
block in log quick on fxp0 all with opt ssrr
block in log first quick on fxp0 proto tcp from any to any flags FUP
block in log quick on fxp0 all with ipopts
block in log quick on fxp0 proto icmp all icmp-type 8
block in log first quick on fxp0 all
block in log all
block out log all
#####################

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

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

З.Ы. Хотел написать об этом моменте в отдельном посте, но решил что это будет не очень корректно, так что привожу в виде небольшого послесловия. Дело в том, что файл правил фаервола ipf поддерживает набор переменных, что конечно же гораздо удобнее для системного администратора, так как позволяет переносить файл правил с одного шлюза на другой, корректируя только объявления переменных в самом начале файла. Одна беда, что сам пакет ipf не понимает переменные и файл с ними надо сохранять в отдельный скрипт /etc/ipf.rules.script, запуская который пользователь создает или обновляет правила в файле ipf.rules. В сам скрипт пишется следующее:
### ipf.rules.script ###

### Описание переменных
oif=”fxp0″ # имя внешнего интерфейса
odns=”DNS1-IP” # IP адрес внешного DNS сервера
mynet=”172.168.0.0″ # Внутренняя сетка
ks=”keep state”
fsks=”flags S keep state”
###
cat > /etc/ipf.rules << EOF
# Доступ из сети к внешнему DNS серверу
pass out quick on $oif proto tcp from any to $odns port = 53 $fks
pass out quick on $oif proto udp from any to $odns port = 53 $ks
# Разрешить выход из сети во вне по http
pass out quick on $oif proto tcp from $mynet to any port = 80 $fks
#### ну и так далее

После изменения правил фаервола необходимо запустить данный скрипт, что бы правила перечитались и файл ipf.rules обновился:
# sh /etc/ipf.rules.script

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

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

Собственно для начала имеем две сетки: 192.168.0.0/24 (основная) и 192.168.10.0/24 (дополнительная) которые нам и надо совокупить посредством нашего настроенного сервера FreeBSD, в который мы же загодя воткнули две-три-четыре и более сетевых карт (максимум который у меня прекрасно существовал было 5 сопряженных сетей, не считая вирутальных интерфейсов). Предположим что для сетевых интерфейсов мы выбрали IP адреса: 192.168.0.1 и 192.168.10.1

Смотрим что за интернерфейсы установлены в системе:
# ifconfig
тут нам главное понять какой интерфейс какой, для чего не плохо было бы ознакомиться с чипами карт. Порядок интерфейсов обычно идет от проца к периферии, а у дополнительных интерфейсов в зависимости от нумерации слотов, возрастая от видюхи. Но проверить все это можно эмперическим путем просто воткнув рабочий кабель в систему, посе чего интерфейс перейдет из статуса status: no carrier в status: active. Предположим у нас в системе два интерфейса rl0 и rl1.
Поняв какие интерфейсы будем сопрягать, идем в /etc/rc.conf и добавляем необходимый интерфейс, так как там уже должен присуствовать один из интерфейсов, если в процессе настройки системы FreeBSD мы поднимали сетку.
##### /etc/rc.conf #####
ifconfig_rl0=”inet 192.168.0.1 netmask 255.255.255.0″
ifconfig_rl1=”inet 192.168.10.1 netmask 255.255.255.0″
#####################
Чтобы поднять теперь интерфейс, выполним
# /etc/netstart
Второй интерфейс rl1 ожил и теперь пингуется из подсети 192.168.10.1, но для того чтобы сервер настроить как маршрутизатор необходимо в ядре разрешить пересылку пакетов между пакетами, за что отвечает парметр net.inet.ip.forwarding. Его значение в системе в данный момент:
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
где значение 0 означает что маршрутизация запрещена, поэтому для включения функционала маршрутизации, нам необходимо присвоить этому значению 1, для чего выполняем:
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Теперь настройка маршрутизации завершена и маршрутизатор будет фурычить до перезагрузки системы, после чего значение net.inet.ip.forwarding переключится обратно в 0. Для того чтобы избежать этого добавляем в файл /etc/rc.conf следующую строку:
gateway_enable=”YES”
после чего уже безбоязненно можем перегрузить машину.
При такой схеме наш маршрутизатор будет рутить только сопряженные с ним сети, представленные интерфейсами, или же алиасами на интерфейсах, в том же случае когда у нас в сети уже существуют маршрутизаторы, прикрывающие еще какие то сети, то тогда поднимаем на нашей машине статическую таблицу маршрутизации. Делается это также в файле /etc/rc.conf
##### /etc/rc.conf #####
static_routes=”network1 network2 network3″
route_network1=”-net 10.10.15.0/24 192.168.0.25″
route_network2=”-net 172.168.10.0/24 192.168.0.25″
route_network3=”-net 192.168.168.0/24 192.168.10.111″
#####################
то есть мы задаем названия маршрутов, которые дальше выводим в виде сетки, и внешнего, для нашего маршрутизатора, интерфейса шлюза.
Также в случае использовании настроенного сервера FreeBSD в качестве внутреннего маршрутизатора, необходимо на внешнем шлюзе, заданном для рабочих станций и серверов сети дефолтным маршрутом, поднять маршрутизацию на внутреннюю сеть задав маршрут в 192.168.10.0, через 192.168.0.1. На самом деле тут обычно и возникает самый косячный момент, особенно в случае использования интернет шлюзом аппаратных фаерволов типо D-Link, у которых вроде функционал рутинга имеется, но чтобы настроить удаленный маршрут надо долго и упорно танцевать с бубном, так что гораздо проще для нашего уже настроенного маршрутизатора задать дефолтовым маршрутом интернет-шлюз, а все машины предприятия завернуть на него- это добавит лишний хоп, но уберет проблему настройки маршрутизации на сторонних серверах.

Для начала понимаем что это вообще за класс операционки, путем вывода универсальной для всех Unix-систем команды:
$ uname -a
которая нам выведет что то типо такого:
Linux hostname.com 2.6.18-194.17.4.el5PAE #1 SMP Mon Oct 25 16:35:27 EDT 2010 i686 i686 i386 GNU/Linux
или
FreeBSD hostname.com 5.5-STABLE FreeBSD 5.5-STABLE #0: Wed Dec  5 20:00:38 MSK 2007  email@hostname.com:/usr/obj/usr/src/sys/GENERIC  i386
или
AIX svcas07 3 4 000145364C00
OS Name Release Version Machine ID
из чего нам либо станет понятно кто это, либо перейдем к более подробному изучению линуха, для того чтобы уже конкретно определить версию линукса:
$ cat /proc/version
Linux version 2.6.18-194.17.4.el5PAE (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Oct 25 16:35:27 EDT 2010
то есть нам понятно семейство линуха и версия ядра, тем более что у семейства шапки есть более подробная команда, для того чтобы узнать версию linux:
$ cat /etc/redhat-release
CentOS release 5.6 (Final)
По хорошему это исчерпывающий ответ, но в шапке также имеется дополнительная утилита ставящаяся в полном комплекте, которая выведет более подробную информацию про версию linux:
$ lsb_release -a
LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description:    CentOS release 5.5 (Final)
Release:        5.5
Codename:       Final

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.

Погуглив, почитав и пообщавшись по форумам с людьми, выявил для себя следующие моменты:
под платформу лучше всего использовать отдельный сервер, поскольку на виртуалке могут возникнуть траблы как с трафом, так и с производительными мощностями, особенно в случае если трафик от провайдера приходит в одном кодеке, а в офисе мы используем другой;
для дедика вполне хватит сore2 или core i3, как минимум с 2Гб оперативы на борту, так что на первое время вполне сгодится какой нить десктоп, если руководство жмет деньги на приобретение полноценного сервера;
использовать лучше кодек g711, при этом под каждый активный разговор отводится порядка 64 кбит/с, так что умножаем на это число количество входящих линий и получаем необходимую под VoIP полосу пропускания;
использовать можно FreeBSD или CentOS, хотя тут мнения разделяются, как собственно и в любой холиваре- единственное что я пока осознал, что обновления для платформы Asterisc выходят на Cent OS с большим опозданием, по сравнению с фрей;
для сервака лучше использовать внешний, отдельный IP, поскольку при пробросе SIP портов (5060 udp/tcp и выделенный upd диапазон для траффа) через NAT могут возникнуть проблемы (в моем случае точно, поскольку на D-Link’e эти проблемы возникли даже при пробросе rdp);
можно использовать аналоговые телефоны, но для них придется докупать либо специальную карту в сервер, чья стоимость составляет около 2к грина, либо же VoIP шлюз, который также стоит в районе 200 грин;
цены на IP-телефоны начинают от 4к за более менее нормальные аппараты, так что имеет резон использовать бесплатные софтовые клиенты, так как в этом случае контора попадает только на гарнитуры, чья стоимость составляет от 700 рублей за штуку;
если планируется иметь факс, то его лучше вешать на аналоговую линию, поскольку для передачи факсимильных сообщений требуется идеализированный траффик, в противном случае факсы будут приходить крайне отстойного качества;
сама платформа Asterisc метит траффик, так что использовать для него приоритезацию траффика QoS не составляет проблемы;
некоторые провайдеры имеют свойство зафильтровывать SIP траффик, чтобы потенциальные клиенты не пользовались сторонними сервисами, так что придется либо брать данный вид трафа у этого провайдера, либо же каким то образом договариваться с ним;
в этом же ключе я пробивал возможность использования VoIP со шлюзом Checkpoint, который я уже успел несколько подзабыть за прошедшие полгода, в связи с чем выяснилось несколько моментов: в стандартной поставке Checkpoint FW будет корректно обрабатывать и пропускать VoIP траффик, и даже фильтровать его по политикам безопасности (при заведении объекта шлюза VoIP), а также симафорить с помощью IPS блейда, имеющего стандартными несколько сигнатур для проверки VoIP траффика. Но есть хочется чего то большего, то необходимо приобретать блейд  Voice over IP (VoIP) Software Blade, который этих сигнатур имеет большее количество и к тому же может не только проверять VoIP траффик, но и при необходимости вносить изменения в пакеты: транслировать адреса или вносить исправления в заголовки. Единственный момент здесь в том, что данный блейд встает только на версию R65, то есть весьма и весьма древнюю, так как на новых версиях SPLAT данный блейд не работает.

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

# wget ‘http://www.splunk.com/index.php/download_track?file=4.1.4/freebsd/splunk-4.1.4-82143-FreeBSD-i386.tgz&ac=&wget=true&name=wget&typed=releases’
# tar -xzvf splunk-4.1.4-82143-FreeBSD-i386.tgz

Поскольку, как оказалось, пакет пришел нам в уже собранном виде, то оправляем его по месту постоянного жительства:
# cp -R splunk /usr/local/

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

/boot/loader.conf
kern.maxdsiz=”2147483648″ # 2GB
kern.dfldsiz=”2147483648″ # 2GB
machdep.hlt_cpus=0

/etc/sysctl.conf
vm.max_proc_mmap=2147483647

После этого перегружаем сервер для того чтобы изменения вступили в силу. При желании можем создать ручками пользователя от которого будет работать splunk, а также и его группу, но мне что то сегодня в ломы. Поэтому запускаем сервис: перед первым запуском сервера необходимо согласиться с лицензионным соглашением, для этого стартуем:
# $SPLUNK_HOME/bin/splunk start –accept-license

После некоторого диалога, сервер сообщит, что он теперь запущен на http://our_server_hostname:8000 хотя зайти можно и по адресу http://our_server_IP:8000. В данном случае 8000 это дефолтный порт нашего веб сервера.

Теперь переходим к настройке сервера.
Логин и пароль по умолчанию для входа в web-консоль:
username: admin
password: changeme

В верхнем правом углу белеет на темном фоне кнопочка Manager, нажав на которую мы попадаем в общирное меню, позволяющее нам настроить наш сервер в разделе System configurations, а также добавить необходимые модули Apps, собития, поиски и прочая в разделе Apps and knowledge.

В System settings задается хостнейм и настраиваются веб-морда сервера, а также параметры индексирования. Также настраивается отправка алертов по почте и всевозможные уровни логирования, которых доступно шесть вариантов: DEBUG, INFO, WARN, ERROR, CRIT, FATAL.

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

В этом разборе полетов я буду осуществлять предварительную настройку системы FreeBSD 7.2. Сама система FreeBSD является одной из наиболее защищенных операционных систем, причем её код, не смотря на открытую идеологию open sourse многократно проверяется и тестируется. Не смотря на то, что с комплекте поставки FreeBSD уже идет с сильной безопасностью, существуют меры по её повышению почти до параноидального режима работы.

Для начала мы ставил чистую систему FreeBSD 7.2 и поднимаем на ней стандартный сервер sshd2, чтобы не сидеть в консоли. После этого приступаем к настройкам:

В системе достаточно иметь только одну директорию для хранения временных файлов, хотя в стандартной упаковке их две /tmp и /var/tmp , поскольку разные пакеты используют разные директории. Поскольку нам достаточно одной, то ограничим их в этом свободном выборе, удалив /var/tmp

# mv /var/tmp/* /tmp/
# rm -rf /var/tmp
# ln -s /tmp /var/tmp

Следом отрубаем возможность входа в консоль под пользователем root, ибо заход под ним дает пользователю сразу же неограниченные права на систему. Поэтому пользователь должен подключаться под собой и только после это забирать права с помощью использования команды su. Для это открываем файл  /etc/ttys и меняем каждую запись “secure” на “insecure”, что запретит пользователю root подключаться к консоли. Это же изменение будет будет требовать пароль пользователя root при рагрузке в однопользовательском режиме системы (single-user mode), что в свою очередь значительно усложнит изменение пароля суперпользователя.

# vi /etc/ttys
#########################################################
console none                            unknown off insecure
#
ttyv0   “/usr/libexec/getty Pc”         cons25  on  insecure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv2   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv3   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv4   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv5   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv6   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv7   “/usr/libexec/getty Pc”         cons25  on  insecure
ttyv8   “/usr/X11R6/bin/xdm -nodaemon”  xterm   off insecure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyd0   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd1   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd2   “/usr/libexec/getty std.9600″   dialup  off insecure
ttyd3   “/usr/libexec/getty std.9600″   dialup  off insecure
# Dumb console
dcons   “/usr/libexec/getty std.9600″   vt100   off insecure
#########################################################

Закручиваем безопасность для ssh сервера. Как его вывести на совсем параноидальный режим, буду разбирать позднее. Пока же ограничиваем пользователей имеющих право на вход в консоль, запрещаем вход с пустым паролем и вход пользователю root. Также ограничиваем время отводимое на подключение к серверу и количество попыток.  Включаем вторую версию SSHv2 вместо идущей по умолчанию первой, т.к. она обеспечивает более высокую безопасность соединения. Поскольку использовать X11 на рабочем сервере мы не планируем то отключим опцию форвардинга.

# vi /etc/ssh/sshd_config
#########################################################
Protocol 2
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 15s
PermitRootLogin no
AllowUsers anchous
StrictModes yes
MaxAuthTries 3
PermitEmptyPasswords no
PrintLastLog yes
UsePrivilegeSeparation yes
UseDNS yes
X11Forwarding no
#########################################################

Теперь переходим к политикам хранения паролей. По умолчанию FreeBSD использует алгоритм md5 для хэширования паролей. Это стойкий и надежный 128-битный алгоритм, но некоторое время назад были найдены слабости в его реализации, поэтому рекомендуется использовать алгоритм blowfish для хранения паролей. Для перевода системы хранения паролей в этот алгоритм, нам следует изменить несколько файлов. парои кстати не будут автоматически сконвертированы в blowfish, и будут храниться в md5 до следующего изменения.

# echo “crypt_default=blf” >> /etc/auth.conf

После этого необходимо задать в файле /etc/login.conf параметр хранения паролей по умолчанию в класс blf.  Также меняем политику применяемых паролей: минимальная длинна, использование верхнего и нижнего регистра, время действия пароля в три месяца и отключения пользователя после 10 минут бездействия.  Также меняем маску прав доступа по умолчанию umask для того чтобы предотвратить доступ пользователей для всех. Маска пробразуется в формат chmod, и все новые созданные файлы и папки будут иметь права доступа 0750, т.е. у “остальных” пользователей не будет никаких прав на данные файлы.

# vi /etc/login.conf
#########################################################
default:\
:passwd_format=blf:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
:path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin ~/bin:\
:nologin=/var/run/nologin:\
:cputime=unlimited:\
:datasize=unlimited:\
:stacksize=unlimited:\
:memorylocked=unlimited:\
:memoryuse=unlimited:\
:filesize=unlimited:\
:coredumpsize=unlimited:\
penfiles=unlimited:\
:maxproc=unlimited:\
:sbsize=unlimited:\
:vmemoryuse=unlimited:\
:priority=0:\
:ignoretime@:\
:minpasswordlen=8:\
:mixpasswordcase=true:\
:passwordtime=90d:\
:accounted=true:\
:autodelete=90d:\
:warnpassword=14d:\
:idletime=10:\
:umask=027:
#########################################################

Обновляем базу логинов:

# /usr/bin/cap_mkdb /etc/login.conf

После смены пароля пользователя в файле их хранения in /etc/master.passwd  записи паролей будут начинаться с $2a. Это будет свидетельствовать о том, что для данного пользователя включилось хеширование blowfish.

Теперь переназначаем правда доступа для пользователей к планировщику задач. Планировщик задач является удобным и в тоже время чрезвычайно мощным средством администрирования *nix платформ. Его неправомочное и неправильное использование может привести сервер в неработоспособное состояние. Это может быть неправильно составленые задания, так и злонамеренное зацикливание выполнения задания, способное привести машину к отказу в обслуживании.

Назначаем права на планирование задач только для пользователя root

# echo “root” > /var/cron/allow
# echo “root” > /var/at/at.allow
# chmod o= /etc/crontab
# chmod o= /usr/bin/crontab
# chmod o= /usr/bin/at
# chmod o= /usr/bin/atq
# chmod o= /usr/bin/atrm
# chmod o= /usr/bin/batch

Также ограничим доступ на чтение и запуск некоторых файлов, к которым у обычных пользователей нет необходимости в доступе:

# chmod o= /etc/fstab
# chmod o= /etc/ftpusers
# chmod o= /etc/group
# chmod o= /etc/hosts
# chmod o= /etc/hosts.allow
# chmod o= /etc/hosts.equiv
# chmod o= /etc/hosts.lpd
# chmod o= /etc/inetd.conf
# chmod o= /etc/login.access
# chmod o= /etc/login.conf
# chmod o= /etc/newsyslog.conf
# chmod o= /etc/rc.conf
# chmod o= /etc/ssh/sshd_config
# chmod o= /etc/sysctl.conf
# chmod o= /etc/syslog.conf
# chmod o= /etc/ttys

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

# chmod o= /var/log
# chflags sappnd /var/log
# chflags sappnd /var/log/*

Отключаем пользователям возможность использования части программ, в которых нет необходимости, по их юзверьским делам.

# chmod o= /usr/bin/users
# chmod o= /usr/bin/w
# chmod o= /usr/bin/who
# chmod o= /usr/bin/lastcomm
# сhmod o= /usr/sbin/jls
# chmod o= /usr/bin/last
# chmod o= /usr/sbin/lastlogin

Также надо заблокировать несколько сервисов:

# chmod ugo= /usr/bin/rlogin
# chmod ugo= /usr/bin/rsh

а также ограничить доступ к продуманным и полезным, для системного администратора конечно, утилитам, которые скорее всего будут установлены на машину:

# chmod o= /usr/local/bin/nmap
# chmod o= /usr/local/bin/nessus

В правами вроде бы закончили, теперь перейдем к горячо любимому файлу /etc/rc.conf в котором мы прикроем некоторые сервисы запущенные в системе по умолчанию, но нам ненужные.
Отключаем MTA, которым по умолчанию является sendmail. Если этот сервис необходим, то имеет смысл использоваться exim или qmail

# echo ’sendmail_enable=”NONE”‘ >> /etc/rc.conf

###############################
***Примечание от 13.012010
По данному синтаксису может возникнуть спор, аналогичный тому что возник у меня с Алексеем ака tess, т.к. по разным версиям фришного мануала sendmail отрубается разным синтаксисом:  по самому man sendmail v.8 рекомендуется использовать приведенный выше, по руководству к самой операционке FreeBSD рекомендуется использовать следующий синтаксис, добавленный в /etc/rc.conf (его же следует использовать если вы хотите чтобы отключить демона работающего на прием почты, а например логи вам высылались ежедневно на почту):

sendmail_enable=”NO”
sendmail_submit_enable=”NO”
sendmail_outbound_enable=”NO”
sendmail_msp_queue_enable=”NO”
###############################

По умолчанию уровень безопасности системы (kernel level) равен -1, т.е. мало защищенный. Если предполагается использовать защищенный уровень, то рекомендуется использовать 2, или даже 3 – как наиболее защищенный.

# echo ‘kern_securelevel_enable=”YES”‘ >> /etc/rc.conf
# echo ‘kern_securelevel=”2″‘ >> /etc/rc.conf

Если не планируется на сервере использовать систему NFS, то отключаем его и демона portmap:

# nfs_server_enable=”NO” >> /etc/rc.conf
# nfs_client_enable=”NO” >> /etc/rc.conf
# echo ‘portmap_enable=”NO”‘ >> /etc/rc.conf

Запрещаем inetd, демон отвечающий за сетевые сервисы (network daemon dispatcher), в виду того что его использование несет много уязвимостей

# echo ‘inetd_enable=”NO”‘ >> /etc/rc.conf

На уровне старта системы чистим директроию временных файлов /tmp , чтобы быть уверенным что весь мусор который может там находиться никаким образом не повлияет на работу нашей системы

# echo ‘clear_tmp_enable=”YES”‘ >> /etc/rc.conf

Если не пишем логи на удаленную машину, то задаем демону syslogd не занимать сетевые сокеты

# echo ’syslogd_flags=”-ss”‘ >> /etc/rc.conf

Cообщения ICMP redirect могут быть использованы для атаки, поэтому игнорируем и логируем их

# echo ‘icmp_drop_redirect=”YES”‘ >> /etc/rc.conf
# echo ‘icmp_log_redirect=”YES”‘ >> /etc/rc.conf

Регистрируем все попытки подключения на закрытые порты, с тем чтобы понимать о том, кто и зачем пытается подключиться на неработающие порты.

# echo ‘log_in_vain=”YES”‘ >> /etc/rc.conf

Чтобы при входе в консоль не выводилась версия OS и координаты ядар, запрещаем обновление файла с сообщением дня (Message of Day)

# echo ‘update_motd=”NO”‘ >> /etc/rc.conf

Задаем несколько параметров ядра путем редактирования файла /etc/sysctl.conf . Для начала запрещаем обычным пользователям просмотр процессов запущенных с иным UID

# echo “security.bsd.see_other_uids=0″ >> /etc/sysctl.conf

Включаем систему поддержки так называемых “черных дыр”, что является предотвращением отправки отклика RST пакета, на запрос пришедший на закрытый порт.

# echo “net.inet.tcp.blackhole=2″ >> /etc/sysctl.conf
# echo “net.inet.udp.blackhole=1″ >> /etc/sysctl.conf

Генерируем произвольный ID для IP пакета для того чтобы исключить возможность fingerprint и затруднить возможность злоумышленника систематизировать пакеты.

# echo “net.inet.ip.random_id=1″ >> /etc/sysctl.conf
# echo “net.inet.icmp.maskrepl=0″ >> /etc/sysctl.conf

Следующая опция ядра подойдет для рутеров, фаерволов и шлюзов: конфигурируем систему отбрасывать SYN/FIN пакеты, при желании её можно включать и на обычных срверах, но это чревато падением производительности.

# echo ‘tcp_drop_synfin=”YES”‘ >> /etc/rc.conf

Вносим небольшие правки в ядро, которое придется пересобрать. Первой мы иключаем возможность перезагрузки от ctrl+alt+del, второй устанавливаем генерацию ID для сетевых пакетов (вариант с sysctl.conf работает только на системах от 5.3, на всех предыдущих необходимо перебирать ядро). Также включаем сброс SYN/FIN и режим stealth forwarding, который позволяет переправлять пакеты через хост без изменения из TTL, т.е. эта функция подойдет например для сокрытия фаервола от команды tracerote

# vi /usr/srs/sys/i386/conf/Custom_KERNEL

#########################################################
options SC_DISABLE_REBOOT # Disable Ctrl+Alt+Del
options RANDOM_IP_ID             # Enables random IP ID generation
options TCP_DROP_SYNFIN     # Enables the ability to drop SYN/FIN packets
options IPSTEALTH                     # Enable stealth forwarding
#########################################################

После чего перестраиваем ядро и перегружаем машину. Теперь у нас есть сервер, на котором максимально поднята безопасность и он готов к тому чтобы настраивать на нем необходимые нам сервисы.

После этого необходимо создать файл: /usr/local/etc/super-users или .su2rc в домашней папке пользователя чьи права необходимо перехватывать, т.е. в нашем случае это будет /root/.su2rc
В этих файлах прописываются имена пользователя, которым разрешается перехватывать права данного пользователя. Права на запись в эти файлы устанавливаем только для root, остальные права можно обнулить. Если перед именем разрешенного пользователя стоит +  то перехват прав происходит без запроса пароля, если при использовании su2 задается ключик -u, то пароль запрашивается в обязательном порядке.

Дальше имеем два пути реализации:
1. который я пользую на внутренних машинах: создаем файл /root/.su2rc  на который линкуем /usr/local/etc/super-users , в них прописываем имена разрешенных пользователей, после чего команда su2 будет запрашивать повторно пароль пользователя (или не запрашивать если поставить +) и повышать ранг прав до суперпользователя

# su2
Password:
#

2. чуть более сложный: когда в единственный файл  /usr/local/etc/super-users пишем пользователя root, т.е. все пользователи системы могут забирать права root, но таким образом, что команда su2 запущенная без аргументов, будет выдавать ошибку авторизации.

# su2
Password:
su2: User anchous is not authorized for this system.
su2: For authorization, see your system administrator.

# echo ‘root’ > /usr/local/etc/super-users
# su2 -u root
Password:
#

Теперь можно пользоваться утилитой su2 для своего удовольствия и безопасности

Наиболее простой способ выяснился после разглядывания подробностей файла /etc/crontab
простая установка директивы  MAILTO= в описании основных параметров отправит всю почту на указанный мейл, но в моем случа нужно давать эпизодического пендаля хозяину сервера, чтобы он следил за своей вотчиной, а я за своей, в этой связи обнаружилось два способа:

корявенький, с указанием директивы mailto в поле команды:
3    1  * * * root MAILTO=xxx@odminblog.ru /root/scripts/mailcleaner.sh
и на мой взгляд более корректный с перенаправлением вывода исполнения скрипта:
3    1  * * * root /root/scripts/mailcleaner.sh 2>&1 | mail -s “Mail base cleaning” xxx@odminblog.ru

, также можно перенаправить вывод выполнения скрипта в лог файл:
3    1  * * * root /root/scripts/mailcleaner.sh >> /var/log/cron.log 2>&1

####################################

begin acl

#  Отбиваем всякие пакости на основе проверки содержимого письма
acl_check_virus:
deny  message   = Message rejected: virus found. NO PASARAN!(Ernesto Che Guevara).
hosts  = *
demime = *
malware = *
accept

acl_check_rcpt:
accept  hosts = :
accept  local_parts =
deny    hosts =

# Задаем почтовые адреса для внутреннего использования, с закрытой внешней пересылкой
deny    message         = SRY, but address not permitted for external use!
hosts           = !+relay_from_hosts
local_parts     = all
!authenticated  = *

# пропускаем почту через RBL
deny    message       = rejected because $sender_host_address is in a black list at $dnslist_domain\n$dnslist_text\
If you think that the system is mistaken, please report details to abuse@odminblog.ru

!authenticated  = *
log_message   = found in $dnslist_domain
dnslists      = relays.mail-abuse.org

deny    message       = rejected, $sender_host_address Open Proxy, see: $dnslist_domain\n$dnslist_text\
If you think that the system is mistaken, please report details to abuse@odminblog.ru

!authenticated  = *
log_message   = found in $dnslist_domain
dnslists      = dnsbl.void.ru

deny    message       = Spam blocked see:http://www.spamcop.net/w3m?action=checkblock&ip=$sender_host_address\
If you think that the system is mistaken, please report details to abuse@odminblog.ru

!authenticated  = *
log_message   = found in $dnslist_domain
dnslists      = bl.spamcop.net

deny    message        = host is listed in $dnslist_domain
!authenticated  = *
log_message   = found in $dnslist_domain
dnslists     =     opm.blitzed.org

deny    message       = rejected, $sender_host_address is listed in: http://relays.osirusoft.com/cgi-bin/rbcheck.cgi \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!authenticated  = *
!local_parts    = abuse                # Эта строка задает игнорирование данного правила для заданных адресов
log_message   = found in spamguard.leadmon.net
dnslists      = spamguard.leadmon.net

deny    message       = rejected, $sender_host_address is listed in: http://www.spamsources.fabel.dk/ \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!authenticated  = *
!local_parts    = abuse
log_message   = found in http://www.spamsources.fabel.dk/
dnslists      = spamsources.fabel.dk

deny    message       = rejected, $sender_host_address is listed in: http://www.spamhaus.org/ \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!authenticated  = *
!local_parts    = abuse
log_message   = found in http://www.spamhaus.org/
dnslists      =         sbl.spamhaus.org : \
xbl.spamhaus.org : \
pbl.spamhaus.org : \
sbl-xbl.spamhaus.org : \
zen.spamhaus.org

# Проводим процедуру обратного звонка, т.е. при поступлении запроса на отправку от отпределенного адреса, происходит встречный запрос к серверу отправителя
verify = sender/callout=90s,maxwait=120s
verify = recipient/defer_ok/callout=90s/callout_defer_ok
message = The sender cannot be verified. Check your email-client settings! \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!local_parts    = abuse
!sender_domains = +domains_disable_senderverify # в данном списке, объявленом в главной конфигурации, мы задаем исключения для доменов

deny    message       = rejected, $sender_host_address is listed in: http://mail-abuse.org/ \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!authenticated  = *
!local_parts    = abuse
log_message   =   found in  www.mail-abuse.org
dnslists        = blackholes.mail-abuse.org : \
dialup.mail-abuse.org

# Проверяем диалог на соответствие RFC
deny message        = HELO/EHLO required by SMTP RFC
condition           =  ${if eq{$sender_helo_name}{}{yes}{no}}
delay           = TEERGRUBE

# Проверяем корректность IP адреса отправителя, проверка направлена на манипуляции с HELO
deny message        = Forged IP detected in HELO-$sender_helo_name
hosts          = !+relay_from_hosts
log_message    = Forged IP detected in HELO: $sender_helo_name
!authenticated  = *
condition      = ${if eq{$sender_helo_name}{$interface_address}{yes}{no}}
delay          = TEERGRUBE

# Проверяем корректность IP адреса отправителя, проверка направлена на манипуляции с HELO
deny message        = Forged IP detected in HELO -$sender_helo_name != $sender_host_address
hosts          = !+relay_from_hosts
!authenticated  = *
condition      = ${if match{$sender_helo_name}{\N^\d+(\.\d+){3}$\N} {yes}{no}}
condition      = ${if eq{$sender_helo_name}{$sender_host_address} {no}{yes}}
delay          = TEERGRUBE

deny message        = Forged hostname detected in HELO -$sender_helo_name
hosts          = !+relay_from_hosts
!authenticated  = *
log_message     = Forged hostname detected in HELO -$sender_helo_name
condition       = ${if match_domain{$sender_helo_name}{+local_domains} {yes}{no}}
delay           = TEERGRUBE

# Отбиваем больше одного пустого отправителя
deny message        = Only one recipient accepted for NULL sender
senders        = :
condition      = ${if >{$rcpt_count}{1} {1}}
delay          = TEERGRUBE

####### Данный раздел перекрывает большие листы рассылки и перебор пользователей
.ifdef ALLOWEDRCPTFAIL
drop message   = too many unknown users (${eval:$rcpt_fail_count+1} failed recipients)
log_message    = Dictionary attack (${eval:$rcpt_fail_count+1} failed recipients).
condition      = ${if >{$rcpt_fail_count}{${eval:ALLOWEDRCPTFAIL-2}} {1}{0}}
delay          = ${eval:FAILEDRCPTDELAY*$rcpt_fail_count}s
domains        = +local_domains
hosts          = !+relay_from_hosts
!authenticated  = *
.endif
deny message        = unknown user
log_message    = Teergrube: dictionary attack (${eval:$rcpt_fail_count+1} failed recipients)
condition      = ${if >{$rcpt_fail_count}{0} {1}{0}}
delay          = ${eval:FAILEDRCPTDELAY*$rcpt_fail_count}s
domains        = +local_domains
!verify         = recipient

deny hosts     = !+localadds:!+hosts_disable_callback:*
sender_domains = !+envdomain_disable_callback:!+domains_callback_norandom:!+domains_disable_senderverify:*
local_parts    = !+noenvfromcallback
!verify         = sender/callout=90s,random
delay          = TEERGRUBE

# Проводим обратный звонок, для всех кроме специально заданных доменов и хостов
deny hosts     = !+localadds:!+hosts_disable_callback:*
sender_domains = !+domains_callback_norandom:!+domains_disable_senderverify
local_parts    = !+noenvfromcallback
!verify         = sender/callout=90s
delay          = TEERGRUBE

############### Проводим проверки на уровне SMTP диалога

deny    message       = Wrong HELO – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
!local_parts    = abuse
!authenticated = *
condition     = ${if !match{$sender_helo_name}{\N\w\.\w\N}{yes}{no}}

deny    message       = Too short HELO – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
!local_parts    = abuse
!authenticated = *
condition     = ${if <{${strlen:$sender_helo_name}}{5}{yes}{no}}

deny    message       = Bad HELO domain symbols – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
!local_parts    = abuse
!authenticated = *
condition     = ${if match{$sender_helo_name}{\N_\N}{yes}{no}}

deny    message       = HELO is IP address – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!local_parts    = abuse
condition     = ${if isip{$sender_helo_name}}

deny    message       = Used HELO: $sender_helo_name not equal IP: $sender_host_address – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
!local_parts    = abuse
!authenticated = *
condition     = ${if match{$sender_helo_name}{\N^\[(\d+\.\d+\.\d+\.\d+)\]$\N}\
{yes}{no}}
condition     = ${if !eq{$sender_host_address}{${sg{$sender_helo_name}\
{\N^\[(\d+\.\d+\.\d+\.\d+)\]$\N}{\$1}}}\
{yes}{no}}

deny    message       = Must be letters in HELO domain – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
!local_parts    = abuse
!authenticated = *
condition     = ${if match{$sender_helo_name}\
{\N^[-\d\.]+$\N}{yes}{no}}

deny    message       = Wrong HELO domain – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
!local_parts    = abuse
!authenticated = *
condition     = ${if match{$sender_helo_name}{\N^.*\.(arpa|local|localdomain)$\N}{yes}{no}}

deny    message       = Main Hostname in your HELO – access denied. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !127.0.0.1
!local_parts    = abuse
condition     = ${if match{$sender_helo_name}{$primary_hostname}{yes}{no}}

# Блокировка попытки подмены IP адреса отправителя на адрес получателя
deny     message       = “Go ahead, it’s mine IP!!!!”
condition     = ${if eq{$sender_helo_name}{$sender_host_address} \
{true}{false}}
hosts         = * : !+relay_from_hosts

# Запрет на использование в доменных именах различных приставок модемного доступа, на основе стоп-слов.
deny    message       = Access denied – dsl/dialup/cable relays HELO detected, use your ISP SMTP server. \
If you think that the system is mistaken, please report details to abuse@odminblog.ru
hosts         = !+relay_from_hosts
sender_domains = !+greedy_suckers    # Исключение для серверов, имеющих в имени, приведенные стоп-слова
!local_parts    = abuse
!authenticated = *
condition     = ${if match{$sender_helo_name}\
{\N^((\d{1,3}[\.\-_x]){3}|.*(\d{6,12}|wireless|broadband|modem|dyn|\
cable|client|dial|unused|gprs|dsl|dhcp|user|vpn|home|dip|catv|(v|w)\
lan|as(1|2|3|4|5)|dynamic(?>ip)|host-ip|ppp|cdma|(?<!mx|s)pool|unassigned)\
.*\.[-a-z0-9]+\.\w+|.*(?<!smtp).*(cust|host).*\.[-a-z0-9]+\.\w+)$\N}\
{yes}{no}}

Интерактивная защита позволяет отнести систему к IPS, т.к. система поддерживает: обнаруживает почти все известные типы сканирования: TCP connect(), SYN/half-open, Null, XMAS и многое другое; позволяет настроить свой механизм работы таким образом, что при обнаружении сканирования путем запуска произвольного скрипта может блокировать атакующего по IP, или отправлять его в т.н черные дыры; ведет логирование всех попыток установления соединения.

На данный момент программу можно скачать с сайта Source Forge и на данный момент доступна бета-версия 1.2. Скачав распаковываем архив, и изучаем файл portsentry_config.h , содержащий в себе параметры конфигурации установки.

/* Путь к конфигурационному файлу. При изменении необходимо тоже самое сделать в Makefile */
#define CONFIG_FILE “/usr/local/psionic/portsentry/portsentry.conf”
/* Путь к файлам hosts.deny для tcpwrapper. Стандартное местоположение в /etc */
#define WRAPPER_HOSTS_DENY “/etc/hosts.deny”
/* Задаем тип логов для syslogd*/
#define SYSLOG_FACILITY LOG_DAEMON
/* Задаем уровень важности логов демона для  syslogd*/
#define SYSLOG_LEVEL LOG_NOTICE
/* Максимальное количество запоминаемых для проверки повторного подключения хостов */
#define MAXSTATE 50

Изменив все по нашему желанию, проделываем стандартную процедуру:
# make && make install && make clean

После установки настраиваем систему, посредством редактирования /usr/local/etc/portsentry.conf

############################ /usr/local/etc/portsentry.conf ############################
# TCP-порты которые прослушивает PortSentry – здесь нужно указывать неиспользуемые приложениями порты.
# Проверить какие порты заняты можно примерно так:
# sockstat | grep {tcp}:{udp} | grep -v 127.0.0.1 | awk ‘{print $6}’ | sort | uniq -c
TCP_PORTS=”1,11,15,23,79,81,111,119,540,635,1080,1524,2000,5742,6667,8080,8085″
# UDP-порты для прослушивания
UDP_PORTS=”1,7,9,69,513,635,640,641,700″

# Верхний порт диапазона, если используется метод Advanced Stealth Scan Detection Options
ADVANCED_PORTS_TCP=”1024″
ADVANCED_PORTS_UDP=”1024″
# порты исключаемые из прослушивания при работе в Advanced Stealth Scan Detection
ADVANCED_EXCLUDE_TCP=”113,139″
ADVANCED_EXCLUDE_UDP=”520,138,137,67″

# Список игнорируемых хостов (сюда вносим админские станции и удаленные серверы)
IGNORE_FILE=”/usr/local/etc/portsentry.ignore”
# Список хостов, которые были внесены в блэклист
HISTORY_FILE=”/usr/local/etc/portsentry.history”
# строка по которой строится имя файла куда писать заблокированные хосты
BLOCKED_FILE=”/usr/local/etc/portsentry.blocked”

# использовать ли преоброзование IP адресов хостов в имена, или нет; лучше не использовать, т.к это лишняя нагрузка на сервер…
RESOLVE_HOST = “1″

# Какие телодвижения предпринимать при обнаружении сканирования:
# 0 = никаких действий, кроме записи в лог
# 1 = заблокировать хост и запустить внешнюю команду
# 2 = только запустить внешнюю команду
BLOCK_UDP=”1″
BLOCK_TCP=”1″

# команда на блокирование хоста. поскольку мы собираемся использовать IPFW , то и танцуем от стенки, также есть возможность прикрутить ipchains и просто сторонние программы, вплоть до rm -Rf /
KILL_ROUTE=”/sbin/ipfw add 2 deny all from $TARGET$:255.255.255.255 to any”

# Если стоит 1 – вначале запускается KILL_RUN_CMD а потом уже KILL_ROUTE, если 0- то наоборот
KILL_RUN_CMD_FIRST = “0″
# Внешняя команда выполняемая при обнаружении сканирования портов, в данном случае внешний скриптик отправляет письмо об обнаруженном сканировании
KILL_RUN_CMD=”/usr/home/script/work/scan_port_mail.sh $TARGET$ $PORT$”

# Сколько портов будет позволено отсканить прежде чем будет выполнено действие.
# 0 – реагирует после первой не угаданной цифры
# 1 – на втором
# 2 – на третьем и т.д
SCAN_TRIGGER=”0″

# Какой `баннер` вешать на порты прослушиваемые PortSentry.
PORT_BANNER=”.. WE ARE WRITING YOUR ADDRESS IN CIA LOG ..”

############################

В файле portsentry.ignore мы упоминаем  IP-адреса компьютеров, которые не должны быть блокированы при подключении к отслеживаемому порту. По умолчанию, в файле заданы два IP-адреса: 127.0.0.1 и 0.0.0.0. туда следует добавить внутреннюю сеть и свои сервера.

После этого создаем указанный в конфиге внешний скрипт для отправки почты:

# mkdir -p /usr/home/script/work/
# cd /usr/home/script/work/
# touch scan_port_mail.sh
# chmod +x scan_port_mail.sh

###################### /usr/home/script/work/scan_port_mail.sh ######################
#!/bin/sh -xv
# оповещение по почте о попытках сканирования хостов

# вводим переменные:
main_e_mail=”root@sane4ka.ru”
attak_date=”`date +%Y-%m-%d`”
attak_time=”`date +%H:%M:%S`”
local_mashine=”`uname -n`”

# достаём хост с которого сканили
hacker_IP=$1
scanned_port=$2

# определяем DNS-атакующего
hacker_DNS=`host ${hacker_IP} | awk ‘{print $5}’`

# ваяем тревожную мессагу
echo ” обнаружена попытка сканирования .
Имя машины:             ${local_mashine}
Отсканенные порты:       ${scanned_port}

Прикрепляем данные атакующего:
IP:     ${hacker_IP}
DNS:    ${hacker_DNS}

=======
Атака заблокирована.
” | mail -s port_scanned_on_${local_mashine} ${main_e_mail}

############################

В случае фаервола естественно необходимо открыть прослушиваемые порты, для более успешной рыбалки.

Portsentry возможно запускать в трех режимах для каждого протокола. Режим работы задается в командной строке при вызове демона, посредством ключика. Одновременно можно использовать только один режим работы на одном протоколе.

Classic
Работая в данном режиме Portsentry открывает порты, указанные в TCP_PORTS или UDP_PORTS и находится в состоянии ожидания соединения. При попытке подключения к перечисленному порту происходит блокирование удаленного хоста. В этом режиме  Portsentry не реагирует на Stealth-сканирование. Данный режим работы задается опциями командной строки: -tcp и -udp , для TCP и UDP-портов соответственно.

Enhanced Stealth Scan Detection
Данный режим используется для проверки перечисленных в TCP_PORTS или UDP_PORTS портов на предмет подключения или сканирования. Отличительная черта, то что палит практически все типы Stealth-сканирования, а не ограничивается только сканирование подключением. Порты, в отличие от предыдущего режима открытыми не держит, посему атакующий получает достоверную информацию об открытых портах. Задается ключиками командной строки: -stcp и -sudp , для TCP и UDP-портов соответственно.

Advanced Stealth Scan Detection
Данный режим используется для проверки всех портов входящих в пул от 1 до ADVANCED_PORT_TCP (для TCP) или ADVANCED_PORT_UDP (для UDP). Порты, открытые работающими на хосте программами и перечисленные в ADVANCED_EXLUDE_TCP(для TCP) или ADVANCED_EXCLUDE_UDP(для UDP) не проверяются. Любой хост, попытавшийся подключится к порту из этого промежутка, мгновенно блокируется. Наиболее удобный для использования метод, т.к. реакция на сканирование или попытку подключения у данного метода самая быстрая, а также в этом режиме используется гораздо меньше процессорного времени, чем в остальных. Задается ключами из коммандной строки: -atcp и -audp , TCP и UDP-портов соответственно.

Таким образом Portsentry можно запускать в следующих режимах:

/usr/local/psionic/portsentry/portsentry -tcp
Classic Mode для TCP-портов
/usr/local/psionic/portsentry/portsentry -udp
Classic Mode для UDP-портов
/usr/local/psionic/portsentry/portsentry -stcp
Enhanced Stealth Scan Detection для TCP-портов
/usr/local/psionic/portsentry/portsentry -sudp
Enhanced Stealth Scan Detection для UDP-портов
/usr/local/psionic/portsentry/portsentry -atcp
Advanced Stealth Scan Detection для TCP-портов
/usr/local/psionic/portsentry/portsentry -audp
Advanced Stealth Scan Detection для UDP-портов

Команду запуска можно добавить в rc.conf или же создать запускающий файлик

*** При установках и последующем написании how-to были использованы материалы сайтов:
Opennet.ru
Lissyara.su

Корректный способ, имеющий так же результатом полную очистку очереди сообщений:
service exim stop;
rm -rf /var/spool/exim/input.bak;
mv /var/spool/exim/input /var/spool/exim/input.bak;
mkdir /var/spool/exim/input;
chown mailnull.mail /var/spool/exim/input;
chmod 750 /var/spool/exim/input;
service exim start;

Официальный способ очистки очереди:
exim -qff

Тоже самое с включенным дебаггом процесса:
exim -qff -d9

Собственно все тоже самое можно проделать скриптом. Как условие- все исполняемые файлы должны быть прописаны полностью, и пользователь стартующий скрипт должен быть доверенным для Exim’а.
Также данный скрипт может помочь в ситуации когда после доставки сообщения Exim куда то девает телосообщения, в результате чего письмо становится гостом и в листинге очереди exim -bp объем не указывается, в результате чего exiqgrep, не понимая о чем речь, выпадает с ошибкой.
Собственно скрипт убивающий сообщения из очереди, но оговорюсь сразу- письма уходят навсегда.

#!/bin/bash

# Определяем qualify_domain — он необходим для удаления всяческого мусора
domain=`exim -bP | grep -i “^qualify_domain” | sed -e s/.*\=\ //g`

# Прощаемся со всеми замороженными сообщениями
exim -bpr | grep ‘<' | awk '{print $2}' | grep '-' | xargs exim -Mrm 2> /dev/null

# при передаче скрипту параметра c, включаем агрессивный режим
if [ "$1" == "c" ]; then

# Удаляем все баунсы старше 20 минут
exiqgrep -o 1200 -if ‘^<>$’ |xargs exim -Mrm
# Сносим все сообщения с адресами начинающихся со спец.символов, таких как нижний подчерк, минус или тире
exiqgrep -f ‘^<\_|^<\-|^<\|' -i | xargs exim -Mrm
exiqgrep -r '^\_|^\-|^\|' -i | xargs exim -Mrm
#Выкашиваем сообщения отправленные на китайские домены, за последние 20 минут
exiqgrep -f "$domain" -r '.cn$' -o 1200 -i | xargs exim -Mrm
# Удаляем любые сообщения отправленные скриптами, если они зависли в очереди более чем на 12 часов
exiqgrep -f "$domain" -o 43200 -i | xargs exim -Mrm
exit
fi

# В мягком режиме удаляем только frozen баунсы и письма с невозможными адресами в заголовках
exiqgrep -zif '^<>$’ |xargs exim -Mrm
exiqgrep -f ‘^<\_|^<\-|^<\|’ -i | xargs exim -Mrm
exiqgrep -r ‘^\_|^\-|^\|’ -i | xargs exim -Mrm

##########################################
Работа с очередью Exim.
Когда возникает необходимость удалить одно или несколько замороженных сообщений из очереди, мы прибегаем к утилите Exipick:
exipick – показывает сообщения в очереди экзима
exipick -z – показывает замороженные сообщения
exipick -i – показывает ID сообщений

exim -Mrm ID – удаляет из очереди сообщение с определенным ID

В итоге получаем:
exipick -zi | xargs exim -Mrm //очистит все замороженные сообщения из очереди
exipick -i | xargs exim -Mrm //очистит все сообщения из очереди
exipick -i | xargs exim -Mg // Очистка почтовой очереди в MTA Exim. Сервер пытается немедленно доставить все письма, находящиеся в очереди. Если какое-либо письмо не удалось доставить, оно удаляется из очереди.

autoreply:
driver = accept
require_files = /usr/home/exim/$local_part/.vacation.txt
condition = ${if or { \
{match {$h_precedence:} {(?i) junk|bulk|list}} \
{eq {$sender_address} {}} \
{match {$h_subject:} {(ADV|Adv)}} \
} {no} {yes}}
no_expn
senders = !+noautoreply_senders
transport = address_reply
unseen
no_verify

##########################################################
Раздел TRANSPORTS CONFIGURATION:

address_reply:
driver = autoreply
file = /usr/home/exim/$local_part/.vacation.txt
file_expand
once = /var/log/exim-$local_part-vacation.db
once_repeat = 1d
from = $local_part@odminblog.ru
headers_add = “Auto_Repl:$reply_address”
to = $sender_address
subject = Re: ${rfc2047:$h_subject:}

##########################################################
В разделе MAIN CONFIGURATION определяем местоположение списка исключений для автоответа

addresslist noautoreply_senders = /etc/mail/autorep.noanswer

##########################################################

И собственно определяем сам список доменов, на письма с которых не нужно отсылать автоответ:

##########################################################
#### /etc/mail/autorep.noanswer
##########################################################

^.*-request@.*
^owner-.*@.*
^.*-owner@.*
^.*-admin@.*
^bounce-.*@.*
^.*@bounce\..*
^.*-outgoing@.*
^.*-relay@.*
^.*-bounces@.*
^.*-bounce@.*
^.*-confirm@.*
^.*-errors@.*
^mailer@.*
^postmaster@.*
^mailer-daemon@.*
^mailer_daemon@.*
^majordomo@.*
^majordom@.*
^mailman@.*
^nobody@.*
^reminder@.*
^autoreply.*@.*
^.*-autoresponder@.*
^autoresponder@.*
^listserv@.*
^daemon@.*
^server@.*
^root@.*
^noreply.*@.*
^no-reply@.*
^bounce@.*
^news@.*
^request.*@.*
^httpd@.*
^lighttpd@.*
^www@.*
^www-data@.*
^nagios@.*
^sales@.*
^info@.*
^fetchmail.*@.*
^listmaster@.*
^mailmaster@.*
^webmaster@.*
^squid@.*
^support@.*
^exim@.*
scomp@aol.net

Теперь все что от нас требуется, это своевременно закинуть в домашнюю директорию пользователя файлик .vacation.txt с текстом автоответа. Кодировка по умолчанию будет utf-8

##########################################################
На EximWiki несколько иная конфигурация которая выглядит довольно убедительно, но я её не пробовал, т.ч. просто привожу.
##Router##
uservacation:
driver = accept
domains = +local_domains
condition = ${if or { \
{ match {$h_precedence:} {(?i)junk|bulk|list} } \
{ eq {$sender_address} {} } \
{ def:header_X-Cron-Env: } \
{ def:header_Auto-Submitted: } \
{ def:header_List-Id: } \
{ def:header_List-Help: } \
{ def:header_List-Unsubscribe:} \
{ def:header_List-Subscribe: } \
{ def:header_List-Owner: } \
{ def:header_List-Post: } \
{ def:header_List-Archive: } \
{ def:header_Autorespond: } \
{ def:header_X-Autoresponse: } \
{ def:header_X-Autoreply-From: } \
{ def:header_X-eBay-MailTracker: } \
{ def:header_X-MaxCode-Template: } \
{ match {$h_X-Auto-Response-Suppress: } {OOF} } \
{ match {$h_X-OS:} {HP Onboard Administrator} } \
{ match {$h_X-MimeOLE:} {\N^Produced By phpBB2$\N} } \
{ match {$h_Subject:} {\N^Yahoo! Auto Response$\N} } \
{ match {$h_Subject:} {\N^ezmlm warning$\N} } \
{ match {$h_X-FC-MachineGenerated:} {true} } \
{ match {$message_body} {\N^Your \”cron\” job on\N} } \
{ match {$h_Subject:} {\N^Out of Office\N} } \
{ match {$h_Subject:} {\N^Auto-Reply:\N} } \
{ match {$h_Subject:} {\N^Autoresponse:\N} } \
{ match {$h_Subject:} {\N(Auto Reply)$\N} } \
{ match {$h_Subject:} {\N(Out of Office)$\N} } \
{ match {$h_Subject:} {\Nis out of the office.$\N} } \
{ match {$h_X-Spam-Flag:} {\N^yes\N} } \
{ match {$h_From:} {\N(via the vacation program)\N } } \
} \
} {no} {yes} \
}
require_files = /.vacation.msg
user = ${lc:$local_part}
senders = !+noautoreply_senders
transport = vacation_transport
unseen
no_expn
no_verify
##########################################
##Transport##
vacation_transport:
driver = autoreply
log = /.vacation.log
once = /.vacation.once
once_repeat = 7d
# Errors-To: is deprecated
# There are arguments over whether this should send to the SMTP sender, or
# to a From:, Reply-To: or Resent-From: header
to = “${if def:h_Errors-To: {$h_Errors-To:} {$sender_address}}”
file = /.vacation.msg
return_message
subject = ${if def:h_subject: \
{Auto: Re: ${rfc2047:${quote:${escape:${length_60:$h_subject:}} }} }\
{Auto: I am away from my mail} \
}
user = ${lc:$local_part}

Файлы исключения для автоответа прописываются таким же образом.
##########################################################

Второй способ значительно проще, и подразумевает запущенную связку Exim + DBmail + MySQL. В этом случае мы всего лишь определяем в разделе Transport следующую строку:
address_reply:
driver = autoreply

и в конфигурационном DBMAIL dbmail.conf определяем дерективу отвечающую за использование таблицы auto_reply для автоответа.

AUTO_REPLY = yes

################################

while [ 0 -eq 0 ]; do

[ -z "`ps axu | grep имя процесса | grep имя владельца процесса | grep -v grep`" ] && команда для запуска
sleep 5
done

################################

Для закрепления пройденного материала накропим скриптик для рестарта веб-сервера под апачем:
Имя процесса – httpd
Пользователь родительского процесса – root
Команда для старта – apachectrl startssl
Соответственно:

#!/bin/sh
while [ 0 -eq 0 ]; do
[ -z "`ps axu | grep http | grep root | grep -v grep`" ] && apachectrl startssl
sleep 5
done

Для автоматизации загрузки этого процесса – прописываем его в  /etc/rc.local.

После того как обновление закончилось, следуем в папку /usr/src. Все изменения версий описаны в файле UPDATING.
Далее просто листинг команд:
1. cd /usr/obj
2. rm -rf *
Если при удаление выдало ошибки по поводу установленных флагов, то необходимо выполнить команду
chflags -R noschg *
и потом повторить удаление.
3. cd /usr/src
Вот теперь мы собственно и начнем собирать систему:
4. make buildworld
конфигурим ядро:
5. make buildkernel KERNCONF=YOUR_KERNEL_HERE (YOUR_KERNEL_HERE – название ядра которое лежит в папке /usr/src/sys/i386/conf. Но заметьте, вы путь не указываете, а указываете только имя файла. Советую переименовать файл, чтобы скомпилилось новое ядро, а не то что было до обновления системы)
инсталлируем ядро:
6. make installkernel KERNCONF=YOUR_KERNEL_HERE
7. reboot (загрузиться в single mode)
В следующем пункте будьте осторожны, здесь проверяются конфигурационные файлы и предлагается заменить файлы вашей системы файлами новой системы; оставить старые файлы; объединить. Таким макаром можно удалить всех своих пользователей, поэтому все делаем аккуратно:
8. mergemaster -p
Инсталлим новую систему:
9. make installworld
И снова правим файлы:
10. mergemaster
И последняя перезагрузка
11. reboot

Собственно все- имеем рабочую машину с обновленным ядром

Примечание:
На рабочем, а тем более удаленном сервере пункты 7 и 8 можно опустить, переходя сразу к 9. У меня за многочисленные разы никаких проблем не возникало.

Порт – это наиболее удобный способ установки приложений в среде FreeBSD, причем приложение устанавливается со всеми выпущенными на данный момент заплатками и патчами. Процесс установки начинается командой make в корневой директории порта и сводится к поиску подходящих исходниках на зеркалах, скачиванию, разархивированию, компиляции и, после задания команды make install, установки с преднастроенными параметрами, и регистрацией в каталоге /var/db/pkg/(база установленных пакетов) .

Собственно для обновления дерева портов, необходимо поставить основной порт, отвечающий за данную процедуру- cvsup.

# cd /usr/ports/net/cvsup-without-gui
# make install

После этого нам необходимо настроить конфигурационный файл cvsupfile, находящийся в каталоге /etc
######################################
*default host=cvsup.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default tag=.
*default delete use-rel-suffix

src-all
*default tag=.
ports-all
doc-all
######################################
Параметры конфига таковы:
*default host=cvsup.FreeBSD.org – адрес сервера откуда мы тащим обновления.
*default tag=RELENG_6_3 – до какой версии обновляемся
RELENG_4 – обновление до FreeBSD-4-Stable
RELENG_4_10 – обновление до FreeBSD-4-10
RELENG_5 – обновление до FreeBSD-5-Stable
RELENG_5_3 – обновление до FreeBSD-5-3
RELENG_6_3 – обновление до FreeBSD-6-3
. – обновление до Current версии (по преданиям на рабочих серверах этого лучше не делать) Если обновляются только порты, то нужно ставить точку, если же вы нацелились на make world, то необходимо указывать версию системы.
src-all – обновить исходники системы
*default tag=. – указатель до какой версии обновить порты, если указать что то вместо точки, то порты благополучно потрутся, и придется поновой обновляться чтобы получить их назад.
ports-all – указываем что хотим обновить все порты

После того как конфиг сохранили, следует запустить обновление ситемы:
# /usr/local/bin/cvsup -g -L 2 /etc/cvsupfile

после этого можно спокойно идти пить чай-кофе-пиво (нужное подчеркнуть), т.к. процесс будет идти минут 15-20 как минимум, в зависимости от канала.

Теперь чтобы поддерживать актуальную коллекцию портов (звучит очень комильфо), необходимо засунуть задачу в cron, для это в каталоге /usr/local/sbin/ создаем файло например ports_update.sh, прописываем в него указанную выше строку, и пишем в cron

35 23 * * 6            root            /usr/local/sbin/cvsup_up.sh

хотя можно засунуть файл и в /etc/periodic/weekly/
Естетсвенно в обоих случаях файлу следует дать права на исполнение.

Для работы с установленными пакетами используются команды семейства pkg_ :
просмотр версий пакетов, устаревших и актуальных
# pkg_version -v

Если необходимо обновить какой либо порт, то идем в директорию его порта, и говорим следующее:

# make clean
# make
# pkg_delete -f имя_пакета  (имя пакеты выводится при листинге pkg_version  )
# make install
# make clean

***Примечание:
При обновлении портов, можно опустить неиспользуемые порты с языковыми поддержками, путем добавления в файл /usr/sup/refuse следующих строк:

ports/arabic
ports/chinese
ports/french
ports/german
ports/hebrew
ports/hungarian
ports/japanese
ports/korean
ports/portuguese
ports/polish
ports/vietnamese

Вычисление масок происходит путем вычисления сумм основных прав доступа:

4 = Read (права на чтение)
2 = Write (права на запись)
1 = Execute (права на выполнение)

Исходя из это все комбинации цифр от 1 до 7 обозначают определенные права доступа, представленные ниже:

7 = Read, Write, Execute (Полные права)
6 = Read, Write (Права на чтение и изменение)
5 = Read, Execute (Права на чтение и запуск)
4 = Read (Права только на чтение)
3 = Write, Execute (Права на изменение и запуск)
2 = Write (Права на изменение)
1 = Execute (Права на запуск)

Ниже приведены основные команды управления доступом:

chmod
Задание или изменение прав доступа для файла или каталога

chown
Задание или изменение владельца, или группы владельцев, на файл или каталог

ls
Вывод подробной информации о файле или владельце, в том числе и права доступа (при использовании ключа -l).