Организация snmp управления на Edge-Core
все тестировалось на ES3528M и ES3510
тип коммутатора
на ES3528M/ES3552M
snmpget -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.1.5.1.0
на ES3510/ES3526XA
snmpget -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.1.5.1.0
работа с файлами ES3528M
указывает источник копирования 1 file, 2 runningCfg, 3 StartUpCfg, 4 tftp, 5 unit, 6 http, 7 ftp,
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.1.0 i [?]
имя копируемого файла
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.2.0 s [filename]
тип копируемого файла 1 opcode, 2 config, 3 bootrom, 5 loader
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.5.0 i [1-6]
указываем куда копировать ( все тоже самое как и в источнике ) -
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.3.0 i [1-6]
указываем с каким именем будет скопирован файл
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.4.0 s [filename]
указываем tftp сервер
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.6.0 a [ip]
говорим 1 некопировать, 2 копировать
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.8.0 i [12]
работа с файлами ES3510
указывает источник копирования 1 file, 2 runningCfg, 3 startUpCfg, 4 tftp, 5 unit
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.1.0 i [1-5]
имя копируемого файла
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.2.0 s [filename]
указываем куда копируем 1 file, 2 runningCfg, 3 startUpCfg, 4 tftp, 5 unit
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.3.0 i [1-5]
указываем с каким именем будет скопирован файл
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.4.0 s [filename]
тип копируемого файла 1 opcode, 2 config, 3 bootrom
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.5.0 i [1-3]
указываем tftp сервер
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.6.0 a [ip]
говорим 1 некопировать, 2 копировать
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.8.0 i [12]
Что мы должны указать для копирования running-config на tftp сервер ES3528M
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.1.0 i 2
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.3.0 i 4
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.4.0 s dev-[ip].cfp
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.6.0 a [tftp server ip]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.8.0 i 2
Что мы должны указать для копирования running-config на tftp сервер ES3510
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.1.0 i 2
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.3.0 i 4
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.4.0 s dev-[ip].cfp
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.6.0 a [tftp server ip]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.8.0 i 2
Что мы должны указать при обновлении софта ES3528M
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.1.0 i 4
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.2.0 s [firmware file name]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.3.0 i 1
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.4.0 s [firmware file name]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.5.0 i 1
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.6.0 a [tftp server ip]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.24.1.8.0 i 2
далее делаем скопированный файл стартовым
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.7.1.0 s [firmware file name]
перегружаем коммутатор, опции 1 работаем, 2 горячий ребут, 3 холодный ребут
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.7.3.0 i 3
Что мы должны указать при обновлении софта ES3510
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.1.0 i 4
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.2.0 s [firmware file name]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.3.0 i 1
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.4.0 s [firmware file name]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.5.0 i 1
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.6.0 a [tftp server ip]
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.24.1.8.0 i 2
далее делаем скопированный файл стартовым
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.7.1.0 s [firmware file name]
перегружаем коммутатор, опции 1 работаем, 2 горячий ребут, 3 холодный ребут
snmpset -v 2c -c [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.7.3.0 i 3
Просмотр текущей версии софта на ES3528M
snmpget -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.1.5.4.0
на ES3510
snmpget -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.1.5.4.0
Включение выключение порта
выключение
snmpset -v 2c -c [community] [ip] .1.3.6.1.2.1.2.2.1.7.[port] i 2
включение
snmpset -v 2c -c [community] [ip] .1.3.6.1.2.1.2.2.1.7.[port] i 1
Включение выключение ip source guard на порту ES3528M
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.48.1.1.2.[port] i [012]
где 0 выключено, 1 IP-SIP, 2 IP-MAC-SIP
Включение выключение ip source guard на порту ES3510
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.48.1.1.2.[port] i [012]
где 0 выключено, 1 IP-SIP, 2 IP-MAC-SIP
включение выключение ip dhcp snooping ES3528M
глобальное включение ( ip dhcp snooping )
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.1.1.0 i [12]
1 включено, 2 выключено
включение 1, выключение 2 проверки мак адреса ( no ip dhcp snooping verify mac-address ) -
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.1.2.0 i [12]
включение 1, выключени 2 добавления option 82 -
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.1.3.0 i [12]
отбрасывать 1, сохранять 2, заменять 3 option 82
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.1.4.0 i [123]
установка идентификатора устройства Agent ID, mac-hex 1, mac-ascii 2, ip-hex 3, ip ascii 4, string 5
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.1.6.0 i [12345]
включение dhcp snooping на вилане, 1 включено, 2 выключено
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.2.1.1.2.[vlan] i [12]
делаем указанный порт доверенным 1, не доверенным 2
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.6.10.94.1.46.3.1.1.2.[port] i [12]
включение выключение ip dhcp snooping ES3510
глобальное включение ( ip dhcp snooping )
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.1.1.0 i [12]
1 включено, 2 выключено
включение 1, выключение 2 проверки мак адреса ( no ip dhcp snooping verify mac-address ) -
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.1.2.0 i [12]
включение 1, выключени 2 добавления option 82 -
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.1.3.0 i [12]
отбрасывать 1, сохранять 2, заменять 3 option 82
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.1.4.0 i [123]
включение dhcp snooping на вилане, 1 включено, 2 выключено
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.2.1.1.2.[vlan] i [12]
делаем указанный порт доверенным 1, не доверенным 2
snmpset -v 2c -с [community] [ip] .1.3.6.1.4.1.259.8.1.5.1.46.3.1.1.2.[port] i [12]
Создание вилана на коммутаторе ES3528M и ES3510M
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.5.[vlan] i [?]
где вместо ?, 6 удалить указанный вилан, 5 создать указанный вилан
далее неоходима активация вилана
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.5.[vlan] i [12]
где 1 активировать, 2 деактивировать
укажем имя вилана
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.1.[vlan] s [name]
добавление тегированных портов
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.2.[vlan] x "f0 00 00 00"
добавление нетегированных портов
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.4.[vlan] x "f0 00 00 00"
определение нейтив вилана на порту
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.5.1.1.[port] u [vlan]
удаление вилана с портов
snmpset -v 2c -c [community] [ip] 1.3.6.1.2.1.17.7.1.4.3.1.2.[vlan] x "00 00 00 00"
Процесс понимания, чтоб не распонять :)
Похоже Hex-STRING отдаваемая с коммутатора содержит дополнительные байты данных, в целом нас интересует только
первые 7 байт для коммутаторов с 26 и 28 портами и первый три байта для 10 портовых коммутаторов.
порты определяются блоками по 4 бита в двоичном счислении с последующим преобразованием в шестнадцатеричный формат
для коммутатора с 28 портами все порты будут выглядеть как
1111 1111 1111 1111 1111 1111 1111 = FF FF FF F0
для коммутатора с 26 портами все порты будут выглядеть как
1111 1111 1111 1111 1111 1111 1100 - FF FF FF C0
для коммутатора с 10 портами все порты будут выглядеть как
1111 1111 1100 = FF C0
в каждом блоке из 4 бит последовательно указываются порты от первого в блоке до последнего
прим. портов в блоках порт 1 dec = 1000 bin, порт 2 dec = 0100 bin, 3 dec = 0010 bin, 4 dec = 0001 bin
в одном блоке указываются от 0 до 4 портов одновременно, допустимо любое значение в диапазоне от 0000 bin
до 1111 bin.
В дальшейшем двоичное значение блока преобразуется в шестнадцатеричное для передачи на устройство.
пример создание вилана на es3528m ( добавим вилан 2 на порты 11 и 18, порт 28 аплинк, назовем Test )
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.3.1.5.2 i 5
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.3.1.5.2 i 1
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.3.1.1.2 s Test
добавим указанный вилан на порт 28 тегированный
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.3.1.2.2 x "00 00 00 10"
добавляем порты 11 18 нетегированные
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.3.1.4.2 x "00 20 40 00"
определение нейтив вилана на порту
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.5.1.1.11 u 2
snmpset -v 2c -c Qorwnm12gT 10.100.10.19 1.3.6.1.2.1.17.7.1.4.5.1.1.18 u 2
---------------------
Взято с:
http://kukachik.blogspot.com/2010/08/snmp-edge-core.html#comment-form
понеділок, 18 жовтня 2010 р.
вівторок, 23 червня 2009 р.
/etc/nginx/nginx.conf
# пользователь и группа от которого запускается процесс
user www www;
# 3 рабочих процесса
worker_processes 3;
# Лог для ошибок
error_log logs/error.log;
events {
# максимум рабочих соединений
worker_connections 1024;
# Метод обработки соединений
# kqueue — эффективный метод, используемый во FreeBSD
# Подробнее http://sysoev.ru/nginx/docs/events.html
use kqueue;
}
http {
# Подключаем таблицу mime
include mime.types;
# mime-тип по умолчанию
default_type application/octet-stream;
# Формат лог файла
#log_format main '$remote_addr - $remote_user [$time_local] $request '
# '"$status" $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
# Лог доступа всего веб-сервера
#access_log logs/access.log main;
# Директива задаёт таймаут при чтении заголовка запроса клиента
client_header_timeout 3m;
# Директива задаёт таймаут при чтении тела запроса клиента
client_body_timeout 3m;
# Директива задаёт таймаут при передаче ответа клиенту
send_timeout 3m;
# Директива задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 2m;
# Директива разрешает или запрещает использовать sendfile()
sendfile on;
# Директива разрешает или запрещает использовать опции TCP_NOPUSH во FreeBSD
# Подробнее http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#keepalive_timeout
#tcp_nopush on;
# Директива задаёт размер буфера для чтения заголовка запроса клиента
#client_header_buffer_size 1k;
# Директива задаёт максимальное число и размер буферов для чтения большого заголовка запроса клиента
#large_client_header_buffers 4 4k;
# Модуль позволяет описывать группы серверов, которые могут использоваться
# в директивах proxy_pass и fastcgi_pass.
upstream backend {
# Директива задаёт имя и параметры сервера. Обратите внимание, мы будем
# использовать имя "backend" в директиве proxy_pass
server 127.0.0.1:88;
}
server {
# Слушать 80 порт
listen 80;
# Использовать следующие хосты
server_name pyha.ru www.pyha.ru;
# Кодировка
#charset koi8-r;
# Лог доступа для конкретного виртуального хоста
#access_log logs/host.access.log main;
# Максимальный размер тела запроса клиента
client_max_body_size 101M;
# Разруливаем статику и динамку, смотрите описание ниже в этой статье!
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ {
root /home/pyha/pyha.ru;
}
location ~ /\.ht {
deny all;
}
location / {
proxy_pass http://backend/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_connect_timeout 120;
proxy_send_timeout 120;
proxy_read_timeout 180;
}
# Адрес страницы 404-ой ошибки, далее все ошибки по аналогии
#error_page 404 /404.html;
# Аналогично 404, только при этом назначается псевдоним 50x.html для всех
# 50x-тых ошибок и далее перенаправляется все на "root"
error_page 500 502 503 504 /50x.html;
location = /50x.html {
# корневая директория
root /usr/local/www/nginx-dist;
}
}
}
Взято з http://adw0rd.ru/2009/nginx-and-apache-install/
user www www;
# 3 рабочих процесса
worker_processes 3;
# Лог для ошибок
error_log logs/error.log;
events {
# максимум рабочих соединений
worker_connections 1024;
# Метод обработки соединений
# kqueue — эффективный метод, используемый во FreeBSD
# Подробнее http://sysoev.ru/nginx/docs/events.html
use kqueue;
}
http {
# Подключаем таблицу mime
include mime.types;
# mime-тип по умолчанию
default_type application/octet-stream;
# Формат лог файла
#log_format main '$remote_addr - $remote_user [$time_local] $request '
# '"$status" $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
# Лог доступа всего веб-сервера
#access_log logs/access.log main;
# Директива задаёт таймаут при чтении заголовка запроса клиента
client_header_timeout 3m;
# Директива задаёт таймаут при чтении тела запроса клиента
client_body_timeout 3m;
# Директива задаёт таймаут при передаче ответа клиенту
send_timeout 3m;
# Директива задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 2m;
# Директива разрешает или запрещает использовать sendfile()
sendfile on;
# Директива разрешает или запрещает использовать опции TCP_NOPUSH во FreeBSD
# Подробнее http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#keepalive_timeout
#tcp_nopush on;
# Директива задаёт размер буфера для чтения заголовка запроса клиента
#client_header_buffer_size 1k;
# Директива задаёт максимальное число и размер буферов для чтения большого заголовка запроса клиента
#large_client_header_buffers 4 4k;
# Модуль позволяет описывать группы серверов, которые могут использоваться
# в директивах proxy_pass и fastcgi_pass.
upstream backend {
# Директива задаёт имя и параметры сервера. Обратите внимание, мы будем
# использовать имя "backend" в директиве proxy_pass
server 127.0.0.1:88;
}
server {
# Слушать 80 порт
listen 80;
# Использовать следующие хосты
server_name pyha.ru www.pyha.ru;
# Кодировка
#charset koi8-r;
# Лог доступа для конкретного виртуального хоста
#access_log logs/host.access.log main;
# Максимальный размер тела запроса клиента
client_max_body_size 101M;
# Разруливаем статику и динамку, смотрите описание ниже в этой статье!
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ {
root /home/pyha/pyha.ru;
}
location ~ /\.ht {
deny all;
}
location / {
proxy_pass http://backend/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_connect_timeout 120;
proxy_send_timeout 120;
proxy_read_timeout 180;
}
# Адрес страницы 404-ой ошибки, далее все ошибки по аналогии
#error_page 404 /404.html;
# Аналогично 404, только при этом назначается псевдоним 50x.html для всех
# 50x-тых ошибок и далее перенаправляется все на "root"
error_page 500 502 503 504 /50x.html;
location = /50x.html {
# корневая директория
root /usr/local/www/nginx-dist;
}
}
}
Взято з http://adw0rd.ru/2009/nginx-and-apache-install/
четвер, 11 червня 2009 р.
файловый редактор в mc
Почему-то в любимом mc в ubuntu 8.10 по умолчанию встал редактор nano
cd /home/.mc
sudo nano ini
Далее находим строчку
use_internal_edit=0
заменяем 0 на 1
сохраняем ctrl+x
жмём Y
и запускаем MC ^)
souece:
http://brandykov.blogspot.com/2009/02/mc.html
cd /home/.mc
sudo nano ini
Далее находим строчку
use_internal_edit=0
заменяем 0 на 1
сохраняем ctrl+x
жмём Y
и запускаем MC ^)
souece:
http://brandykov.blogspot.com/2009/02/mc.html
четвер, 4 червня 2009 р.
DNS За 15 хвилин
Сервер:
OS debian 5
ip 192.168.1.1
zone org.ua (для прикладу :) )
Насам перед потрібно встановити сам DNS сервер. В якості сервера я обрав bind, отже приступимо.
#aptitude install bind9
Дочекавшись закінчення процедури інсталяції робимо наступне.
#/etc/init.d/bind9 stop
Тепер можемо приступидо до зміни конфігураційних файлів.
#nano /etc/bind/named.conf.local
Зараз нам потрібно створити файли зон які ми вказали в named.conf.local, а саме db.org.ua та db.org.ua.rev
db.org.ua:
;
; BIND data file for broadcast zone org.ua
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.org.ua.
ns A 127.0.0.1
ns A 192.168.1.1
gw A 192.168.1.1
web A 192.168.1.2
db.org.ua.rev
;
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1 PTR ns.org.ua.
2 PTR web.org.ua.
після чого потібно внести запис про DNS сервер в /etc/resolv.conf
#nano /etc/resolv.conf
Запускаємо сервер
#/etc/init.d/bind9 start
Перевіряємо
~# dig ns.org.ua
; <<>> DiG 9.3.4-P1.1 <<>> ns.org.ua
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26392
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.org.ua. IN A
;; ANSWER SECTION:
ns.org.ua. 604800 IN A 192.168.1.1
ns.org.ua. 604800 IN A 127.0.0.1
;; AUTHORITY SECTION:
org.ua. 604800 IN NS ns.org.ua.
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 4 15:47:32 2009
;; MSG SIZE rcvd: 73
OS debian 5
ip 192.168.1.1
zone org.ua (для прикладу :) )
Насам перед потрібно встановити сам DNS сервер. В якості сервера я обрав bind, отже приступимо.
#aptitude install bind9
Дочекавшись закінчення процедури інсталяції робимо наступне.
#/etc/init.d/bind9 stop
Тепер можемо приступидо до зміни конфігураційних файлів.
#nano /etc/bind/named.conf.local
zone "org.ua" {
type master;
file "/etc/bind/db.org.ua";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.org.ua.rev";
};
Зараз нам потрібно створити файли зон які ми вказали в named.conf.local, а саме db.org.ua та db.org.ua.rev
db.org.ua:
;
; BIND data file for broadcast zone org.ua
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.org.ua.
ns A 127.0.0.1
ns A 192.168.1.1
gw A 192.168.1.1
web A 192.168.1.2
db.org.ua.rev
;
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1 PTR ns.org.ua.
2 PTR web.org.ua.
після чого потібно внести запис про DNS сервер в /etc/resolv.conf
#nano /etc/resolv.conf
search org.ua
nameserver 127.0.0.1
nameserver 192.168.1.1
Запускаємо сервер
#/etc/init.d/bind9 start
Перевіряємо
~# dig ns.org.ua
; <<>> DiG 9.3.4-P1.1 <<>> ns.org.ua
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26392
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.org.ua. IN A
;; ANSWER SECTION:
ns.org.ua. 604800 IN A 192.168.1.1
ns.org.ua. 604800 IN A 127.0.0.1
;; AUTHORITY SECTION:
org.ua. 604800 IN NS ns.org.ua.
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 4 15:47:32 2009
;; MSG SIZE rcvd: 73
/etc/network/interfaces
######################################################################
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
#
# A "#" character in the very first column makes the rest of the line
# be ignored. Blank lines are ignored. Lines may be indented freely.
# A "\" character at the very end of the line indicates the next line
# should be treated as a continuation of the current one.
#
# The "pre-up", "up", "down" and "post-down" options are valid for all
# interfaces, and may be specified multiple times. All other options
# may only be specified once.
#
# See the interfaces(5) manpage for information on what options are
# available.
######################################################################
# We always want the loopback interface.
#
# auto lo
# iface lo inet loopback
# An example ethernet card setup: (broadcast and gateway are optional)
#
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# A more complicated ethernet setup, with a less common netmask, and a downright
# weird broadcast address: (the "up" lines are executed verbatim when the
# interface is brought up, the "down" lines when it's brought down)
#
# auto eth0
# iface eth0 inet static
# address 192.168.1.42
# network 192.168.1.0
# netmask 255.255.255.128
# broadcast 192.168.1.0
# up route add -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# up route add default gw 192.168.1.200
# down route del default gw 192.168.1.200
# down route del -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# A more complicated ethernet setup with a single ethernet card with
# two interfaces.
# Note: This happens to work since ifconfig handles it that way, not because
# ifup/down handles the ':' any differently.
# Warning: There is a known bug if you do this, since the state will not
# be properly defined if you try to 'ifdown eth0' when both interfaces
# are up. The ifconfig program will not remove eth0 but it will be
# removed from the interfaces state so you will see it up until you execute:
# 'ifdown eth0:1 ; ifup eth0; ifdown eth0'
# BTW, this is "bug" #193679 (it's not really a bug, it's more of a
# limitation)
#
# auto eth0 eth0:1
# iface eth0 inet static
# address 192.168.0.100
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# iface eth0:1 inet static
# address 192.168.0.200
# network 192.168.0.0
# netmask 255.255.255.0
# "pre-up" and "post-down" commands are also available. In addition, the
# exit status of these commands are checked, and if any fail, configuration
# (or deconfiguration) is aborted. So:
#
# auto eth0
# iface eth0 inet dhcp
# pre-up [ -f /etc/network/local-network-ok ]
#
# will allow you to only have eth0 brought up when the file
# /etc/network/local-network-ok exists.
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet. If their MAC addresses get swapped (because an
# updated kernel uses a different order when probing for network cards,
# say), then they don't get brought up at all.
#
# auto eth0 eth1
# iface eth0 inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66
# pre-up /usr/local/sbin/enable-masq
# iface eth1 inet dhcp
# pre-up /path/to/check-mac-address.sh eth1 AA:BB:CC:DD:EE:FF
# pre-up /usr/local/sbin/firewall
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet, identified by MAC address rather than interface
# name:
#
# auto eth0 eth1
# mapping eth0 eth1
# script /path/to/get-mac-address.sh
# map 11:22:33:44:55:66 lan
# map AA:BB:CC:DD:EE:FF internet
# iface lan inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /usr/local/sbin/enable-masq $IFACE
# iface internet inet dhcp
# pre-up /usr/local/sbin/firewall $IFACE
# A PCMCIA interface for a laptop that is used in different locations:
# (note the lack of an "auto" line for any of these)
#
# mapping eth0
# script /path/to/pcmcia-compat.sh
# map home,*,*,* home
# map work,*,*,00:11:22:33:44:55 work-wireless
# map work,*,*,01:12:23:34:45:50 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note, this won't work unless you specifically change the file
# /etc/pcmcia/network to look more like:
#
# if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi
# get_info $DEVICE
# case "$ACTION" in
# 'start')
# /sbin/ifup $DEVICE
# ;;
# 'stop')
# /sbin/ifdown $DEVICE
# ;;
# esac
# exit 0
# An alternate way of doing the same thing: (in this case identifying
# where the laptop is is done by configuring the interface as various
# options, and seeing if a computer that is known to be on each particular
# network will respond to pings. The various numbers here need to be chosen
# with a great deal of care.)
#
# mapping eth0
# script /path/to/ping-places.sh
# map 192.168.42.254/24 192.168.42.1 home
# map 10.15.43.254/24 10.15.43.1 work-wireless
# map 10.15.43.23/24 10.15.43.1 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note that the ping-places script requires the iproute package installed,
# and the same changes to /etc/pcmcia/network are required for this as for
# the previous example.
# Set up an interface to read all the traffic on the network. This
# configuration can be useful to setup Network Intrusion Detection
# sensors in 'stealth'-type configuration. This prevents the NIDS
# system to be a direct target in a hostile network since they have
# no IP address on the network. Notice, however, that there have been
# known bugs over time in sensors part of NIDS (for example see
# DSA-297 related to Snort) and remote buffer overflows might even be
# triggered by network packet processing.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up ip link set $IFACE promisc on
# down ip link set $IFACE promisc off
# down ifconfig $IFACE down
# Set up an interface which will not be allocated an IP address by
# ifupdown but will be configured through external programs. This
# can be useful to setup interfaces configured through other programs,
# like, for example, PPPOE scripts.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up /usr/local/bin/myconfigscript
# down ifconfig $IFACE down
Джерело: http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
#
# A "#" character in the very first column makes the rest of the line
# be ignored. Blank lines are ignored. Lines may be indented freely.
# A "\" character at the very end of the line indicates the next line
# should be treated as a continuation of the current one.
#
# The "pre-up", "up", "down" and "post-down" options are valid for all
# interfaces, and may be specified multiple times. All other options
# may only be specified once.
#
# See the interfaces(5) manpage for information on what options are
# available.
######################################################################
# We always want the loopback interface.
#
# auto lo
# iface lo inet loopback
# An example ethernet card setup: (broadcast and gateway are optional)
#
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# A more complicated ethernet setup, with a less common netmask, and a downright
# weird broadcast address: (the "up" lines are executed verbatim when the
# interface is brought up, the "down" lines when it's brought down)
#
# auto eth0
# iface eth0 inet static
# address 192.168.1.42
# network 192.168.1.0
# netmask 255.255.255.128
# broadcast 192.168.1.0
# up route add -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# up route add default gw 192.168.1.200
# down route del default gw 192.168.1.200
# down route del -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
# A more complicated ethernet setup with a single ethernet card with
# two interfaces.
# Note: This happens to work since ifconfig handles it that way, not because
# ifup/down handles the ':' any differently.
# Warning: There is a known bug if you do this, since the state will not
# be properly defined if you try to 'ifdown eth0' when both interfaces
# are up. The ifconfig program will not remove eth0 but it will be
# removed from the interfaces state so you will see it up until you execute:
# 'ifdown eth0:1 ; ifup eth0; ifdown eth0'
# BTW, this is "bug" #193679 (it's not really a bug, it's more of a
# limitation)
#
# auto eth0 eth0:1
# iface eth0 inet static
# address 192.168.0.100
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
# iface eth0:1 inet static
# address 192.168.0.200
# network 192.168.0.0
# netmask 255.255.255.0
# "pre-up" and "post-down" commands are also available. In addition, the
# exit status of these commands are checked, and if any fail, configuration
# (or deconfiguration) is aborted. So:
#
# auto eth0
# iface eth0 inet dhcp
# pre-up [ -f /etc/network/local-network-ok ]
#
# will allow you to only have eth0 brought up when the file
# /etc/network/local-network-ok exists.
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet. If their MAC addresses get swapped (because an
# updated kernel uses a different order when probing for network cards,
# say), then they don't get brought up at all.
#
# auto eth0 eth1
# iface eth0 inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66
# pre-up /usr/local/sbin/enable-masq
# iface eth1 inet dhcp
# pre-up /path/to/check-mac-address.sh eth1 AA:BB:CC:DD:EE:FF
# pre-up /usr/local/sbin/firewall
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet, identified by MAC address rather than interface
# name:
#
# auto eth0 eth1
# mapping eth0 eth1
# script /path/to/get-mac-address.sh
# map 11:22:33:44:55:66 lan
# map AA:BB:CC:DD:EE:FF internet
# iface lan inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /usr/local/sbin/enable-masq $IFACE
# iface internet inet dhcp
# pre-up /usr/local/sbin/firewall $IFACE
# A PCMCIA interface for a laptop that is used in different locations:
# (note the lack of an "auto" line for any of these)
#
# mapping eth0
# script /path/to/pcmcia-compat.sh
# map home,*,*,* home
# map work,*,*,00:11:22:33:44:55 work-wireless
# map work,*,*,01:12:23:34:45:50 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note, this won't work unless you specifically change the file
# /etc/pcmcia/network to look more like:
#
# if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi
# get_info $DEVICE
# case "$ACTION" in
# 'start')
# /sbin/ifup $DEVICE
# ;;
# 'stop')
# /sbin/ifdown $DEVICE
# ;;
# esac
# exit 0
# An alternate way of doing the same thing: (in this case identifying
# where the laptop is is done by configuring the interface as various
# options, and seeing if a computer that is known to be on each particular
# network will respond to pings. The various numbers here need to be chosen
# with a great deal of care.)
#
# mapping eth0
# script /path/to/ping-places.sh
# map 192.168.42.254/24 192.168.42.1 home
# map 10.15.43.254/24 10.15.43.1 work-wireless
# map 10.15.43.23/24 10.15.43.1 work-static
#
# iface home inet dhcp
# iface work-wireless bootp
# iface work-static static
# address 10.15.43.23
# netmask 255.255.255.0
# gateway 10.15.43.1
#
# Note that the ping-places script requires the iproute package installed,
# and the same changes to /etc/pcmcia/network are required for this as for
# the previous example.
# Set up an interface to read all the traffic on the network. This
# configuration can be useful to setup Network Intrusion Detection
# sensors in 'stealth'-type configuration. This prevents the NIDS
# system to be a direct target in a hostile network since they have
# no IP address on the network. Notice, however, that there have been
# known bugs over time in sensors part of NIDS (for example see
# DSA-297 related to Snort) and remote buffer overflows might even be
# triggered by network packet processing.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up ip link set $IFACE promisc on
# down ip link set $IFACE promisc off
# down ifconfig $IFACE down
# Set up an interface which will not be allocated an IP address by
# ifupdown but will be configured through external programs. This
# can be useful to setup interfaces configured through other programs,
# like, for example, PPPOE scripts.
#
# auto eth0
# iface eth0 inet manual
# up ifconfig $IFACE 0.0.0.0 up
# up /usr/local/bin/myconfigscript
# down ifconfig $IFACE down
Джерело: http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/
субота, 2 травня 2009 р.
Мониторинг сети с помощью tcpdump
Довольно часто встает проблема, когда ему нужно узнать как работает сеть. Или просто для учебных-исследовательских целей узнать как взаимодействуют между собой объекты сети. Для этих целей в UNIX-мире написано целая куча инструментов. В данном материале будет рассматриваться один из них: tcpdump.
Итак, tcpdump.
$ man tcpdump, нам гласит
Tcpdump выводит заголовки пакетов проходящих через сетевой интерфейс, которые совпадают с булевым выражением. Он может также быть запущен с ключем -w, который заставляет сохранять данные пактов в файл для дальнейшего исследования, и/или с ключем -r, который заставляет читать сохраненные пакеты из файла, вместо чтения пакетов из сетевого интерфейса. В любом случае, tcpdump будут обработаны только те пакеты, которые совпадают с выражением.
Tcpdump будет, если не запущен с ключем -c, продолжать собирать пакеты до тех пор, пока не будет прерван сигналом SIGINT (генерируемым, для примера, вводом Вашего символа прерывания, обычно CTRL+C) или сигналом SIGTERM (обычно генерируемого командой kill). Если запуск был с ключем -c, то сбор пакетов будет продолжаться до тех пор, пока не произойдет прерывание сигналом SIGINT или SIGTERM или пока не будет обработано определенное количество пакетов.
Когда tcpdump закончит сбор пакетов, то будет сообщено об количестве:
пакетов "полученных фильтром" (received by filter) (значение зависит от той ОС, на какой Вы запускаете tcpdump, и, возможно, от способа, котрым ОС была сконфигурирована - если фильтр был определен в командной строке, на некоторых ОС будут сосчитаны пакеты независимо от фильтрующего выражения, а в других ОС будут сосчитаны только те пакеты, которые попадают под фильтрующее и выражение, и были обработаны tcpdump);
пакетов "отброшенных ядром" (dropped by kernel) (это число пакетов, которые были отброшены, в зависимости от механизма сбора пакетов (недостаточного объема буферов) на той ОС, где запускается tcpdump, ОС предоставит эту инофрмацию приложению или нет, и тогда будет выведено число 0)
Это был перевод - исправления приветствуются.
Дальше идет описание ключей. Вот некоторые из них:
-c count Выйти после получения определенного количества пакетов.
-C file_size Перед записью "сырого" пакета в файл, происходит проверка на превышение размером файла лимита, указанного в file_size. Если размер файла больше, то файл закрывается и открывается новый. Новый файл будет иметь имя определенное в ключе -w, со стоящим в конце числом 2, которое будет увеличиваться в следующих именах файлов. file_size определяет размер в миллионах байт (1,000,000), а не мегабайтах (1,048,576).
-F file Использовать file для ввода фильтрующего выражения. Выражение, указанное в командной строке, будет игнорироваться.
-i interface Собирать пакеты только на определенном интерфейсе. Если не указан - берется минимальный по номеру интерфейс (исключая loopback). Для Linux-ядер 2.2 и более новых, возможно указать 'any', тогда будет происходить сбор на всех интерфейсах, но они не будут переведены в режим promiscuous.
-n Не преобразовывать адрес хоста в имя. Может быть использовано, если необходимо избегать DNS-запросов.
-nn Не преобразовывать протокол и номер порта в их имена.
-N Не выводить доменную часть имени хоста. Например, при данном ключе будет выводится "nic" вместо "nic.ddn.mil"
-p Не переводить интерфейс в режим promiscuous. Следует заметить, что интерфейс может быть в режиме promiscuous по другим причинам.
-r file Читать пакеты из file (который, был создан с ключем -w). Если file указан как "-", то используется стандартный ввод.
-t Не выводить временной штамп (timestamp) в каждой строке дампа (dump).
-tt Выводит не форматированный временной штамп в каждой строке дампа.
-ttt Выводить разницу (в микросекундах) между текущей и предыдущей строками дампа.
-tttt Выводить временной штамп вместе с датой в формате по-умолчанию в каждой строке дампа.
-v (Чуть более) подробный вывод. Для еще более подробного вывода используются: -vv и -vvv.
-w file Писать "сырые" пакеты в file перед тем как произвести их разбор и вывести. Они могут быть позднее выведены с ключем -r. Если file указан как "-", то используется стандартный вывод.
-x Печатать каждый пакет (без заголовков уровня соединения) в шестнадцатиричном виде.
-X Помимо шестнадцатиричного вида выводить их ASCII-значения.
Теперь, рассмотрим фильтрующее выражение.
Оно выбирает какие пакеты будут выбираться из общего потока. Если оно не указано, то будут выбираться и выводится все пакеты идущие через интерфейс. Иначе, будут обработаны только те пакеты, для которых проверка с выражением выдаст значение "истина" (true).
Выражение состоит из одного или более примитивов. Примитивы обычно состоят из ID (имя или номер) следующего за одним или более классификаторами. Различают три вида классификаторов:
type Говорят к какому виду относить ID. Возможный значения host, net или port. Пример: 'host foo', 'net 128.3', 'port 20'. Если классификатор type не указан, то подразумевается host.
dir Определяет конкретное направление передачи "к" и/или "от" ID. Возможны значения src, dst, src or dst and src and dst. Пример, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'. Если не указан, то подразумевается src or dst. Для соединений нулевого ('null') уровня (к примеру, протокол точка-точка, такой как slip) указанием направления могут быть классификаторы inbound и outbound.
proto Ограничивает совпадение конкретным протоколом. Возможные протоколы: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp и udp. Пример, 'ether src foo', 'arp net 128.3', 'tcp port 21'. Если классификатор proto не указан, то подразумеваются все перечисленные типы протоколов. Например, 'src foo означает '(ip or arp or rarp) src foo', 'net bar' означает '(ip or arp or rarp) net bar', а 'port 53' означает '(tcp or udp) port 53'.
В добавок, существует несколько специальных примитивов - ключевых слов: gateway, broadcast, less, greater и арифметические выражения.
Более сложные фильтрующие выражения могут быть построены с помощью слов and, or и not, объединяющих примитивы. Пример, 'host foo and not port ftp and not port ftp-data'. Чтобы уменьшить количество вводимой информации, идентичные списки классификаторов могут быть опущены. Пример, 'tcp dst port ftp or ftp-data or domain' это тоже самое, что и 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'
Перечислим некоторые из допустимых примитивов (за более полным списком в man tcpdump):
dst host host
Истина, если поле "назначение" пакета -это host, который может быть адресом или именем
src host host
Истина, если поле "источник" пакета - это host.
host host
Истина, если или поле "назначение", или поле "источник" пакета - это host. Любое из описанный выше выражений может быть приписано к ключевому слову ip, arp, rarp, или ip6, как в 'ip host host', что эквивалентно 'ether proto \ip and host host'. Если host - это имя с несколькими IP адресам, то проверяется совпадение по каждому адресу.
net net mask netmask
Истина, если IP адрес входит в сеть с указанной сетевой маской. Может быть классифицировано с dst или src.
net net/len
Истина, если IP адрес входит в сеть с указанной сетевой маской, заданной количеством бит. Может быть классифицировано с dst или src.
dst port port
Истина, если пакет протоколов ip/tcp, ip/udp, ip6/tcp или ip6/udp, и порт-назначения имеет значение указанное в port. Порт может быть числом или именем, используемым в /etc/services. Если используется число или неоднозначное имя, то проверяется только номер порта (пример, 'dst port 513' будет выводить трафик и для tcp/login и для udp/who, а 'port domain' будет выводить трафик и для tcp/domain и для udp/domain).
src port port
Истина, если пакет имеет порт-источник - port
port port
Истина, если или порт-назначение, или порт-источник в пакете - port. Любое из описанных выше выражений может быть приписано к ключевому слову tcp или udp, как в 'tcp src port port', проверяющее совпадения только для TCP-пакетов.
less length
Истина, если пакет имеет длину меньше или равную length. Это эквивалентно len <= length.
greater length
Истина, если пакет имеет длину больше или равную length. Это эквивалентно len >= length.
ip proto protocol
Истина, если пакет - это IP-пакет протокола, указанного в protocol. Протокол может быть числом или одним из имен icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, или tcp. Заметим, что идентификаторы tcp, udp и icmp - ключевые слова и должны быть "заэкскейпены" через обратный слэш (\).
Прежде чем переходит к примерам рассмотрим, что может нам выдать tcpdump при выполнении.
Типичные результаты работы tcpdump -ttt:
1. 000107 192.168.2.13 > 192.168.2.254: icmp: 192.168.2.13 udp port 3631 unreachable
2. 000313 192.168.2.254.53 > 192.168.2.13.3656: 4 ServFail 0/0/0 (22) (DF)
3. 000287 192.168.2.254 > 192.168.2.100: icmp: net 205.188.179.233 unreachable [tos 0xc0]
4. 010956 192.168.2.254.139 > 192.168.2.13.3661: P 1:5(4) ack 73 win 5840 NBT Packet (DF)
5. 276274 192.168.2.150.3053 > 192.168.2.254.53: 7+ A? Tatyana.karavay-shops.ru. (42)
6. 001162 192.168.2.100.32772 > 192.168.2.254.16007: . ack 73 win 5840 (DF)
Первое поле - поле времени, т. к. запуск осуществлялся с ключом "-ttt", то это разница в микросекундах между этим пакетом и предыдущим.
Потом идет IP-адрес (или имя) отправителя пакета, через точку может указываться порт. После знака ">", указывается получатель пакета (или его имя) и также порт. Затем будет идти либо сразу служебная информация идущая в пакете, либо протокол (у нас это icmp). В служебной информации может быть указано либо состояние флагов в пакете, либо расшифрованная информация ("192.168.2.13 udp port 3631 unreachable" или DNS-запрос об хосте "Tatyana.karavay-shops.ru").
Ну а теперь пора взяться за конкретные примеры.
1. Ловим весь входящий трафик из локальной сети на сервер. Здесь все просто.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt dst host 192.168.2.254
Если вы запускаете его в SSH сессии, то подготовьтесь - польется очень много и очень быстро...
2. Ловим весь входящий трафик, исключая трафик генерируемый нашей SSH-сессией.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'dst host 192.168.2.254 and not ( src host 192.168.2.100 and dst port 22 )'
Вот теперь в потоке пакетов можно разобраться.
3. Нужна информация об DNS-общении между сервером и каким-нибудь узлом сети.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and ip proto \udp'
Здесь, кстати будет бегать не только DNS-трафик. А вообще весь, который идет по UDP. Исправить это можно следующим:
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and port 53'
4. Отлавливаем исключительно icmp пакеты.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'ip proto \icmp'
Вот. Теперь все.
Не забывайте, что более подробную информацию можно получить из man tcpdump. Там же можно прочитать об структуре пакетов основных протоколов, что позволит еще глубже исследовать Ваши сети.
Итак, tcpdump.
$ man tcpdump, нам гласит
Tcpdump выводит заголовки пакетов проходящих через сетевой интерфейс, которые совпадают с булевым выражением. Он может также быть запущен с ключем -w, который заставляет сохранять данные пактов в файл для дальнейшего исследования, и/или с ключем -r, который заставляет читать сохраненные пакеты из файла, вместо чтения пакетов из сетевого интерфейса. В любом случае, tcpdump будут обработаны только те пакеты, которые совпадают с выражением.
Tcpdump будет, если не запущен с ключем -c, продолжать собирать пакеты до тех пор, пока не будет прерван сигналом SIGINT (генерируемым, для примера, вводом Вашего символа прерывания, обычно CTRL+C) или сигналом SIGTERM (обычно генерируемого командой kill). Если запуск был с ключем -c, то сбор пакетов будет продолжаться до тех пор, пока не произойдет прерывание сигналом SIGINT или SIGTERM или пока не будет обработано определенное количество пакетов.
Когда tcpdump закончит сбор пакетов, то будет сообщено об количестве:
пакетов "полученных фильтром" (received by filter) (значение зависит от той ОС, на какой Вы запускаете tcpdump, и, возможно, от способа, котрым ОС была сконфигурирована - если фильтр был определен в командной строке, на некоторых ОС будут сосчитаны пакеты независимо от фильтрующего выражения, а в других ОС будут сосчитаны только те пакеты, которые попадают под фильтрующее и выражение, и были обработаны tcpdump);
пакетов "отброшенных ядром" (dropped by kernel) (это число пакетов, которые были отброшены, в зависимости от механизма сбора пакетов (недостаточного объема буферов) на той ОС, где запускается tcpdump, ОС предоставит эту инофрмацию приложению или нет, и тогда будет выведено число 0)
Это был перевод - исправления приветствуются.
Дальше идет описание ключей. Вот некоторые из них:
-c count Выйти после получения определенного количества пакетов.
-C file_size Перед записью "сырого" пакета в файл, происходит проверка на превышение размером файла лимита, указанного в file_size. Если размер файла больше, то файл закрывается и открывается новый. Новый файл будет иметь имя определенное в ключе -w, со стоящим в конце числом 2, которое будет увеличиваться в следующих именах файлов. file_size определяет размер в миллионах байт (1,000,000), а не мегабайтах (1,048,576).
-F file Использовать file для ввода фильтрующего выражения. Выражение, указанное в командной строке, будет игнорироваться.
-i interface Собирать пакеты только на определенном интерфейсе. Если не указан - берется минимальный по номеру интерфейс (исключая loopback). Для Linux-ядер 2.2 и более новых, возможно указать 'any', тогда будет происходить сбор на всех интерфейсах, но они не будут переведены в режим promiscuous.
-n Не преобразовывать адрес хоста в имя. Может быть использовано, если необходимо избегать DNS-запросов.
-nn Не преобразовывать протокол и номер порта в их имена.
-N Не выводить доменную часть имени хоста. Например, при данном ключе будет выводится "nic" вместо "nic.ddn.mil"
-p Не переводить интерфейс в режим promiscuous. Следует заметить, что интерфейс может быть в режиме promiscuous по другим причинам.
-r file Читать пакеты из file (который, был создан с ключем -w). Если file указан как "-", то используется стандартный ввод.
-t Не выводить временной штамп (timestamp) в каждой строке дампа (dump).
-tt Выводит не форматированный временной штамп в каждой строке дампа.
-ttt Выводить разницу (в микросекундах) между текущей и предыдущей строками дампа.
-tttt Выводить временной штамп вместе с датой в формате по-умолчанию в каждой строке дампа.
-v (Чуть более) подробный вывод. Для еще более подробного вывода используются: -vv и -vvv.
-w file Писать "сырые" пакеты в file перед тем как произвести их разбор и вывести. Они могут быть позднее выведены с ключем -r. Если file указан как "-", то используется стандартный вывод.
-x Печатать каждый пакет (без заголовков уровня соединения) в шестнадцатиричном виде.
-X Помимо шестнадцатиричного вида выводить их ASCII-значения.
Теперь, рассмотрим фильтрующее выражение.
Оно выбирает какие пакеты будут выбираться из общего потока. Если оно не указано, то будут выбираться и выводится все пакеты идущие через интерфейс. Иначе, будут обработаны только те пакеты, для которых проверка с выражением выдаст значение "истина" (true).
Выражение состоит из одного или более примитивов. Примитивы обычно состоят из ID (имя или номер) следующего за одним или более классификаторами. Различают три вида классификаторов:
type Говорят к какому виду относить ID. Возможный значения host, net или port. Пример: 'host foo', 'net 128.3', 'port 20'. Если классификатор type не указан, то подразумевается host.
dir Определяет конкретное направление передачи "к" и/или "от" ID. Возможны значения src, dst, src or dst and src and dst. Пример, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'. Если не указан, то подразумевается src or dst. Для соединений нулевого ('null') уровня (к примеру, протокол точка-точка, такой как slip) указанием направления могут быть классификаторы inbound и outbound.
proto Ограничивает совпадение конкретным протоколом. Возможные протоколы: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp и udp. Пример, 'ether src foo', 'arp net 128.3', 'tcp port 21'. Если классификатор proto не указан, то подразумеваются все перечисленные типы протоколов. Например, 'src foo означает '(ip or arp or rarp) src foo', 'net bar' означает '(ip or arp or rarp) net bar', а 'port 53' означает '(tcp or udp) port 53'.
В добавок, существует несколько специальных примитивов - ключевых слов: gateway, broadcast, less, greater и арифметические выражения.
Более сложные фильтрующие выражения могут быть построены с помощью слов and, or и not, объединяющих примитивы. Пример, 'host foo and not port ftp and not port ftp-data'. Чтобы уменьшить количество вводимой информации, идентичные списки классификаторов могут быть опущены. Пример, 'tcp dst port ftp or ftp-data or domain' это тоже самое, что и 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'
Перечислим некоторые из допустимых примитивов (за более полным списком в man tcpdump):
dst host host
Истина, если поле "назначение" пакета -это host, который может быть адресом или именем
src host host
Истина, если поле "источник" пакета - это host.
host host
Истина, если или поле "назначение", или поле "источник" пакета - это host. Любое из описанный выше выражений может быть приписано к ключевому слову ip, arp, rarp, или ip6, как в 'ip host host', что эквивалентно 'ether proto \ip and host host'. Если host - это имя с несколькими IP адресам, то проверяется совпадение по каждому адресу.
net net mask netmask
Истина, если IP адрес входит в сеть с указанной сетевой маской. Может быть классифицировано с dst или src.
net net/len
Истина, если IP адрес входит в сеть с указанной сетевой маской, заданной количеством бит. Может быть классифицировано с dst или src.
dst port port
Истина, если пакет протоколов ip/tcp, ip/udp, ip6/tcp или ip6/udp, и порт-назначения имеет значение указанное в port. Порт может быть числом или именем, используемым в /etc/services. Если используется число или неоднозначное имя, то проверяется только номер порта (пример, 'dst port 513' будет выводить трафик и для tcp/login и для udp/who, а 'port domain' будет выводить трафик и для tcp/domain и для udp/domain).
src port port
Истина, если пакет имеет порт-источник - port
port port
Истина, если или порт-назначение, или порт-источник в пакете - port. Любое из описанных выше выражений может быть приписано к ключевому слову tcp или udp, как в 'tcp src port port', проверяющее совпадения только для TCP-пакетов.
less length
Истина, если пакет имеет длину меньше или равную length. Это эквивалентно len <= length.
greater length
Истина, если пакет имеет длину больше или равную length. Это эквивалентно len >= length.
ip proto protocol
Истина, если пакет - это IP-пакет протокола, указанного в protocol. Протокол может быть числом или одним из имен icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, или tcp. Заметим, что идентификаторы tcp, udp и icmp - ключевые слова и должны быть "заэкскейпены" через обратный слэш (\).
Прежде чем переходит к примерам рассмотрим, что может нам выдать tcpdump при выполнении.
Типичные результаты работы tcpdump -ttt:
1. 000107 192.168.2.13 > 192.168.2.254: icmp: 192.168.2.13 udp port 3631 unreachable
2. 000313 192.168.2.254.53 > 192.168.2.13.3656: 4 ServFail 0/0/0 (22) (DF)
3. 000287 192.168.2.254 > 192.168.2.100: icmp: net 205.188.179.233 unreachable [tos 0xc0]
4. 010956 192.168.2.254.139 > 192.168.2.13.3661: P 1:5(4) ack 73 win 5840 NBT Packet (DF)
5. 276274 192.168.2.150.3053 > 192.168.2.254.53: 7+ A? Tatyana.karavay-shops.ru. (42)
6. 001162 192.168.2.100.32772 > 192.168.2.254.16007: . ack 73 win 5840 (DF)
Первое поле - поле времени, т. к. запуск осуществлялся с ключом "-ttt", то это разница в микросекундах между этим пакетом и предыдущим.
Потом идет IP-адрес (или имя) отправителя пакета, через точку может указываться порт. После знака ">", указывается получатель пакета (или его имя) и также порт. Затем будет идти либо сразу служебная информация идущая в пакете, либо протокол (у нас это icmp). В служебной информации может быть указано либо состояние флагов в пакете, либо расшифрованная информация ("192.168.2.13 udp port 3631 unreachable" или DNS-запрос об хосте "Tatyana.karavay-shops.ru").
Ну а теперь пора взяться за конкретные примеры.
1. Ловим весь входящий трафик из локальной сети на сервер. Здесь все просто.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt dst host 192.168.2.254
Если вы запускаете его в SSH сессии, то подготовьтесь - польется очень много и очень быстро...
2. Ловим весь входящий трафик, исключая трафик генерируемый нашей SSH-сессией.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'dst host 192.168.2.254 and not ( src host 192.168.2.100 and dst port 22 )'
Вот теперь в потоке пакетов можно разобраться.
3. Нужна информация об DNS-общении между сервером и каким-нибудь узлом сети.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and ip proto \udp'
Здесь, кстати будет бегать не только DNS-трафик. А вообще весь, который идет по UDP. Исправить это можно следующим:
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'host 192.168.2.13 and port 53'
4. Отлавливаем исключительно icmp пакеты.
# /usr/sbin/tcpdump -i eth0 -n -nn -ttt 'ip proto \icmp'
Вот. Теперь все.
Не забывайте, что более подробную информацию можно получить из man tcpdump. Там же можно прочитать об структуре пакетов основных протоколов, что позволит еще глубже исследовать Ваши сети.
вівторок, 3 березня 2009 р.
Мониторинг нагрузки Apache 2
Рассмотрим ситуацию: у вас на сервере хостится несколько сайтов работающих через mod_php под Apache 2.x. Вы обнаруживаете, что сервер начинает тормозить. Запускаете top и видите, что верхние строчки занимает процесс apache2 (или httpd). Ваша задача — узнать какой из сайтов и какими запросами грузит сервер.
Первый шаг — разрешить загрузку модуля mod_status и сконфигурировать его в /etc/apache2/mods-available/status.conf или в /etc/apache2/apache2.conf (я буду писать пути и команды применительно к Debian):
ExtendedStatus On
SetHandler server-status
Можно опционально ограничить доступ к URL /server-status по IP-адресу или даже поставить пароль.
Добавляем к любому сайту на сервере путь /server-status и смотрим, что там показывается. Если видим много запросов к какому либо сайту в состоянии «W», то можно предположить, что проблема с этим сайтом. Но это будет лишь гипотеза, так как узнать точно ситуацию по нагрузке, используя данный отчет, невозможно.
Используем хитрый ход. Установим модуль mod_perl:
apt-get install libapache2-mod-perl2 apache2-prefork-dev
Пакет apache2-prefork-dev нужен для последующей установки перловых модулей. Далее запустим cpan и установим пару модулей:
cpan> install Sys::Proctitle
cpan> install Apache2::ShowStatus
В файл /etc/apache2/mods-available/perl.conf добавим следующие строчки:
PerlModule Apache2::ShowStatus
PerlInitHandler Apache2::ShowStatus
Проставим линк на этот файл и перезагрузим Apache:
ln -s /etc/apache2/mods-available/perl.conf /etc/apache2/mods-enabled/
apache2 -t
invoke-rc.d apache2 restart
Смотрим что из этого получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | egrep '^USER|httpd' | grep -v grep
USER PID %CPU COMMAND
www-data 14039 0.6 httpd: GET /notices_item/????? HTTP/1.0
www-data 14073 0.5 httpd: GET /notice/???????.html HTTP/1.0
www-data 14069 0.5 httpd: GET /r_9/ HTTP/1.0
www-data 14075 0.5 httpd: GET /notice/???????.html HTTP/1.0
Я заменил часть URL-ов вопросиками из соображений конфиденциальности.
Ну что же, это неплохо, теперь мы видим отсортированные по полю %CPU процессы Apache, а так же видим, какой запрос они выполняют в данный момент. Но мы не видим к какому сайту относятся эти запросы. Придеться немного подпатчить модуль Apache2::ShowStatus в файле /usr/local/share/perl/5.8.8/Apache2/ShowStatus.pm:
--- ShowStatus.pm.orig 2009-01-22 14:19:26.122058102 +0300
+++ ShowStatus.pm 2009-01-22 14:21:01.030847967 +0300
@@ -16,7 +16,7 @@
my $r=shift;
$r->pnotes( 'ProctitleObject'=>
- Sys::Proctitle->new( 'httpd: '.$r->the_request ) );
+ Sys::Proctitle->new( 'httpd: ['.$r->get_server_name().'] '.$r->the_request ) );
return Apache2::Const::DECLINED;
}
Перезагружаем Apache:
invoke-rc.d apache2 restart
Смотрим, что получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | grep httpd | grep -v grep
www-data 16927 3.3 httpd: [www.????????.ru] GET /img_code.html HTTP/1.0
www-data 16885 3.2 httpd: [76.?????????.ru] GET /notices_item/???????/user_register/ HTTP/1.0
www-data 16921 1.0 httpd: [www.??????.ru] GET /products_item/?????? HTTP/1.0
www-data 16933 0.5 httpd: [www.????????.ru] GET /notice/????????.html HTTP/1.0
www-data 16878 0.5 httpd: [??????????.ru] GET /main_???????? HTTP/1.0
www-data 16930 0.2 httpd: [www.??????????.ru] GET /notice/??????????.html?sd=?????????????????????????????? HTTP/1.0
Ну вот, теперь мы видим и сайт, к которому пришел запрос, и сам запрос.
Кто еще какие способы использует для мониторинга нагрузки на хостинге в окружении Apache2 + mod_php5?
Первый шаг — разрешить загрузку модуля mod_status и сконфигурировать его в /etc/apache2/mods-available/status.conf или в /etc/apache2/apache2.conf (я буду писать пути и команды применительно к Debian):
ExtendedStatus On
SetHandler server-status
Можно опционально ограничить доступ к URL /server-status по IP-адресу или даже поставить пароль.
Добавляем к любому сайту на сервере путь /server-status и смотрим, что там показывается. Если видим много запросов к какому либо сайту в состоянии «W», то можно предположить, что проблема с этим сайтом. Но это будет лишь гипотеза, так как узнать точно ситуацию по нагрузке, используя данный отчет, невозможно.
Используем хитрый ход. Установим модуль mod_perl:
apt-get install libapache2-mod-perl2 apache2-prefork-dev
Пакет apache2-prefork-dev нужен для последующей установки перловых модулей. Далее запустим cpan и установим пару модулей:
cpan> install Sys::Proctitle
cpan> install Apache2::ShowStatus
В файл /etc/apache2/mods-available/perl.conf добавим следующие строчки:
PerlModule Apache2::ShowStatus
PerlInitHandler Apache2::ShowStatus
Проставим линк на этот файл и перезагрузим Apache:
ln -s /etc/apache2/mods-available/perl.conf /etc/apache2/mods-enabled/
apache2 -t
invoke-rc.d apache2 restart
Смотрим что из этого получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | egrep '^USER|httpd' | grep -v grep
USER PID %CPU COMMAND
www-data 14039 0.6 httpd: GET /notices_item/????? HTTP/1.0
www-data 14073 0.5 httpd: GET /notice/???????.html HTTP/1.0
www-data 14069 0.5 httpd: GET /r_9/ HTTP/1.0
www-data 14075 0.5 httpd: GET /notice/???????.html HTTP/1.0
Я заменил часть URL-ов вопросиками из соображений конфиденциальности.
Ну что же, это неплохо, теперь мы видим отсортированные по полю %CPU процессы Apache, а так же видим, какой запрос они выполняют в данный момент. Но мы не видим к какому сайту относятся эти запросы. Придеться немного подпатчить модуль Apache2::ShowStatus в файле /usr/local/share/perl/5.8.8/Apache2/ShowStatus.pm:
--- ShowStatus.pm.orig 2009-01-22 14:19:26.122058102 +0300
+++ ShowStatus.pm 2009-01-22 14:21:01.030847967 +0300
@@ -16,7 +16,7 @@
my $r=shift;
$r->pnotes( 'ProctitleObject'=>
- Sys::Proctitle->new( 'httpd: '.$r->the_request ) );
+ Sys::Proctitle->new( 'httpd: ['.$r->get_server_name().'] '.$r->the_request ) );
return Apache2::Const::DECLINED;
}
Перезагружаем Apache:
invoke-rc.d apache2 restart
Смотрим, что получилось:
# ps -o user,pid,%cpu,args --sort=-%cpu -u www-data | grep httpd | grep -v grep
www-data 16927 3.3 httpd: [www.????????.ru] GET /img_code.html HTTP/1.0
www-data 16885 3.2 httpd: [76.?????????.ru] GET /notices_item/???????/user_register/ HTTP/1.0
www-data 16921 1.0 httpd: [www.??????.ru] GET /products_item/?????? HTTP/1.0
www-data 16933 0.5 httpd: [www.????????.ru] GET /notice/????????.html HTTP/1.0
www-data 16878 0.5 httpd: [??????????.ru] GET /main_???????? HTTP/1.0
www-data 16930 0.2 httpd: [www.??????????.ru] GET /notice/??????????.html?sd=?????????????????????????????? HTTP/1.0
Ну вот, теперь мы видим и сайт, к которому пришел запрос, и сам запрос.
Кто еще какие способы использует для мониторинга нагрузки на хостинге в окружении Apache2 + mod_php5?
Замечательный препроцессор для iptables
Я вполне хорошо знаю и умею пользоваться iptables, но не могу сказать, что написание сложных правил доставляет мне удовольствие, в отличие от того же pf). GUI для iptables меня обычно либо вводят в шок (например, fwbuilder просто вынес мне мозг, предоставив писать правила для iptables, как обычно, только мышкой), либо не дают всех нужных возможностей, которые есть в iptables.
На днях, наткнулся на совершенно замечательный препроцессор для iptables, который позволяет описывать правила на более высоком уровне. Что абсолютно радует, это человекочитаемость полученного конфига. В общем, я влюбился в эту программу. Зовется она ferm, подробно о ней можно почитать на домашней страничке проекта. Проект активно развивается, последняя версия выходила в этом месяце.
Чтобы вы сразу прониклись, красотой этой программы, кидаю свой конфиг /etc/ferm/ferm.conf с моего десктопного компа:
# -*- shell-script -*-
#
# Configuration file for ferm(1).
#
table filter {
chain INPUT {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
# allow local packages
interface lo ACCEPT;
# respond to ping
proto icmp ACCEPT;
interface eth1 {
mod state state NEW {
# pdns-recursor
proto (tcp udp) dport domain ACCEPT;
proto tcp {
# ssh
dport ssh ACCEPT;
# pulseaudio
dport 4713 ACCEPT;
# mysql
dport 3306 ACCEPT;
# memcached
dport 11211 ACCEPT;
}
}
}
}
chain OUTPUT {
policy ACCEPT;
# connection tracking
#mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
}
chain FORWARD {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
mod state state NEW {
interface eth1 ACCEPT;
outerface eth1 ACCEPT;
}
}
}
table nat {
chain POSTROUTING {
outerface (ppp0 ppp1) saddr 192.168.0.0/24 MASQUERADE;
}
}
# vim:sw=4 ts=4:
На днях, наткнулся на совершенно замечательный препроцессор для iptables, который позволяет описывать правила на более высоком уровне. Что абсолютно радует, это человекочитаемость полученного конфига. В общем, я влюбился в эту программу. Зовется она ferm, подробно о ней можно почитать на домашней страничке проекта. Проект активно развивается, последняя версия выходила в этом месяце.
Чтобы вы сразу прониклись, красотой этой программы, кидаю свой конфиг /etc/ferm/ferm.conf с моего десктопного компа:
# -*- shell-script -*-
#
# Configuration file for ferm(1).
#
table filter {
chain INPUT {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
# allow local packages
interface lo ACCEPT;
# respond to ping
proto icmp ACCEPT;
interface eth1 {
mod state state NEW {
# pdns-recursor
proto (tcp udp) dport domain ACCEPT;
proto tcp {
# ssh
dport ssh ACCEPT;
# pulseaudio
dport 4713 ACCEPT;
# mysql
dport 3306 ACCEPT;
# memcached
dport 11211 ACCEPT;
}
}
}
}
chain OUTPUT {
policy ACCEPT;
# connection tracking
#mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
}
chain FORWARD {
policy DROP;
# connection tracking
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
mod state state NEW {
interface eth1 ACCEPT;
outerface eth1 ACCEPT;
}
}
}
table nat {
chain POSTROUTING {
outerface (ppp0 ppp1) saddr 192.168.0.0/24 MASQUERADE;
}
}
# vim:sw=4 ts=4:
середа, 25 лютого 2009 р.
Добавление скрипта в автозагрузку
Добавить скрипт в автозагрузку
Пишем скрипт и помещаем его в каталог /etc/init.d Находясь в нем, набираем
# update-rc.d НАЗВАНИЕ_СКРИПТА defaults 99
-defaults запускать на уровнях выполнения по умолчанию (2 - 5)
-99 порядок загрузки
Отключить автозапуск скрипта (удалить все ссылки на скрипт)
Переходим в каталог /etc/init.d
# update-rc.d -f НАЗВАНИЕ_СКРИПТА remove
-f - удалить ссылки на скрипт из всех уровней запуска (сам скрипт в /etc/init.d не удаляется)
Полностью удалить скрипт из автозагрузки и все ссылки на него
Переходим в каталог /etc/init.d
# rm НАЗВАНИЕ_СКРИПТА
# update-rc.d НАЗВАНИЕ_СКРИПТА remove
Cделать локальный репозитарий
Есть куча deb пакетов когда то скачанных из интернета. Чтобы сделать из них свой репозитарий нужно перейти в каталог где лежат эти пакеты и выполнить:
$ dpkg-scanpackages . /dev/null | gzip > Packages.gz
Появиться файл Packages.gz Затем добавляем этой файл в начало файла /etc/apt/sources.list. Допустим пакеты лежат в /home/coder/debs, тогда строка будет выклядеть так
deb file:/home/coder/debs ./
Все. Теперь
# aptitude update
и можно пользоваться.
P.S. Утилита dpkg-scanpackages находиться в пакете dpkg-dev.
Сформировать пакеты из уже установленных программ (оригинальные deb пакеты были утеряны)
dpkg --get-selections | grep -v "deinstall" | awk '{print $1}' | xargs dpkg-repack
Пишем скрипт и помещаем его в каталог /etc/init.d Находясь в нем, набираем
# update-rc.d НАЗВАНИЕ_СКРИПТА defaults 99
-defaults запускать на уровнях выполнения по умолчанию (2 - 5)
-99 порядок загрузки
Отключить автозапуск скрипта (удалить все ссылки на скрипт)
Переходим в каталог /etc/init.d
# update-rc.d -f НАЗВАНИЕ_СКРИПТА remove
-f - удалить ссылки на скрипт из всех уровней запуска (сам скрипт в /etc/init.d не удаляется)
Полностью удалить скрипт из автозагрузки и все ссылки на него
Переходим в каталог /etc/init.d
# rm НАЗВАНИЕ_СКРИПТА
# update-rc.d НАЗВАНИЕ_СКРИПТА remove
Cделать локальный репозитарий
Есть куча deb пакетов когда то скачанных из интернета. Чтобы сделать из них свой репозитарий нужно перейти в каталог где лежат эти пакеты и выполнить:
$ dpkg-scanpackages . /dev/null | gzip > Packages.gz
Появиться файл Packages.gz Затем добавляем этой файл в начало файла /etc/apt/sources.list. Допустим пакеты лежат в /home/coder/debs, тогда строка будет выклядеть так
deb file:/home/coder/debs ./
Все. Теперь
# aptitude update
и можно пользоваться.
P.S. Утилита dpkg-scanpackages находиться в пакете dpkg-dev.
Сформировать пакеты из уже установленных программ (оригинальные deb пакеты были утеряны)
dpkg --get-selections | grep -v "deinstall" | awk '{print $1}' | xargs dpkg-repack
середа, 11 лютого 2009 р.
DNS Amplification (DNS усиление)
Не так давно столкнулся с проблемой (и ее решением) учитывая актуальность этой темы в последнее время, а также то, сколько людей сейчас страдают от этой беды, решил объединить информацию в одну статью. Может быть кому-то еще она будет полезной.
Начало
Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:
10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)
На что, как видно из лога, сервер отвечал отказами. Естественно мне стало интересно, что за IP-адреса долбят мой DNS. Посмотрев несколько адресов через whois я определил, что это крупные хостинговые компании, я написал просьбу прекратить атаку на мой сервер в техподдержку некоторых из них. В ответ я получил отписку, что этот тип атаки относится к тем, что они не могут блокировать, и что они сами они страдают от этой аномальной активности. Было решено со всем разбираться самому.
DNS Amplification (DNS усиление). Теория
Сам тип атаки не нов — о нем было известно еще в 2006 году, подробности на английском языке можно посмотреть здесь , однако активно использовать его начали относительно недавно. В январе-феврале 2009 года несколько интернет-изданий опубликовало информацию о крупномасштабном использовании киберпреступниками этого вида DDOS, о чем можно узнать здесь и на английском языке здесь
Объясняя простым языком, суть усиления заключается в том, что злоумышленник посылает (обычно короткий) запрос уязвимому DNS-серверу, который отвечает на запрос уже значительно большим по размеру пакетом. Если использовать в качестве исходного IP-адреса при отправке запроса адрес компьютера жертвы (ip spoofing), то уязвимый DNS-сервер будет посылать в большом количестве ненужные пакеты компьютеру-жертве, пока полностью не парализует его работу.
Практика
Наиболее эффективен этот тип атаки на старом (непропатченном) или неправильно сконфигурированном DNS-сервере, который, как уже было сказано, отвечает на короткие запросы злоумышленников большими по размеру пакетами.
Вот пример такого взаимодействия (кстати именно такие запросы чаще всего используют атакующие):
Отправляем серверу NS запрос командой
#dig @SERVER_IP NS
где SERVER_IP — IP-адрес сервера. В результате в логе по 53 порту сервера получаем:
11:08:47.994604 IP MY_IP.47816 > SERVER_IP.53: 5655+ NS?. (17)
т.е. как раз те 17 байт запроса, что мы хотели послать.
В ответ в то же самом логе видим:
11:08:47.995853 IP 192.168.100.254.53 > 192.168.100.100.47816: 5655 13/0/6 NS C.ROOT-SERVERS.NET.,[|domain]
т.е. сервер ответил нам подсказкой в виде адресов корневых DNS-серверов, что составляет уже 360 байт. Это длины DNS запроса и ответа, общая же длина пакетов 60 и 402 байта соответственно. Усиление налицо.
Что делать?
Во-первых конечно же проверить актуальность версии вашего DNS-сервера вне зависимости от того, на какой платформе он работает. Во-вторых, убедиться, что настроен сервер достаточно безопасно и не отвечает на «левые» запросы всем подряд. Об этом в сети можно найти множество мануалов и рекомендаций, упомяну здесь только об одном документе, который нашел не так давно.
Что еще можно сделать?
В моем случае делать было уже особенно нечего. Если посмотреть самый первый лог, который я привел, то видно, что атакующий отправляет запрос длиной 17 байт и получает REJECT той же самой длины (17 байт), т.е. никакого усиления не происходит. Но, видимо, «ddos-еры» особенно не торопятся убирать из своих списков адреса DNS-серверов, не подверженных этой уязвимости, и продолжают беспокоить их своей долбежкой… Эта ситуация меня не устраивала. Неприятно что от моего адреса кто-то получает на свой сервер ненужный трафик (даже пусть я в этом и не виноват).
Поначалу я начал ставить в black-лист адреса отправителей, но не тут-то было, со старых адресов атака прекращалась, но появлялись все новые и новые. Было решено использовать более изощренные методы фильтрации и задействовать на моем Linux-сервере модули iptables, до которых раньше у меня никак руки не доходили. Убить, так сказать, сразу двух зайцев — и атакующим сделать -1 и разобраться с парой модулей iptables.
Модуль String
Закрыть 53 порт (DNS) полностью я конечно же не мог — у меня много клиентов которым он нужен. Я решил фильтровать пакеты по содержимому DNS-запросов и убирать те из них, которые содержат запросы атакующих, а они все как один содержали в себе «NS». Для этой задачи подходит модуль iptables string, который как раз позволяет заглянуть в содержимое пакетов.
Для того, чтобы понять что фильтровать, посмотрим на пакет атакующего через wireshark.
Здесь и здесь можно почитать о структуре UDP пакетов и формате кадра DNS соответственно. Для краткости скажу, что первые 14 байт пакета занимают данные протокола Ethernet (на рис. красным), затем идут 20 байт заголовка протокола IP (на рис. синим), затем 8 байт — заголовок UDP (на рис. зеленым), после которого начинаются данные протокола DNS (на рис. желтым). Первые 12 байт кадра DNS занимает заголовок, после которого, наконец, начинается поле DNS Query (т.е. непосредственно сам запрос, на рис. оранжевым). В пакетах, присылаемых атакующим начиная с 54-ого (14+20+8+12) байта идут следующие данные: 00 00 02 00 01 (в шестнадцатеричном коде), что соответствует запросу «NS», о котором я говорил раньше. Таким образом нужно выделить пакеты, которые начиная с 54 байта содержат эти байты. Это будет выглядеть так:
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --jump DROP
Немного поясню.
--in-interface — указывает на каком интерфейсе отлавливать пакеты. Нужно поставить только внешний интерфейс, на который идет атака (незачем ущемлять пользователей во внутри сети).
--match state --state NEW — отлавливаем пакеты только со состоянием NEW, чтобы не проверять все транзакции подряд, а только инициирующие пакеты (мало ли что может передаваться по 53 порту).
Дальше идет самое интересное — задействуем модуль sting. Мы используем следующие параметры:
--algo — указывает алгоритм поиска, по сути не важен я указал kmp, но можно указать и bm;
--hex-string — записывается та самая строка в шестнадцатеричном виде, которую мы ищем;
--from 40 — ищем начиная с 40 байта (заметьте, не с 54 потому что string начинает поиск, а соответственно и отсчет от первого байта протокола IP, т.е. выбрасывается протокол Ethernet, длина которого 14 байт(на рис. сверху красным). Итого 54 — 14 = 40);
--to 45 — соответственно искать до 45 байта пакета.
Модуль Recent
На этом уже можно было бы остановиться. Пакеты уже не будут доходить до bind, но меня еще не утешала мысль, что я закрыл для ВСЕХ возможность обращаться с запросами NS к моему DNS-серверу, поэтому я решил задействовать еще один модуль iptables — recent.
Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.
Рассмотрим простой пример использования recent, состоящий из двух строк:
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --update --seconds 30 --name SSHT --jump DROP
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --set --name SSHT --jump ACCEPT
Начнем разбираться со второго правила. Каждый кто пытается зайти (именно зайти, т.к. мы используем --state NEW) на порт 22 (SSH) пропускается (--jump ACCEPT), но его IP-адрес попадает в таблицу с именем SSHT. Когда с этого адреса пытаются соединиться еще раз, начинает работать первое правило, смысл которого состоит в том, чтобы обновить (--update) запись в таблице и заодно проверить когда эта запись была установлена/обновлена в последний раз. Если запись была установлена/обновлена меньше 30 секунд назад (--seconds 30), то срабатывает --jump DROP и пакет отбрасывается. Таким образом брутфорсеры, пытающиеся долбиться на порт SSH будут отбрасывается, если частота отправки их пакетов будет превышать 1 пакет в 30 секунд.
Попробуем использовать recent для наших нужд:
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --update --seconds 600 --jump DROP
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --set --jump ACCEPT
Таким образом я разрешаю делать запросы NS на внешний интерфейс не чаще, чем 1 раз в 10 минут.
После добавления этих правил в /proc/net/xt_recent моего сервера появился файл DNST, в котором начали записываться IP-адреса атакующих. А DNS-сервер перестал поддаваться на провокации:
14:10:19.011818 IP 89.149.221.182.40320 > MY_IP.53: 23508+ NS?. (17)
14:10:25.243499 IP 89.149.221.182.64984 > MY_IP.53: 25306+ NS?. (17)
14:11:08.832827 IP 89.149.221.182.15864 > MY_IP.53: 48029+ NS?. (17)
14:11:15.063058 IP 89.149.221.182.30959 > MY_IP.53: 64444+ NS?. (17)
Через несколько дней работы правил количество пакетов со стороны атакующих снизилось в несколько раз. Сейчас я получаю 2-3 пакета в минуту, которые тут же отбрасываются фаерволом.
Джерело http://habrahabr.ru/blogs/infosecurity/51574/
четвер, 5 лютого 2009 р.
squid
From: Забудкин Лев Мирославович
Date: Fri, 14 Jan 2005 15:04:58 +0500 (YEKT)
Subject: Настройка Squid для начинающих
Настройка Squid для чайников
(версия статьи 1.0 от 29.10.2004)
Забудкин Лев Мирославович,
Россия, Тюменская область,
Г. Нижневартовск,
ведущий программист
МУ "Библиотечная-информационная система"
zabudkin@mail.ru
http://zabudkin.com
ВСТУПЛЕНИЕ
Многие администраторы сталкиваются с проблемой разумного использования
времени и канала для выхода в сеть Интернет, задумываются о возможности
экономии времени и денег, об ограничении скорости для отдельных видов
файлов или личностей, в конце концов об экономии всего, что связано с
теми или иными аспектами выхода в глобальную сеть.
Я, с помощью этой статьи, попытаюсь наглядно и доходчиво объяснить о
настройках самого распространенного прокси сервера - прокси
сервера Squid.
НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ
Мы не будем вдаваться в процесс установки прокси сервера Squid, а
перейдем сразу к его настройке.
Самое элементарное, что нам после установки следует сделать, так это
разрешить доступ пользователям нашей локальной сети. Для этого служат
параметры http_port, http_access. Кроме этого, мы заведем acl (список
контроля доступа) для нашей локальной сети.
И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid
должен обслуживать только компьютеры нашей локальной сети и быть
невидимым для внешнего мира, дабы исключить возможность "плохим
людям" внешней сети воспользоваться нашим каналом или трафиком, а
в случае, если будут обнаружены "дыры" в коде прокси сервера
Squid, воспользоваться ими.
Параметр http_access используется для разрешения или запрещения доступа
к определенным ресурсам, определенным адресам либо с определенных
адресов, к определенным сайтам, по определенным протоколам, портам и
всему тому, что непосредственно указано с помощью Acl (списков контроля
доступа).
Таблица N 1. Некоторые подсети.
|Диапазон адресов |Полная форма |Краткая форма
192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24
192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24
192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16
10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8
Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254,
тогда добавим новый Acl (см. таблицу N1):
acl LocalNet src 192.168.0.0/24
Предположим, что у Вас прокси сервер Squid расположен по адресу
192.168.0.200 на порту 3128, тогда пишем в файле конфигурации:
http_port 192.168.0.200:3128
Следующим нашим действием будет запрет использования нашего прокси
сервера, кроме как пользователями нашей локальной сети:
http_access allow LocalNet
http_access deny all
В данном случае слово allow является разрешением, а слово deny
запрещением, то есть мы разрешаем доступ к прокси серверу Squid с
адресов нашей локальной сети и запрещаем доступ всем остальным.
Будьте внимательны, указывая http_access, так как Squid использует их в
порядке указания Вами.
ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)
Система управления доступом в прокси сервере Squid является очень гибкой
и обширной. Она состоит из элементов со значениями и списков доступа c
указанием allow (разрешение) или deny (запрещение).
Формат Acl следующий:
acl имя элемент список
Формат списка доступа:
http_access указание имя_acl
Мы рассмотрим некоторые элементы, которые позволяет использовать прокси
сервер Squid, конечно же с примерами:
* acl имя src список
С помощью этого элемента (src) мы указываем IP-адрес источника, то есть
клиента от которого пришел запрос к нашему прокси серверу.
В следующем примере мы разрешим Васе Пупкину (Pupkin) и отделу
программирования (Progs) доступ к нашему прокси серверу, а всем
остальным запретим:
acl Progs src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
http_access allow Progs
http_access allow Pupkin
http_access deny all
* acl имя dst список
Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес
того сервера, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к
примеру, в ней находится тот же aport.ru):
acl Net194 dst 194.67.0.0/16
http_access deny Pupkin Net194
* acl имя dstdomain список
С помощью этого элемента (dstdomain) мы указываем домен, доступ к
которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и
kpnemo.ru:
acl SitesWarez dstdomain .nnm.ru .kpnemo.ru
http_access deny Pupkin SitesWarez
В случае, если будет необходимо указать домен источника, то используйте
srcdomain.
* acl имя [-i] srcdom_regex список
* acl имя [-i] dstdom_regex список
Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них
используются регулярные выражения, которые в данной статье мы не
рассматриваем, но пример всё-таки приведём:
Acl SitesRegexSex dstdom_regex sex
Acl SitesRegexComNet dstdom_regex \.com$ \.net$
http_access deny Pupkin SitesRegexSex
http_access deny Pupkin SitesRegexComNet
В данном примере мы запретили доступ Пупкину Василию на все домены,
содержащие слово sex и на все домены в зонах .com и .net.
Ключ -i призван игнорировать регистр символов в регулярных выражениях.
* acl имя [-i] url_regex список
С помощью этого элемента (url_regex) мы указываем шаблон регулярного
выражения для URL.
Пример указания файлов с расширением avi, начинающихся на слово sex:
acl NoAviFromSex url_regex -i sex.*\.avi$
В случае, если Вы желаете указать шаблон только для пути URL, то есть
исключая протокол и имя хоста (домена), то используйте urlpath_regex.
Пример для указания музыкальных файлов:
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
* acl имя_acl port список
Указание номера порта назначения, то есть порта, к которому желает
подключится клиент нашего прокси сервера.
Как пример, запретим всем использование программы Mirc через наш прокси
сервер:
Acl Mirc port 6667-6669 7770-7776
http_access deny all Mirc
* acl имя_acl proto список
Указание протокола передачи.
Как пример, запретим вышеупомянутому Васе использование протокола FTP
через наш прокси сервер:
acl ftpproto proto ftp
http_access deny Pupkin ftpproto
* acl имя_acl method список
Указание метода http запроса клиентом (GET, POST).
Возьмем ситуацию, когда следует запретить Васе Пупкину просматривать его
почту на сайте mail.ru, но при этом разрешить прогуливаться по сайту без
запретов, то есть запретить Васе возможность войти в свой почтовый ящик
через форму входа на сайте:
acl SiteMailRu dstdomain .mail.ru
acl methodpost method POST
http_access deny Pupkin methodpost SiteMailRu
ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Достаточно часто в нашей стране возникает ситуация, что канала доступа в
глобальную сеть Интернет на всех пользователей не хватает и возникает
желание дать каждому по максимуму, но при этом не дать каналу
"загнуться" из-за любителей позагружать файлы.
Средства прокси-сервера Squid позволяют этого добится несколькими путями:
- первый путь это оптимизация кеширования объектов;
- второй - это ограничение по времени определенных пользователей, что не
совсем корректно;
- третий путь заключается в ограничении скорости для определенных типов
файлов, пользователей и всего того, что определено нами через Acl.
ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ
Ограничить пользователей по времени можно следующим образом:
acl имя time дни чч:мм-ЧЧ:ММ
Где день: M - Понедельник, T - Вторник, W - Среда, H - Четверг, F -
Пятница, A - Суббота, S - Воскресенье.
При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с
00:00-23:59, но нельзя указать 20:00-09:00.
Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до
15 часов каждый день:
acl TimePupkin time 10:00-15:00
http_access deny Pupkin TimePupkin
Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14
часов, то пишем:
acl TimePupkin time 13:00-14:00
http_access allow Pupkin TimePupkin Mirc
http_access deny Pupkin Mirc
А что делать, если необходимо запретить или разрешить в определенные дни
недели? Squid также позволяет это сделать, к примеру с 13 до 14 в
понедельник и в воскресенье:
acl TimePupkin time MS 13:00-14:00
Как видите, ничего сложного в этом нет.
ОГРАНИЧЕНИЯ ПО СКОРОСТИ
Регулировка скорости в прокси сервере Squid осуществляется с помощью
пулов. Пул - это своего рода бочонок с пивом, в который пиво постоянно
заливают до краёв, а клиенты наливают в свои стаканы или иные ёмкости
для дальнейшего внутреннего потребления по мере надобности через свои
персональные краны.
Пулы регулируются с помощью трех параметров: delay_class,
delay_parameters, delay_access. Количество пулов указывается с помощью
параметра delay_pools.
Пулы могут быть трёх классов:
1. Весь поток пива ограничен одним краном (на всю сеть).
2. Весь поток пива ограничен одним краном, но при этом кран делится
на подкранчики (на каждый IP).
3. Весь поток пива ограничен одним краном, но кран делится на
подкранчики (на подсети), которые также делятся на мини кранчики (на
каждый IP).
Форматы:
delay_pools количество_объявленных_пулов
delay_access номер_пула действие имя_acl
действие может быть allow (разрешить) и deny (запретить). При этом,
данный пул действует на тех, кому он разрешен и не действует на тех,
кому он запрещен. В случае, если указано allow all, а затем deny Pupkin,
то на Пупкина данный класс всё-равно подействует, т.к. IP-адрес Пупкина
объявленный в acl Pupkin, входит в список адресов acl all. Имейте это
ввиду.
delay_class номер_пула класс_пула
delay_parameters номер_пула параметры
параметры отличаются в зависимости от класса пула:
для первого класса:
delay_parameters 1 байт_на_всю_сеть
для второго класса:
delay_parameters 1 на_всю_сеть на_клиента
для третьего класса:
delay_parameters 1 на_всю_сеть на_подсеть на_клиента
Для примера, у нас канал на 128 Кбит (в среднем 15 Кбайт в секунду) и мы
желаем Васе (Pupkin) дать всего 4 Кбайта/сек (на все про всё один
маленький бокальчик), отделу программирования (Prog) дать всего 10
Кбайт/сек и на каждого всего по 5 Кб/сек (всего два бокальчика), всех
остальных ограничить в 2 Кбайта/сек на каждого и 10 Кб/сек на всех, а
файлы mp3 (media) ограничить в 3 Кбайта в секунду на всех (на всю бочку
пива такой маленький кран). Тогда пишем:
acl Prog src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
acl LocalNet src 192.168.0.0/255.255.255.0
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
delay_pools 4
# сначала ограничим mp3
delay_class 1 1
delay_parameters 1 3000/3000
delay_access 1 allow media
delay_access 1 deny all
# ограничим бедного Васю
delay_class 2 1
delay_parameters 2 4000/4000
delay_access 2 allow Pupkin
delay_access 2 deny all
# ограничим отдел программирования
delay_class 3 2
delay_parameters 3 10000/10000 5000/5000
delay_access 3 allow Prog
delay_access 3 deny all
# а теперь ограничим остальных (второй класс пула)
delay_class 4 2
delay_parameters 4 10000/10000 2000/2000
delay_access 4 deny media
delay_access 4 deny Pupkin
delay_access 4 deny Prog
delay_access 4 allow LocalNet
delay_access 4 deny all
Часто возникает вопрос, а как лучше всего использовать столь малый
канал, чтобы он автоматически делился между всеми теми, кто в данный
момент что-либо загружает? На этот вопрос имеется однозначный ответ -
средствами прокси сервера Squid этого сделать не возможно, но всё-таки
кое-что предпринять можно:
delay_class 1 2
delay_parameters 1 -1/-1 5000/15000
delay_access 1 allow LocalNet
delay_access 1 deny all
Таким образом мы выделяем на всю нашу сеть и на подсети максимальный
канал (-1 означает неограниченность), а каждому пользователю даем
скорость максимум в 5 Кб/сек после того, как он скачает на максимальной
скорости первые 15 Кбайт документа.
Таким образом клиент не съест весь канал, но достаточно быстро получит
первые 15 Кбайт.
ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID
-----------------------------------------
Существует множество типов файлов, которые обновляются не достаточно
часто, чтобы позволить прокси серверу реагировать на заголовки от
вебсерверов о том, что данный объект не подлежит кешированию либо он был
на удивление только что изменён. Это довольно частая ситуация.
Для разрешения таких ситуаций призван параметр refresh_pattern в файле
настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его
рассматривать не будем.
Формат:
refresh_pattern [-i] строка МИНВ процент МАКСВ параметры
Данный параметр используется для того, чтобы определить возраст объекта
(считайте файла) в кеше, следует ли его обновлять или нет.
МИНВ (минимальное время) - время в минутах, когда объект, имеющийся в
кеше считается свежим.
МАКСВ (максимальное время) - максимальное время в минутах, когда объект
считается свежим.
Параметры - это один или несколько следующих параметров:
- override-expire - игнорировать информацию об истечении свежести объекта
и использовать МИНВ.
- override-lastmod - игнорировать информацию о дате изменения файла и
использовать МИНВ.
- reload-into-ims - вместо запроса клиентского запроса "не кешировать
документы" (no-cache) посылать запрос "Если изменен с"
(If-Modified-Since)
- ignore-reload - игнорировать запросы клиентов "не кешировать документы"
(no-cache) или "перезагрузить документ" (reload).
И так, мы подошли к самом главному. Ну, так какие же типы файлов реже
всех обновляются? Как правило, это разнообразные музыкальные файлы и
картинки.
Установим свежесть объектов, для этого для картинок и музыкальных файлов
укажем, скажем так для примера, целых 30 дней (43200 минут):
refresh_pattern -i \.gif$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.png$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpeg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.pdf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.zip$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tar$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.gz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tgz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.exe$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.prz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.ppt$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.inf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.swf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mid$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.wav$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mp3$ 43200 100% 43200 override-lastmod override-expire
Показанные Выше настройки лишь пример, для того, чтобы была понятна
суть.
Теперь можете проверить эффективность своего прокси сервера, она уж
точно возрастет.
ЗАКЛЮЧЕНИЕ
Прокси сервер Squid не является одним лишь распространенным прокси
сервером, существуют и другие. Но как показывает статистика, большинство
используют именно этот прокси сервер, но при этом всё равно у многих
начинающих возникают проблемы с настройкой.
С помощью этой статьи я попытался хоть немного раскрыть для обширных
масс некоторые функции прокси сервера Squid.
Джерело: http://www.opennet.ru/base/net/squid_inst.txt.html
Date: Fri, 14 Jan 2005 15:04:58 +0500 (YEKT)
Subject: Настройка Squid для начинающих
Настройка Squid для чайников
(версия статьи 1.0 от 29.10.2004)
Забудкин Лев Мирославович,
Россия, Тюменская область,
Г. Нижневартовск,
ведущий программист
МУ "Библиотечная-информационная система"
zabudkin@mail.ru
http://zabudkin.com
ВСТУПЛЕНИЕ
Многие администраторы сталкиваются с проблемой разумного использования
времени и канала для выхода в сеть Интернет, задумываются о возможности
экономии времени и денег, об ограничении скорости для отдельных видов
файлов или личностей, в конце концов об экономии всего, что связано с
теми или иными аспектами выхода в глобальную сеть.
Я, с помощью этой статьи, попытаюсь наглядно и доходчиво объяснить о
настройках самого распространенного прокси сервера - прокси
сервера Squid.
НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ
Мы не будем вдаваться в процесс установки прокси сервера Squid, а
перейдем сразу к его настройке.
Самое элементарное, что нам после установки следует сделать, так это
разрешить доступ пользователям нашей локальной сети. Для этого служат
параметры http_port, http_access. Кроме этого, мы заведем acl (список
контроля доступа) для нашей локальной сети.
И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid
должен обслуживать только компьютеры нашей локальной сети и быть
невидимым для внешнего мира, дабы исключить возможность "плохим
людям" внешней сети воспользоваться нашим каналом или трафиком, а
в случае, если будут обнаружены "дыры" в коде прокси сервера
Squid, воспользоваться ими.
Параметр http_access используется для разрешения или запрещения доступа
к определенным ресурсам, определенным адресам либо с определенных
адресов, к определенным сайтам, по определенным протоколам, портам и
всему тому, что непосредственно указано с помощью Acl (списков контроля
доступа).
Таблица N 1. Некоторые подсети.
|Диапазон адресов |Полная форма |Краткая форма
192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24
192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24
192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16
10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8
Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254,
тогда добавим новый Acl (см. таблицу N1):
acl LocalNet src 192.168.0.0/24
Предположим, что у Вас прокси сервер Squid расположен по адресу
192.168.0.200 на порту 3128, тогда пишем в файле конфигурации:
http_port 192.168.0.200:3128
Следующим нашим действием будет запрет использования нашего прокси
сервера, кроме как пользователями нашей локальной сети:
http_access allow LocalNet
http_access deny all
В данном случае слово allow является разрешением, а слово deny
запрещением, то есть мы разрешаем доступ к прокси серверу Squid с
адресов нашей локальной сети и запрещаем доступ всем остальным.
Будьте внимательны, указывая http_access, так как Squid использует их в
порядке указания Вами.
ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)
Система управления доступом в прокси сервере Squid является очень гибкой
и обширной. Она состоит из элементов со значениями и списков доступа c
указанием allow (разрешение) или deny (запрещение).
Формат Acl следующий:
acl имя элемент список
Формат списка доступа:
http_access указание имя_acl
Мы рассмотрим некоторые элементы, которые позволяет использовать прокси
сервер Squid, конечно же с примерами:
* acl имя src список
С помощью этого элемента (src) мы указываем IP-адрес источника, то есть
клиента от которого пришел запрос к нашему прокси серверу.
В следующем примере мы разрешим Васе Пупкину (Pupkin) и отделу
программирования (Progs) доступ к нашему прокси серверу, а всем
остальным запретим:
acl Progs src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
http_access allow Progs
http_access allow Pupkin
http_access deny all
* acl имя dst список
Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес
того сервера, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к
примеру, в ней находится тот же aport.ru):
acl Net194 dst 194.67.0.0/16
http_access deny Pupkin Net194
* acl имя dstdomain список
С помощью этого элемента (dstdomain) мы указываем домен, доступ к
которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и
kpnemo.ru:
acl SitesWarez dstdomain .nnm.ru .kpnemo.ru
http_access deny Pupkin SitesWarez
В случае, если будет необходимо указать домен источника, то используйте
srcdomain.
* acl имя [-i] srcdom_regex список
* acl имя [-i] dstdom_regex список
Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них
используются регулярные выражения, которые в данной статье мы не
рассматриваем, но пример всё-таки приведём:
Acl SitesRegexSex dstdom_regex sex
Acl SitesRegexComNet dstdom_regex \.com$ \.net$
http_access deny Pupkin SitesRegexSex
http_access deny Pupkin SitesRegexComNet
В данном примере мы запретили доступ Пупкину Василию на все домены,
содержащие слово sex и на все домены в зонах .com и .net.
Ключ -i призван игнорировать регистр символов в регулярных выражениях.
* acl имя [-i] url_regex список
С помощью этого элемента (url_regex) мы указываем шаблон регулярного
выражения для URL.
Пример указания файлов с расширением avi, начинающихся на слово sex:
acl NoAviFromSex url_regex -i sex.*\.avi$
В случае, если Вы желаете указать шаблон только для пути URL, то есть
исключая протокол и имя хоста (домена), то используйте urlpath_regex.
Пример для указания музыкальных файлов:
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
* acl имя_acl port список
Указание номера порта назначения, то есть порта, к которому желает
подключится клиент нашего прокси сервера.
Как пример, запретим всем использование программы Mirc через наш прокси
сервер:
Acl Mirc port 6667-6669 7770-7776
http_access deny all Mirc
* acl имя_acl proto список
Указание протокола передачи.
Как пример, запретим вышеупомянутому Васе использование протокола FTP
через наш прокси сервер:
acl ftpproto proto ftp
http_access deny Pupkin ftpproto
* acl имя_acl method список
Указание метода http запроса клиентом (GET, POST).
Возьмем ситуацию, когда следует запретить Васе Пупкину просматривать его
почту на сайте mail.ru, но при этом разрешить прогуливаться по сайту без
запретов, то есть запретить Васе возможность войти в свой почтовый ящик
через форму входа на сайте:
acl SiteMailRu dstdomain .mail.ru
acl methodpost method POST
http_access deny Pupkin methodpost SiteMailRu
ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Достаточно часто в нашей стране возникает ситуация, что канала доступа в
глобальную сеть Интернет на всех пользователей не хватает и возникает
желание дать каждому по максимуму, но при этом не дать каналу
"загнуться" из-за любителей позагружать файлы.
Средства прокси-сервера Squid позволяют этого добится несколькими путями:
- первый путь это оптимизация кеширования объектов;
- второй - это ограничение по времени определенных пользователей, что не
совсем корректно;
- третий путь заключается в ограничении скорости для определенных типов
файлов, пользователей и всего того, что определено нами через Acl.
ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ
Ограничить пользователей по времени можно следующим образом:
acl имя time дни чч:мм-ЧЧ:ММ
Где день: M - Понедельник, T - Вторник, W - Среда, H - Четверг, F -
Пятница, A - Суббота, S - Воскресенье.
При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с
00:00-23:59, но нельзя указать 20:00-09:00.
Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до
15 часов каждый день:
acl TimePupkin time 10:00-15:00
http_access deny Pupkin TimePupkin
Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14
часов, то пишем:
acl TimePupkin time 13:00-14:00
http_access allow Pupkin TimePupkin Mirc
http_access deny Pupkin Mirc
А что делать, если необходимо запретить или разрешить в определенные дни
недели? Squid также позволяет это сделать, к примеру с 13 до 14 в
понедельник и в воскресенье:
acl TimePupkin time MS 13:00-14:00
Как видите, ничего сложного в этом нет.
ОГРАНИЧЕНИЯ ПО СКОРОСТИ
Регулировка скорости в прокси сервере Squid осуществляется с помощью
пулов. Пул - это своего рода бочонок с пивом, в который пиво постоянно
заливают до краёв, а клиенты наливают в свои стаканы или иные ёмкости
для дальнейшего внутреннего потребления по мере надобности через свои
персональные краны.
Пулы регулируются с помощью трех параметров: delay_class,
delay_parameters, delay_access. Количество пулов указывается с помощью
параметра delay_pools.
Пулы могут быть трёх классов:
1. Весь поток пива ограничен одним краном (на всю сеть).
2. Весь поток пива ограничен одним краном, но при этом кран делится
на подкранчики (на каждый IP).
3. Весь поток пива ограничен одним краном, но кран делится на
подкранчики (на подсети), которые также делятся на мини кранчики (на
каждый IP).
Форматы:
delay_pools количество_объявленных_пулов
delay_access номер_пула действие имя_acl
действие может быть allow (разрешить) и deny (запретить). При этом,
данный пул действует на тех, кому он разрешен и не действует на тех,
кому он запрещен. В случае, если указано allow all, а затем deny Pupkin,
то на Пупкина данный класс всё-равно подействует, т.к. IP-адрес Пупкина
объявленный в acl Pupkin, входит в список адресов acl all. Имейте это
ввиду.
delay_class номер_пула класс_пула
delay_parameters номер_пула параметры
параметры отличаются в зависимости от класса пула:
для первого класса:
delay_parameters 1 байт_на_всю_сеть
для второго класса:
delay_parameters 1 на_всю_сеть на_клиента
для третьего класса:
delay_parameters 1 на_всю_сеть на_подсеть на_клиента
Для примера, у нас канал на 128 Кбит (в среднем 15 Кбайт в секунду) и мы
желаем Васе (Pupkin) дать всего 4 Кбайта/сек (на все про всё один
маленький бокальчик), отделу программирования (Prog) дать всего 10
Кбайт/сек и на каждого всего по 5 Кб/сек (всего два бокальчика), всех
остальных ограничить в 2 Кбайта/сек на каждого и 10 Кб/сек на всех, а
файлы mp3 (media) ограничить в 3 Кбайта в секунду на всех (на всю бочку
пива такой маленький кран). Тогда пишем:
acl Prog src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
acl LocalNet src 192.168.0.0/255.255.255.0
acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$
delay_pools 4
# сначала ограничим mp3
delay_class 1 1
delay_parameters 1 3000/3000
delay_access 1 allow media
delay_access 1 deny all
# ограничим бедного Васю
delay_class 2 1
delay_parameters 2 4000/4000
delay_access 2 allow Pupkin
delay_access 2 deny all
# ограничим отдел программирования
delay_class 3 2
delay_parameters 3 10000/10000 5000/5000
delay_access 3 allow Prog
delay_access 3 deny all
# а теперь ограничим остальных (второй класс пула)
delay_class 4 2
delay_parameters 4 10000/10000 2000/2000
delay_access 4 deny media
delay_access 4 deny Pupkin
delay_access 4 deny Prog
delay_access 4 allow LocalNet
delay_access 4 deny all
Часто возникает вопрос, а как лучше всего использовать столь малый
канал, чтобы он автоматически делился между всеми теми, кто в данный
момент что-либо загружает? На этот вопрос имеется однозначный ответ -
средствами прокси сервера Squid этого сделать не возможно, но всё-таки
кое-что предпринять можно:
delay_class 1 2
delay_parameters 1 -1/-1 5000/15000
delay_access 1 allow LocalNet
delay_access 1 deny all
Таким образом мы выделяем на всю нашу сеть и на подсети максимальный
канал (-1 означает неограниченность), а каждому пользователю даем
скорость максимум в 5 Кб/сек после того, как он скачает на максимальной
скорости первые 15 Кбайт документа.
Таким образом клиент не съест весь канал, но достаточно быстро получит
первые 15 Кбайт.
ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID
-----------------------------------------
Существует множество типов файлов, которые обновляются не достаточно
часто, чтобы позволить прокси серверу реагировать на заголовки от
вебсерверов о том, что данный объект не подлежит кешированию либо он был
на удивление только что изменён. Это довольно частая ситуация.
Для разрешения таких ситуаций призван параметр refresh_pattern в файле
настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его
рассматривать не будем.
Формат:
refresh_pattern [-i] строка МИНВ процент МАКСВ параметры
Данный параметр используется для того, чтобы определить возраст объекта
(считайте файла) в кеше, следует ли его обновлять или нет.
МИНВ (минимальное время) - время в минутах, когда объект, имеющийся в
кеше считается свежим.
МАКСВ (максимальное время) - максимальное время в минутах, когда объект
считается свежим.
Параметры - это один или несколько следующих параметров:
- override-expire - игнорировать информацию об истечении свежести объекта
и использовать МИНВ.
- override-lastmod - игнорировать информацию о дате изменения файла и
использовать МИНВ.
- reload-into-ims - вместо запроса клиентского запроса "не кешировать
документы" (no-cache) посылать запрос "Если изменен с"
(If-Modified-Since)
- ignore-reload - игнорировать запросы клиентов "не кешировать документы"
(no-cache) или "перезагрузить документ" (reload).
И так, мы подошли к самом главному. Ну, так какие же типы файлов реже
всех обновляются? Как правило, это разнообразные музыкальные файлы и
картинки.
Установим свежесть объектов, для этого для картинок и музыкальных файлов
укажем, скажем так для примера, целых 30 дней (43200 минут):
refresh_pattern -i \.gif$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.png$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.jpeg$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.pdf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.zip$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tar$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.gz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.tgz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.exe$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.prz$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.ppt$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.inf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.swf$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mid$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.wav$ 43200 100% 43200 override-lastmod override-expire
refresh_pattern -i \.mp3$ 43200 100% 43200 override-lastmod override-expire
Показанные Выше настройки лишь пример, для того, чтобы была понятна
суть.
Теперь можете проверить эффективность своего прокси сервера, она уж
точно возрастет.
ЗАКЛЮЧЕНИЕ
Прокси сервер Squid не является одним лишь распространенным прокси
сервером, существуют и другие. Но как показывает статистика, большинство
используют именно этот прокси сервер, но при этом всё равно у многих
начинающих возникают проблемы с настройкой.
С помощью этой статьи я попытался хоть немного раскрыть для обширных
масс некоторые функции прокси сервера Squid.
Джерело: http://www.opennet.ru/base/net/squid_inst.txt.html
вівторок, 27 січня 2009 р.
vsftpd переведений конфіг
#Пример файла конфигурации /etc/vsftpd.conf
#
# По умолчанию в настройках составлен довольно параноиком. Это образец файла
# Loosens вещи немного вверх, чтобы сделать FTP-демон, более удобным для использования.
# См. vsftpd.conf.5 все воедино в значения по умолчанию.
#
# ПРОЧИТАЙТЕ ЭТО: В данном примере файл не является исчерпывающим перечнем vsftpd вариантов.
# Пожалуйста, прочитайте страницу руководства vsftpd.conf.5 чтобы получить больше идей по vsftpd
# возможностям.
#
#
#Если опция включена сервер стартует в независимом от inetd/xinetd режиме
#"standalone mode". В этом случае он сам заботится о прослушивании и
#определении входящих соединений.
listen=YES
#
#Тоже самое что listen, за исключением того что vsftpd слушает IPv6 протокол включительно.
#Этот параметр и listen взаимно исключаемые.
#listen_ipv6=YES
#
# Разрешает или запрещает вход анонимных пользователей. Если разрешено, пользователи
#с именами ftp и anonymous распознаются как анонимные пользователи.
anonymous_enable=YES
#
# Разрешает или запрещает вход для локальных пользователей. Если включено
#обычные пользовательские акаунты в /etc/passwd могут быть использованы для входа.
#Должно быть включено для разрешения любых не анонимных входов, включая вход
#виртуальных пользователей.
#local_enable=YES
#
# Разрешает FTP команды изменяющие файловую систему. Такие команды как:
#STOR, DELE, RNFR, RNTO, MKD, RMD, APPE, SITE.
write_enable=YES
#
#Значение маски назначения прав доступа к файлам созданным локальными
#пользователями. Помните! Если вы хотите указать параметр в качестве
#цифрового значения, указывайте "0" (нулевую) приставку, иначе
#значение будет определено как целое десятизначное.
#local_umask=022
#
#Включение этой опции позволяет анонимным пользователям загружать файлы на сервер, в
#соответствии с определенными для этого условиями. Для того чтобы это работало опция
#write_enable должна быть активирована, и анонимный ftp пользователь должен иметь права
#на запись в каталоге для загрузки. Включение опции также необходимо для предоставления
#возможности загружать на сервер файлы виртуальным пользователям; по умолчанию виртуальные
#пользователи имеют одинаковые привилегии с анонимными пользователями
#(т.е. максимально ограниченные привилегии).
anon_upload_enable=YES
#
# Включение этой опции, позволяет анонимным пользователям создавать новые каталоги в
#соответствии с определенными для этого условиями. Для того чтобы это работало опция
#write_enable должна быть включена, и анонимный пользователь должен иметь права на
#запись в данном каталоге.
anon_mkdir_write_enable=YES
#
#Если разрешено, при входе в каталог пользователям показывается сообщение
#из файла .message. По умолчанию, директория сканируется на наличие
#сообщения в файле .message, что можно изменить задав имя другого файла
#параметром message_file..
dirmessage_enable=YES
#
#Если включено, журнал будет включать детальные отчеты о закачках на сервер,
#и закачках с сервера (uploads, downloads). По умолчанию, этот файл будет
#располагаться в /var/log/vsftpd.log, но расположение может быть изменено
#используя опцию vsftpd_log_file.
xferlog_enable=YES
#
#Включение этой опции указывает исходящим с сервера соединениям использовать
#20 порт. Из соображений безопасности, некоторые клиенты могут настаивать
#на этом значении. Отключение этой опции позволяет vsftpd стартовать с немного
#меньшими привилегиями.
connect_from_port_20=YES
#
#Если включить, у всех анонимно закачанных файлов на сервер будут
#изменены владельцы на пользователя в указанного в chown_username.
#Это может быть полезно при администрировании, и возможно из соображений
#безопасности.
#chown_uploads=YES
#chown_username=whoever
#
#В параметре этой опции можно указать альтернативный путь к файлу
#журнала записываемому в стиле wu-ftpd. Запись в этот журнал производится
#только при включенной xferlog_eneble опции, включительно с xferlog_std_format.
#Также журнал ведется если включена опция dual_log_enable.
#xferlog_file=/var/log/vsftpd.log
#
#Если включено, запись в журнал производится в стандартном wu-ftpd стиле,
#xferlog формата. Полезно при желании использования уже существующих
#привычных способов генерации статистики. Однако с другой стороны,
#формат используемый по умолчанию лучше читается. Расположение журнала
#по умолчанию /var/log/xferlog, что может быть изменено при
#помощи опции xferlog_file.
#xferlog_std_format=YES
#
#Временной промежуток в секундах указывающий для удаленного клиента
#максимальное время которое он может бездействовать не выполняя FTP команды.
#Если время исчерпано, соединение отбрасывается.
#idle_session_timeout=600
#
# Максимальный временной промежуток в секундах, разрешенного замирания процесса
#передачи данных. Если перерыв превышен, соединение с удаленным клиентом отбрасывается.
#data_connection_timeout=120
#
#Указывает имя пользователя под которым работает сервер, когда ему не нужны привилегии.
#Для этого предпочтительней выделить отдельного пользователя, чем использовать nobody
#nopriv_user=ftpsecure
#
#При включении, специальные FTP команды известные как "async ABOR"
#будут разрешены. Только плохо продуманные FTP клиенты используют эту функцию.
#В добавок эта функция неудобна в управлении, поэтому отключена по умолчанию.
#К сожалению, некоторые FTP клиенты могут зависать в момент отмены передачи,
#если эта функция выключена. Если это происходит можно попробовать включить
#эту функцию.
#async_abor_enable=YES
#
#При включёном ASCII режиме возможна DDOS атака с использованием
#"SIZE / большой / файл".
# Если включить, ASCII режим передачи будет разрешен при uploads.
#ascii_upload_enable=YES
#Если включить, ASCII режим передачи данных будет разрешен при download.
#ascii_download_enable=YES
#
# В этой опции можно указать банер-строку выводимую на экран клиента при подключении к серверу
#ftpd_banner=Welcome to blah FTP service.
#
#Активация опции, позволяет использовать список анонимных паролей типа e-mail, при
#использовании которых попытки подключения будут отвергнуты. По умолчанию, файл содержащий
#этот список располагается в /etc/vsftpd.banned_emails, но имеется возможность изменить путь,
#указав альтернативный путь в banned_email_file.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
#Если выбрано локальные пользователи будут (по умолчанию) перенесены в chroot () "заточение"
#в их домашнем каталоге после входа. Внимание: эта опция имеет смысл быть включенной из
#соображений безопасности, особенно если пользователи имеют права позволяющие загрузку
#файлов на сервер, или shell доступ. Включать только если вы действительно уверены что
#знаете зачем вам это нужно. Заметим что эта опция безопасности в системах класса unix,
#характерна не только для vsftpd, используется и в других FTP серверах.
#chroot_local_user=YES
#
#Если включить, вы можете использовать список локальных пользователей помещаемых в
#chroot() заточение в их домашнем каталоге после входа. Если используется совместно
#с включенным chroot_local_user означает список пользователей которые не помещаются
#в chroot() заточение. По умолчанию список содержится в файле /etc/vsftpd.chroot_list,
#но можно указать любой другой путь к файлу используя опцию chroot_list_file.
#chroot_list_enable=YES
# (default follows)
#Опция является дополнением к chroot_list_enable указывает альтернативный путь
#к файлу содержащему список локальных пользователей которые будут перемещены в chroot()
#заточение в их домашние каталоги при входе. Эта опция уместна только при разрешенной
#chroot_list_enable. Если опция chroot_local_user включена, наоборот указывает
#файл списка пользователей не помещаемых в chroot() заточение.
#chroot_list_file=/etc/vsftpd.chroot_list
#
#При включении, разрешает рекурсивный листинг "ls -R". Включение немного
#рискованно исходя из соображений безопасности, так как выполнение "ls -R" в
#верхнем уровне большого сайта может поглощать много ресурсов.
#ls_recurse_enable=YES
#
#
# настройки Debian
#
# Some of vsftpd's settings don't fit the Debian filesystem layout by
# default. These settings are more Debian-friendly.
#
№Эта опция указывает на имя пустого каталога. Также, каталог не должен быть записываемый
№для ftp пользователя. Этот каталог используется как безопасный chroot(), когда vsftpd не
№нужен доступ к файловой системе.
secure_chroot_dir=/var/run/vsftpd
#
#В этой строке можно указать имя PAM сервиса который будет использоваться для vsftpd.
pam_service_name=vsftpd
#
#Эта опция задает расположения RSA сертификата для использования в
#SSL зашифрованных соединениях.
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#Эта опция задает расположения личного RSA ключа для использования в
#SSL зашифрованных соединениях.
#Если эта опция не выбрана, сертификат предусматривается как личный ключ.
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
то, что в спойлере, можете смело закидывать в файл /etc/vsftpd.conf
файл русифицирован с помощью http://www.opennet.ru/base/net/vsftpd_overview.txt.html этой статьи по настройке vsftpd
#
# По умолчанию в настройках составлен довольно параноиком. Это образец файла
# Loosens вещи немного вверх, чтобы сделать FTP-демон, более удобным для использования.
# См. vsftpd.conf.5 все воедино в значения по умолчанию.
#
# ПРОЧИТАЙТЕ ЭТО: В данном примере файл не является исчерпывающим перечнем vsftpd вариантов.
# Пожалуйста, прочитайте страницу руководства vsftpd.conf.5 чтобы получить больше идей по vsftpd
# возможностям.
#
#
#Если опция включена сервер стартует в независимом от inetd/xinetd режиме
#"standalone mode". В этом случае он сам заботится о прослушивании и
#определении входящих соединений.
listen=YES
#
#Тоже самое что listen, за исключением того что vsftpd слушает IPv6 протокол включительно.
#Этот параметр и listen взаимно исключаемые.
#listen_ipv6=YES
#
# Разрешает или запрещает вход анонимных пользователей. Если разрешено, пользователи
#с именами ftp и anonymous распознаются как анонимные пользователи.
anonymous_enable=YES
#
# Разрешает или запрещает вход для локальных пользователей. Если включено
#обычные пользовательские акаунты в /etc/passwd могут быть использованы для входа.
#Должно быть включено для разрешения любых не анонимных входов, включая вход
#виртуальных пользователей.
#local_enable=YES
#
# Разрешает FTP команды изменяющие файловую систему. Такие команды как:
#STOR, DELE, RNFR, RNTO, MKD, RMD, APPE, SITE.
write_enable=YES
#
#Значение маски назначения прав доступа к файлам созданным локальными
#пользователями. Помните! Если вы хотите указать параметр в качестве
#цифрового значения, указывайте "0" (нулевую) приставку, иначе
#значение будет определено как целое десятизначное.
#local_umask=022
#
#Включение этой опции позволяет анонимным пользователям загружать файлы на сервер, в
#соответствии с определенными для этого условиями. Для того чтобы это работало опция
#write_enable должна быть активирована, и анонимный ftp пользователь должен иметь права
#на запись в каталоге для загрузки. Включение опции также необходимо для предоставления
#возможности загружать на сервер файлы виртуальным пользователям; по умолчанию виртуальные
#пользователи имеют одинаковые привилегии с анонимными пользователями
#(т.е. максимально ограниченные привилегии).
anon_upload_enable=YES
#
# Включение этой опции, позволяет анонимным пользователям создавать новые каталоги в
#соответствии с определенными для этого условиями. Для того чтобы это работало опция
#write_enable должна быть включена, и анонимный пользователь должен иметь права на
#запись в данном каталоге.
anon_mkdir_write_enable=YES
#
#Если разрешено, при входе в каталог пользователям показывается сообщение
#из файла .message. По умолчанию, директория сканируется на наличие
#сообщения в файле .message, что можно изменить задав имя другого файла
#параметром message_file..
dirmessage_enable=YES
#
#Если включено, журнал будет включать детальные отчеты о закачках на сервер,
#и закачках с сервера (uploads, downloads). По умолчанию, этот файл будет
#располагаться в /var/log/vsftpd.log, но расположение может быть изменено
#используя опцию vsftpd_log_file.
xferlog_enable=YES
#
#Включение этой опции указывает исходящим с сервера соединениям использовать
#20 порт. Из соображений безопасности, некоторые клиенты могут настаивать
#на этом значении. Отключение этой опции позволяет vsftpd стартовать с немного
#меньшими привилегиями.
connect_from_port_20=YES
#
#Если включить, у всех анонимно закачанных файлов на сервер будут
#изменены владельцы на пользователя в указанного в chown_username.
#Это может быть полезно при администрировании, и возможно из соображений
#безопасности.
#chown_uploads=YES
#chown_username=whoever
#
#В параметре этой опции можно указать альтернативный путь к файлу
#журнала записываемому в стиле wu-ftpd. Запись в этот журнал производится
#только при включенной xferlog_eneble опции, включительно с xferlog_std_format.
#Также журнал ведется если включена опция dual_log_enable.
#xferlog_file=/var/log/vsftpd.log
#
#Если включено, запись в журнал производится в стандартном wu-ftpd стиле,
#xferlog формата. Полезно при желании использования уже существующих
#привычных способов генерации статистики. Однако с другой стороны,
#формат используемый по умолчанию лучше читается. Расположение журнала
#по умолчанию /var/log/xferlog, что может быть изменено при
#помощи опции xferlog_file.
#xferlog_std_format=YES
#
#Временной промежуток в секундах указывающий для удаленного клиента
#максимальное время которое он может бездействовать не выполняя FTP команды.
#Если время исчерпано, соединение отбрасывается.
#idle_session_timeout=600
#
# Максимальный временной промежуток в секундах, разрешенного замирания процесса
#передачи данных. Если перерыв превышен, соединение с удаленным клиентом отбрасывается.
#data_connection_timeout=120
#
#Указывает имя пользователя под которым работает сервер, когда ему не нужны привилегии.
#Для этого предпочтительней выделить отдельного пользователя, чем использовать nobody
#nopriv_user=ftpsecure
#
#При включении, специальные FTP команды известные как "async ABOR"
#будут разрешены. Только плохо продуманные FTP клиенты используют эту функцию.
#В добавок эта функция неудобна в управлении, поэтому отключена по умолчанию.
#К сожалению, некоторые FTP клиенты могут зависать в момент отмены передачи,
#если эта функция выключена. Если это происходит можно попробовать включить
#эту функцию.
#async_abor_enable=YES
#
#При включёном ASCII режиме возможна DDOS атака с использованием
#"SIZE / большой / файл".
# Если включить, ASCII режим передачи будет разрешен при uploads.
#ascii_upload_enable=YES
#Если включить, ASCII режим передачи данных будет разрешен при download.
#ascii_download_enable=YES
#
# В этой опции можно указать банер-строку выводимую на экран клиента при подключении к серверу
#ftpd_banner=Welcome to blah FTP service.
#
#Активация опции, позволяет использовать список анонимных паролей типа e-mail, при
#использовании которых попытки подключения будут отвергнуты. По умолчанию, файл содержащий
#этот список располагается в /etc/vsftpd.banned_emails, но имеется возможность изменить путь,
#указав альтернативный путь в banned_email_file.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
#Если выбрано локальные пользователи будут (по умолчанию) перенесены в chroot () "заточение"
#в их домашнем каталоге после входа. Внимание: эта опция имеет смысл быть включенной из
#соображений безопасности, особенно если пользователи имеют права позволяющие загрузку
#файлов на сервер, или shell доступ. Включать только если вы действительно уверены что
#знаете зачем вам это нужно. Заметим что эта опция безопасности в системах класса unix,
#характерна не только для vsftpd, используется и в других FTP серверах.
#chroot_local_user=YES
#
#Если включить, вы можете использовать список локальных пользователей помещаемых в
#chroot() заточение в их домашнем каталоге после входа. Если используется совместно
#с включенным chroot_local_user означает список пользователей которые не помещаются
#в chroot() заточение. По умолчанию список содержится в файле /etc/vsftpd.chroot_list,
#но можно указать любой другой путь к файлу используя опцию chroot_list_file.
#chroot_list_enable=YES
# (default follows)
#Опция является дополнением к chroot_list_enable указывает альтернативный путь
#к файлу содержащему список локальных пользователей которые будут перемещены в chroot()
#заточение в их домашние каталоги при входе. Эта опция уместна только при разрешенной
#chroot_list_enable. Если опция chroot_local_user включена, наоборот указывает
#файл списка пользователей не помещаемых в chroot() заточение.
#chroot_list_file=/etc/vsftpd.chroot_list
#
#При включении, разрешает рекурсивный листинг "ls -R". Включение немного
#рискованно исходя из соображений безопасности, так как выполнение "ls -R" в
#верхнем уровне большого сайта может поглощать много ресурсов.
#ls_recurse_enable=YES
#
#
# настройки Debian
#
# Some of vsftpd's settings don't fit the Debian filesystem layout by
# default. These settings are more Debian-friendly.
#
№Эта опция указывает на имя пустого каталога. Также, каталог не должен быть записываемый
№для ftp пользователя. Этот каталог используется как безопасный chroot(), когда vsftpd не
№нужен доступ к файловой системе.
secure_chroot_dir=/var/run/vsftpd
#
#В этой строке можно указать имя PAM сервиса который будет использоваться для vsftpd.
pam_service_name=vsftpd
#
#Эта опция задает расположения RSA сертификата для использования в
#SSL зашифрованных соединениях.
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#Эта опция задает расположения личного RSA ключа для использования в
#SSL зашифрованных соединениях.
#Если эта опция не выбрана, сертификат предусматривается как личный ключ.
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
то, что в спойлере, можете смело закидывать в файл /etc/vsftpd.conf
файл русифицирован с помощью http://www.opennet.ru/base/net/vsftpd_overview.txt.html этой статьи по настройке vsftpd
понеділок, 26 січня 2009 р.
bind 9
Этот документ описывает установку и начальную конфигурацию пакета BIND 9 для работы в качестве кэширующего DNS сервера для локальной сети.
Было решено использовать 9-ю версию пакета BIND, так как она наименее уязвима для внешних атак. BIND 9 поддерживает списки управления доступом для запросов, передачи зоны, а также динамических обновлений. Кроме того, этой версией поддерживается стандарт динамических обновлений и уведомления об изменениях зоны, она может использовать механизм инкрементальной передачи зоны, позволяющий вторичным DNS серверам запрашивать у первичных серверов только изменения зональных данных. Это позволяет ускорить передачу зон.
В качестве ОС на сервере установлена FreeBSD 4.10.
Получение, сборка и установка пакета BIND из исходных кодов
На момент написания статьи последней стабильной версией BIND 9 являлась 9.2.3.
Исходные коды BIND 9.2.3 доступны для загрузки с публичного FTP сервера: ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz.
Итак.
Создаем директорию, где будет проходить весь процесс:
# mkdir /usr/local/src
# cd /usr/local/src
Скачиваем дистрибутив с FTP сервера ftp.isc.org:
# fetch ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz
Распаковываем, и заходим в полученную папку:
# tar -xzf bind-9.2.3.tar.gz
# cd bind-9.2.3
Мы хотим что бы наш BIND 9 стал вместо штатного BIND 8.
# ./configure --prefix=/usr --sysconfdir=/etc/namedb
Далее, если конфигурация прошла успешно, приступаем к сборке пакета:
# make
# make install
На моей системе (FreeBSD 4.10) все собралось и установилось без каких-либо проблем.
Проверяем версию named которая у нас теперь стоит:
# named -v
BIND 9.2.3
Пусть вас не пугает, что мы устанавливаем BIND, а для проверки запускаем named. Так называется исполняемый файл, который, собственно говоря, и выполняет роль DNS сервера.
На этом первый этап нашей затеи окончен, BIND 9 скомпилирован и установлен в вашей системе, можно порадоваться за себя. :)
Установка BIND 9 из портов FreeBSD
Если порты у вас обновляются регулярно, то переходим в соответствующую директорию:
# cd /usr/ports/dns/bind9
Если не регулярно, то, вероятно, ваш BIND 9 нужно искать здесь:
# cd /usr/ports/net/bind9
Если портов у вас совсем нет, то устанавливайте BIND 9 из исходных кодов (см. выше).
Итак делаем следующие шаги.
Переходим в каталог BIND9 в ваших портах и компиллируем BIND 9:
# cd /usr/ports/dns/bind9
# make PORT_REPLACES_BASE_BIND9=yes install
Данная операция необходима для того, чтобы BIND 9 был установлен вместо штатного BIND 8.
Система сама скачает дистрибутив, распакует, сконфигурирует и установит.
После того, как закончится установка, предлагаю убедиться, что теперь у вас установлен именно BIND 9:
# named -v
BIND 9.2.3
На этом установка BIND 9 закончена, теперь можно переходить к конфигурированию и запуску. :)
Маленькая ремарка: я предпочитаю установку из портов, потому что в дальнейшем очень удобно обновлять пакет при помощи portupgrade, например, и потому, что устанавливать из портов просто удобнее.
Начальное конфигурирование и запуск BIND 9
Если у вас был установлен BIND 8, который идет в поставке с системой, то, вероятно, в папке /etc/namedb вы найдете файл конфигурации bind и некоторые дополнительные файлы, которые могут понадобиться для работы BIND. Если таких файлов у вас нет, никогда не было, и вы не знаете, где их взять, придется писать их с нуля. Я, например, нашел эти файлы в исходных кодах системы /usr/src/etc/namedb/.
Если вы обнаружили у себя соответствующие файлы, внимательно делайте необходимые правки в них. Будьте особенно осторожны, если вы решились писать конфигурационные файлы с нуля.
Итак, сначала создадим самый главный файл - файл конфигурации. Возьмите свой любимый текстовый редактор и создайте новый файл с именем named.conf. Содержание у него будет примерно такое:
# cat named.conf
// Первой строкой задаем сети, которым будет разрешено
//посылать запросы через наш DNS-сервер:
acl "corpnets" { 192.168.1.0/24; 192.168.2.0/24; 127.0.0.1; };
options {
// Рабочая директория:
directory "/etc/namedb";
// Pid файл создавать тоже в рабочей директории, хотя можно
// написать любую другую, например /var/run/named/named.pid:
pid-file "named.pid";
// Разрешаем посылать запросы только от тех сетей, которые мы
// указали выше:
allow-query { "corpnets"; };
};
// Указатели корневых серверов:
zone "." {
type hint;
file "named.root"; };
// Настраиваем обратное отображение
// для адреса 127.0.0.1:
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no; };
С файлом named.conf пока все. Теперь нужно создать файлы, на которые мы ссылаемся в named.conf, а именно: named.root и localhost.rev.
Файл named.root скачиваем c FTP-сервера ftp.internic.net:
# fetch ftp://ftp.internic.net/domain/named.root
Желательно периодически повторять эту процедуру или настроить на автоматическое обновление через cron.
Файл localhost.rev можно написать вручную, а можно воспользоваться специальной утилитой make-localhost, которая находится в исходных кодах системы: /usr/src/etc/namedb/make-localhost.
Выглядит он примерно так:
# cat localhost.rev
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the 'make-localhost' script in
; the /etc/namedb directory.
;
$TTL 3600
@ IN SOA zm.domain.com. root.zm.domain.com. (
20040603 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS zm.domain.com.
1 IN PTR localhost.domain.com.
С файлом localhost.rev тоже закончили.
Теперь можно попробовать запустить и проверить наш bind:
# named
# ps -ax|grep named
Если процес запущен и работает, пробуем послать запрос через наш DNS-сервер:
# dig @127.0.0.1 ya.ru
В ответ на этот запрос мы должны получить некий положительный ответ, например:
# dig @127.0.0.1 ya.ru
; <<>> DiG 9.2.1 <<>> @127.0.0.1 ya.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36843
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;ya.ru. IN A
;; ANSWER SECTION:
ya.ru. 36000 IN A 213.180.193.123
;; AUTHORITY SECTION:
ya.ru. 36000 IN NS ns1.yandex.ru.
ya.ru. 36000 IN NS ns2.yandex.ru.
ya.ru. 36000 IN NS ns3.yandex.ru.
ya.ru. 36000 IN NS ns.ispm.ru.
;; Query time: 2639 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jun 13 22:28:50 2004
;; MSG SIZE rcvd: 122
Если ответа нет, идем смотреть логи системы в /var/log/messages, читаем, что нам пишет наш bind, и пытаемся понять, с чем это может быть связано.
Надеюсь, вы догадаетесь при необходимости настроить соответствующим образом ваш фаервол для работы DNS-сервера.
Если положительный ответ получен, значит ваш DNS-сервер работает и теоретически может обслуживать вашу сеть :)
Теперь давайте настроим ваш компьютер на работу с установленным DNS-сервером. Для этого необходимо внести изменения в файл /etc/resolv.conf. Выглядеть он будет примерно следующим образом:
# cat /etc/resolv.conf
# Ваш домен
domain domain.com
# IP адрес либо 127.0.0.1 либо адрес вашей машины
nameserver 127.0.0.1
Проверяем, обращается ли ваша машина к установленному DNS-серверу:
# nslookup yandex.ru
Server: localhost.domain.com
Address: 127.0.0.1
Non-authoritative answer:
Name: yandex.ru
Address: 213.180.216.200
Если получен ответ, аналогичный тому, что вы видите выше, значит, обращение происходит успешно.
С целью уменьшения трафика от вашего DNS сервера имеет смысл указать ему адреса DNS серверов вашего провайдера. В этом случае при попытке резольвинга DNS имени ваш DNS сервер будет сначала обращаться к кэшу на сервере провайдера.
Для этого необходимо добавить в наш файл конфигурации (named.conf) опцию forwarders.
В секции options добавляем следующую строку:
forwarders { 195.5.45.17; };
Не забудьте изменить IP адрес на адрес DNS сервера вашего провайдера.
Секция options в файле конфигурации должна выглядеть вот так:
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working dir
allow-query { "corpnets"; };
forwarders { 195.5.45.17; };
};
После изменения файла конфигурации необходимо перестартовать named, для чего можно воспользоваться командой:
# killall -HUP named
Настройка DNS-сервера для работы с утилитой удаленного администрирования rdnc
Теперь настроим наш DNS сервер для работы с утилитой удаленного администрирования rndc, которая в дальнейшем вам очень пригодится.
Чтобы решить эту задачу, нам необходимо создать файл конфигурации для утилиты rndc.conf и добавить несколько строк в конфигурационный файл нашего сервера.
Копируем содержимое файла /usr/sbin/rndc-confgen в файл /etc/namedb/rndc.conf, который будет служить конфигурационным файлом для утилиты rndc:
# /usr/sbin/rndc-confgen > /etc/namedb/rndc.conf
В результате выполнения этой команды мы получим файл rndc.conf примерно следующего содержания:
# Начало файла rndc.conf
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# Конец файла rndc.conf
# Начало секции для named.conf
# Для использования ключа авторизации необходимо добавить следующие строки в файл
# named.conf, при необходимости исправив список разрешенных для авторизации хостов:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
#Конец секции для named.conf
Теперь нужно добавить в самое начало файла конфигурации DNS сервера (named.conf) следующую секцию файла rndc.conf:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
После этого можно перезапустить named:
# killall -HUP named
Давайте проверим, работает ли наша утилита для удаленного администрирования DNS сервера:
# rndc status
number of zones: 3
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
Если выполнение данной команды прошло успешно, и вы получили примерно то, что получилось выше, значит утилита смогла подключиться к вашему named, успешно авторизовалась при помощи ключа, который мы создали, и попросила показать статус DNS сервера.
При помощи утилиты rndc можно делать очень много различных операций с вашим DNS сервером. Запустите ее без аргументов и увидите список доступных команд. :)
На этом установка и конфигурация вашего DNS сервера закончена. После ее окончания должен получиться DNS сервер, который может обслуживать вашу локальную сеть, использовать кэш DNS-сервера провайдера для оптимизации распознания имен Интернет и поддерживает удаленное управление при помощи утилиты rndc.
В следующей части статьи мы рассмотрим такие темы, как:
1. Настройка DNS сервера для поддержки домена.
2. Повышение безопасности DNS сервера.
3. Параметры в файле доменной зоны.
Автор: Дмитрий Донченко.
Огромное спасибо всем кто помогал написать эту статью. Отдельное спасибо bm-у, моему лучшему другу и коллеге, который высматривал очепятки и неправильности в том, что я тут насочинял.
Оригінал : http://www.ru-board.com/new/article.php?sid=161
Было решено использовать 9-ю версию пакета BIND, так как она наименее уязвима для внешних атак. BIND 9 поддерживает списки управления доступом для запросов, передачи зоны, а также динамических обновлений. Кроме того, этой версией поддерживается стандарт динамических обновлений и уведомления об изменениях зоны, она может использовать механизм инкрементальной передачи зоны, позволяющий вторичным DNS серверам запрашивать у первичных серверов только изменения зональных данных. Это позволяет ускорить передачу зон.
В качестве ОС на сервере установлена FreeBSD 4.10.
Получение, сборка и установка пакета BIND из исходных кодов
На момент написания статьи последней стабильной версией BIND 9 являлась 9.2.3.
Исходные коды BIND 9.2.3 доступны для загрузки с публичного FTP сервера: ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz.
Итак.
Создаем директорию, где будет проходить весь процесс:
# mkdir /usr/local/src
# cd /usr/local/src
Скачиваем дистрибутив с FTP сервера ftp.isc.org:
# fetch ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz
Распаковываем, и заходим в полученную папку:
# tar -xzf bind-9.2.3.tar.gz
# cd bind-9.2.3
Мы хотим что бы наш BIND 9 стал вместо штатного BIND 8.
# ./configure --prefix=/usr --sysconfdir=/etc/namedb
Далее, если конфигурация прошла успешно, приступаем к сборке пакета:
# make
# make install
На моей системе (FreeBSD 4.10) все собралось и установилось без каких-либо проблем.
Проверяем версию named которая у нас теперь стоит:
# named -v
BIND 9.2.3
Пусть вас не пугает, что мы устанавливаем BIND, а для проверки запускаем named. Так называется исполняемый файл, который, собственно говоря, и выполняет роль DNS сервера.
На этом первый этап нашей затеи окончен, BIND 9 скомпилирован и установлен в вашей системе, можно порадоваться за себя. :)
Установка BIND 9 из портов FreeBSD
Если порты у вас обновляются регулярно, то переходим в соответствующую директорию:
# cd /usr/ports/dns/bind9
Если не регулярно, то, вероятно, ваш BIND 9 нужно искать здесь:
# cd /usr/ports/net/bind9
Если портов у вас совсем нет, то устанавливайте BIND 9 из исходных кодов (см. выше).
Итак делаем следующие шаги.
Переходим в каталог BIND9 в ваших портах и компиллируем BIND 9:
# cd /usr/ports/dns/bind9
# make PORT_REPLACES_BASE_BIND9=yes install
Данная операция необходима для того, чтобы BIND 9 был установлен вместо штатного BIND 8.
Система сама скачает дистрибутив, распакует, сконфигурирует и установит.
После того, как закончится установка, предлагаю убедиться, что теперь у вас установлен именно BIND 9:
# named -v
BIND 9.2.3
На этом установка BIND 9 закончена, теперь можно переходить к конфигурированию и запуску. :)
Маленькая ремарка: я предпочитаю установку из портов, потому что в дальнейшем очень удобно обновлять пакет при помощи portupgrade, например, и потому, что устанавливать из портов просто удобнее.
Начальное конфигурирование и запуск BIND 9
Если у вас был установлен BIND 8, который идет в поставке с системой, то, вероятно, в папке /etc/namedb вы найдете файл конфигурации bind и некоторые дополнительные файлы, которые могут понадобиться для работы BIND. Если таких файлов у вас нет, никогда не было, и вы не знаете, где их взять, придется писать их с нуля. Я, например, нашел эти файлы в исходных кодах системы /usr/src/etc/namedb/.
Если вы обнаружили у себя соответствующие файлы, внимательно делайте необходимые правки в них. Будьте особенно осторожны, если вы решились писать конфигурационные файлы с нуля.
Итак, сначала создадим самый главный файл - файл конфигурации. Возьмите свой любимый текстовый редактор и создайте новый файл с именем named.conf. Содержание у него будет примерно такое:
# cat named.conf
// Первой строкой задаем сети, которым будет разрешено
//посылать запросы через наш DNS-сервер:
acl "corpnets" { 192.168.1.0/24; 192.168.2.0/24; 127.0.0.1; };
options {
// Рабочая директория:
directory "/etc/namedb";
// Pid файл создавать тоже в рабочей директории, хотя можно
// написать любую другую, например /var/run/named/named.pid:
pid-file "named.pid";
// Разрешаем посылать запросы только от тех сетей, которые мы
// указали выше:
allow-query { "corpnets"; };
};
// Указатели корневых серверов:
zone "." {
type hint;
file "named.root"; };
// Настраиваем обратное отображение
// для адреса 127.0.0.1:
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no; };
С файлом named.conf пока все. Теперь нужно создать файлы, на которые мы ссылаемся в named.conf, а именно: named.root и localhost.rev.
Файл named.root скачиваем c FTP-сервера ftp.internic.net:
# fetch ftp://ftp.internic.net/domain/named.root
Желательно периодически повторять эту процедуру или настроить на автоматическое обновление через cron.
Файл localhost.rev можно написать вручную, а можно воспользоваться специальной утилитой make-localhost, которая находится в исходных кодах системы: /usr/src/etc/namedb/make-localhost.
Выглядит он примерно так:
# cat localhost.rev
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the 'make-localhost' script in
; the /etc/namedb directory.
;
$TTL 3600
@ IN SOA zm.domain.com. root.zm.domain.com. (
20040603 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS zm.domain.com.
1 IN PTR localhost.domain.com.
С файлом localhost.rev тоже закончили.
Теперь можно попробовать запустить и проверить наш bind:
# named
# ps -ax|grep named
Если процес запущен и работает, пробуем послать запрос через наш DNS-сервер:
# dig @127.0.0.1 ya.ru
В ответ на этот запрос мы должны получить некий положительный ответ, например:
# dig @127.0.0.1 ya.ru
; <<>> DiG 9.2.1 <<>> @127.0.0.1 ya.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36843
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;ya.ru. IN A
;; ANSWER SECTION:
ya.ru. 36000 IN A 213.180.193.123
;; AUTHORITY SECTION:
ya.ru. 36000 IN NS ns1.yandex.ru.
ya.ru. 36000 IN NS ns2.yandex.ru.
ya.ru. 36000 IN NS ns3.yandex.ru.
ya.ru. 36000 IN NS ns.ispm.ru.
;; Query time: 2639 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jun 13 22:28:50 2004
;; MSG SIZE rcvd: 122
Если ответа нет, идем смотреть логи системы в /var/log/messages, читаем, что нам пишет наш bind, и пытаемся понять, с чем это может быть связано.
Надеюсь, вы догадаетесь при необходимости настроить соответствующим образом ваш фаервол для работы DNS-сервера.
Если положительный ответ получен, значит ваш DNS-сервер работает и теоретически может обслуживать вашу сеть :)
Теперь давайте настроим ваш компьютер на работу с установленным DNS-сервером. Для этого необходимо внести изменения в файл /etc/resolv.conf. Выглядеть он будет примерно следующим образом:
# cat /etc/resolv.conf
# Ваш домен
domain domain.com
# IP адрес либо 127.0.0.1 либо адрес вашей машины
nameserver 127.0.0.1
Проверяем, обращается ли ваша машина к установленному DNS-серверу:
# nslookup yandex.ru
Server: localhost.domain.com
Address: 127.0.0.1
Non-authoritative answer:
Name: yandex.ru
Address: 213.180.216.200
Если получен ответ, аналогичный тому, что вы видите выше, значит, обращение происходит успешно.
С целью уменьшения трафика от вашего DNS сервера имеет смысл указать ему адреса DNS серверов вашего провайдера. В этом случае при попытке резольвинга DNS имени ваш DNS сервер будет сначала обращаться к кэшу на сервере провайдера.
Для этого необходимо добавить в наш файл конфигурации (named.conf) опцию forwarders.
В секции options добавляем следующую строку:
forwarders { 195.5.45.17; };
Не забудьте изменить IP адрес на адрес DNS сервера вашего провайдера.
Секция options в файле конфигурации должна выглядеть вот так:
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working dir
allow-query { "corpnets"; };
forwarders { 195.5.45.17; };
};
После изменения файла конфигурации необходимо перестартовать named, для чего можно воспользоваться командой:
# killall -HUP named
Настройка DNS-сервера для работы с утилитой удаленного администрирования rdnc
Теперь настроим наш DNS сервер для работы с утилитой удаленного администрирования rndc, которая в дальнейшем вам очень пригодится.
Чтобы решить эту задачу, нам необходимо создать файл конфигурации для утилиты rndc.conf и добавить несколько строк в конфигурационный файл нашего сервера.
Копируем содержимое файла /usr/sbin/rndc-confgen в файл /etc/namedb/rndc.conf, который будет служить конфигурационным файлом для утилиты rndc:
# /usr/sbin/rndc-confgen > /etc/namedb/rndc.conf
В результате выполнения этой команды мы получим файл rndc.conf примерно следующего содержания:
# Начало файла rndc.conf
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# Конец файла rndc.conf
# Начало секции для named.conf
# Для использования ключа авторизации необходимо добавить следующие строки в файл
# named.conf, при необходимости исправив список разрешенных для авторизации хостов:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
#Конец секции для named.conf
Теперь нужно добавить в самое начало файла конфигурации DNS сервера (named.conf) следующую секцию файла rndc.conf:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
После этого можно перезапустить named:
# killall -HUP named
Давайте проверим, работает ли наша утилита для удаленного администрирования DNS сервера:
# rndc status
number of zones: 3
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
Если выполнение данной команды прошло успешно, и вы получили примерно то, что получилось выше, значит утилита смогла подключиться к вашему named, успешно авторизовалась при помощи ключа, который мы создали, и попросила показать статус DNS сервера.
При помощи утилиты rndc можно делать очень много различных операций с вашим DNS сервером. Запустите ее без аргументов и увидите список доступных команд. :)
На этом установка и конфигурация вашего DNS сервера закончена. После ее окончания должен получиться DNS сервер, который может обслуживать вашу локальную сеть, использовать кэш DNS-сервера провайдера для оптимизации распознания имен Интернет и поддерживает удаленное управление при помощи утилиты rndc.
В следующей части статьи мы рассмотрим такие темы, как:
1. Настройка DNS сервера для поддержки домена.
2. Повышение безопасности DNS сервера.
3. Параметры в файле доменной зоны.
Автор: Дмитрий Донченко.
Огромное спасибо всем кто помогал написать эту статью. Отдельное спасибо bm-у, моему лучшему другу и коллеге, который высматривал очепятки и неправильности в том, что я тут насочинял.
Оригінал : http://www.ru-board.com/new/article.php?sid=161
середа, 3 грудня 2008 р.
Apache2 + SSL под Debian
Привет всем. Сегодня все-таки добрался до Ooo2.4 и решил написать ещё одну заметку.
Недавно столкнулся с такой проблемой... Нужно было поставить Apache2 и настроить его, чтобы он работал с SSL.
Для начала нам нужно поставить сам apache2:
#apt-get install apache2
Далее нам нужно создать .htaccess в /var/www со следующим текстом (данная операция не позволит просмотреть каталог с php файлами если отсутствует index.* файл):
#echo "Options -Indexes" > /var/www/.htaccess
Далее создаем ключ:
#openssl genrsa -des3 -out name.key 1024
genrsa - указывает для библиотеки OpenSSL, что мы хотим сгенерировать пару ключей.
des3 - указывает, что секретный ключ должен быть зашифрован и защищен ключевой фразой (pass phrase).
Опция out указывает, где следует сохранить результаты.
Число 1024 указывает длину генерируемых ключей в битах.
Создаём сертификат
#openssl req -new -key name.key -out name.csr
Вас попросят ввести пароль, который потом будет нужен в дальнейшем при подписи создаваемого сертификата и при запуске apacha2.
На запрос: Country Name (2 letter code) [AU]:
(Выбираем RU)
На запрос: State or Province Name (full name) [Some-State]: (Вводим край или область или ... где находимся)
На запрос: Locality Name (eg, city) []: (Вводим наименование города)
На запрос: Organization Name (eg, company) [Internet Widgits Pty Ltd]: (Вводим наименование организации)
На запрос: Organizational Unit Name (eg, section) []: (Вводим наименование вашего подразделения)
На запрос: Common Name (eg, YOUR name) []: (Вводим ваше имя)
На запрос: Email Address []: (вводим ваш электронный адрес)
Далее идут расширенные опции:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
На них можно просто нажать Enter пока программа не создаст name.csr
Сформированный файл запроса подписи сертификата сохранится файле name.csr. Узнать о содержании сертификата можно узнать так - openssl req -noout -text -in name.csr. В идеале, файл запроса подписи сертификата нужно отослать в сертификационную службу для обработки. Verisign и Thawte - две наиболее известные сертификационные службы. Но можно создать само-подписанный сертификат.
Создаем сертификат с личной подписью
#openssl x509 -req -days 700 -in name.csr -signkey name.key -out name.cert
Следует скопировать файл сертификата name.cert (или тот, что возвращен вам сертификационной службой) и файл с ключами secure.home.net.key в пути SSLCertificateFile и SSLCertificateKeyFile соответственно.
Далее создаем директорию где будут храниться наши ключи и сертификаты:
#mkdir /etc/apache2/keys
Далее перемещаем в /etc/apache2/keys наши name.key, name.csr и name.cert:
#mv name.key /etc/apache2/keys && mv name.csr /etc/apache2/keys && mv name.cert /etc/apache2/keys
Далее правим файл в /etc/apache2/sites-available/default-ssl:
#nano default-ssl
Ищем и правим следующее:
< Directory / >
...
AllowOverride All
< /Directory >
< Directory /var/www >
...
AllowOverride All
...
< /Directory >
Еще ищем следующие строки и редактируем их:
SSLCertificateFile /etcl/apache2/keys/name.cert
SSLCertificateKeyFile /etc/apache2/keys/name.key
После того, как отредактировали этот файл, нам нужно будет включить наш сайт:
#a2ensite default-ssl
Выключить стандартный http:
#a2dissite default
Затем включаем модуль SSL:
#a2enmod ssl
И после всего это нам осталось перезапустить наш Apache2:
#/etc/init.d/apache restart
Зы. Все, теперь можете попробовать зайти на https://localhost. Удачи! =)
http://fearuth.blog.ru/11191075.html
Недавно столкнулся с такой проблемой... Нужно было поставить Apache2 и настроить его, чтобы он работал с SSL.
Для начала нам нужно поставить сам apache2:
#apt-get install apache2
Далее нам нужно создать .htaccess в /var/www со следующим текстом (данная операция не позволит просмотреть каталог с php файлами если отсутствует index.* файл):
#echo "Options -Indexes" > /var/www/.htaccess
Далее создаем ключ:
#openssl genrsa -des3 -out name.key 1024
genrsa - указывает для библиотеки OpenSSL, что мы хотим сгенерировать пару ключей.
des3 - указывает, что секретный ключ должен быть зашифрован и защищен ключевой фразой (pass phrase).
Опция out указывает, где следует сохранить результаты.
Число 1024 указывает длину генерируемых ключей в битах.
Создаём сертификат
#openssl req -new -key name.key -out name.csr
Вас попросят ввести пароль, который потом будет нужен в дальнейшем при подписи создаваемого сертификата и при запуске apacha2.
На запрос: Country Name (2 letter code) [AU]:
(Выбираем RU)
На запрос: State or Province Name (full name) [Some-State]: (Вводим край или область или ... где находимся)
На запрос: Locality Name (eg, city) []: (Вводим наименование города)
На запрос: Organization Name (eg, company) [Internet Widgits Pty Ltd]: (Вводим наименование организации)
На запрос: Organizational Unit Name (eg, section) []: (Вводим наименование вашего подразделения)
На запрос: Common Name (eg, YOUR name) []: (Вводим ваше имя)
На запрос: Email Address []: (вводим ваш электронный адрес)
Далее идут расширенные опции:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
На них можно просто нажать Enter пока программа не создаст name.csr
Сформированный файл запроса подписи сертификата сохранится файле name.csr. Узнать о содержании сертификата можно узнать так - openssl req -noout -text -in name.csr. В идеале, файл запроса подписи сертификата нужно отослать в сертификационную службу для обработки. Verisign и Thawte - две наиболее известные сертификационные службы. Но можно создать само-подписанный сертификат.
Создаем сертификат с личной подписью
#openssl x509 -req -days 700 -in name.csr -signkey name.key -out name.cert
Следует скопировать файл сертификата name.cert (или тот, что возвращен вам сертификационной службой) и файл с ключами secure.home.net.key в пути SSLCertificateFile и SSLCertificateKeyFile соответственно.
Далее создаем директорию где будут храниться наши ключи и сертификаты:
#mkdir /etc/apache2/keys
Далее перемещаем в /etc/apache2/keys наши name.key, name.csr и name.cert:
#mv name.key /etc/apache2/keys && mv name.csr /etc/apache2/keys && mv name.cert /etc/apache2/keys
Далее правим файл в /etc/apache2/sites-available/default-ssl:
#nano default-ssl
Ищем и правим следующее:
< Directory / >
...
AllowOverride All
< /Directory >
< Directory /var/www >
...
AllowOverride All
...
< /Directory >
Еще ищем следующие строки и редактируем их:
SSLCertificateFile /etcl/apache2/keys/name.cert
SSLCertificateKeyFile /etc/apache2/keys/name.key
После того, как отредактировали этот файл, нам нужно будет включить наш сайт:
#a2ensite default-ssl
Выключить стандартный http:
#a2dissite default
Затем включаем модуль SSL:
#a2enmod ssl
И после всего это нам осталось перезапустить наш Apache2:
#/etc/init.d/apache restart
Зы. Все, теперь можете попробовать зайти на https://localhost. Удачи! =)
http://fearuth.blog.ru/11191075.html
Підписатися на:
Дописи (Atom)