Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Alt26.Alt16. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве



Squid и борьба с банерами и порно

2007-03-08 · Posted in Squid-cache, Unix FreeBSD

Для борьбы с баннерами порно-сайтами достаточно прописать пару строк в конфигурационный файл прокси-сервера Squid и создать список ‘нежелательных’ URL, как это правильно сделать описано ниже:

1)Необходимо указать файл, в котором будут храниться имена и маски ‘нежелательных’ сайтов, для этого в файл squid.conf(в ЮНИКС-системах он обычно располагается по адресу /usr/local/squid/etc/squid.conf) в раздел ACCESS CONTROLS нужно вписать следующее…

Понятно, что в первой строке вы указываете путь к файлу, где хранятся полные URL и ‘маски’ баннерных URL.
Во второй путь к файлу хранящему порно-URL.
В третьей к адресам, которые должны быть доступны в любом случае. Это необходимо тогда, когда в каком-то из ‘правильных’ адресов есть часть, включающая в себя ‘маску’ банера или порно. Например, если вы хотите посмотреть новостной сайт, в адресе страницы которого есть слово analitic, а у вас в списке порно присутствует ‘маска’ anal, то к аналитике вам не добраться. Тогда вам нужно вписать ‘маску’ этого URL в список nobanners.
Далее перед всеми разрешениями http_access вписываем.

Тем самым разрешая все, указанное в списке НеБаннеры, и запрещая все, указанное в списках Баннеры и Порно. Далее следуют все остальные ваши разрешения. Или располагайте эти строки по вашему усмотрению, если понимаете, что делаете. :)

2)Вам нужно создать эти самые файлы и чем то их наполнить. Мы предлагаем вам варианты уже созданных файлов.

Banners
Porno
NoBanners
Вы можете скачать их и разместить в местах, которые вы указали в конфигурационном файле прокси-сервера.

3)Перезапустите сквид командой

– ! Пример команды приведен для ОС Linux.

4)Наслаждайтесь жизнью.

Помните, что порносайты, как и баннерные системы постоянно плодятся и множатся, в связи с чем периеодически пополняйте ваши СТОП-листы, дабы борьба была эффективной. На этом сайте файлы обновляются раз в неделю, вы можете регулярно скачивать отсюда свежие СТОП-листы.
Так же мы просим вас, если вы обнаружите URL порносайта или баннерной системы, не указанный в новейшем из списков, вы можете пойти сюда или прислать нам письмо, на адрес master#fork.kiev.ua с пометкой SQUID в теме и адресом или списком адресов, которые необходимо добавить в тот или иной файл. Мы постоянно будем пополнять существующие файлы и помогать в этом всем желающим. Все ваши пополнения будут доступны для скачивания в следующей версии СТОП-листов. Давайте помогать друг другу. Только есть одна просьба, пожалуйста, присылайте ТОЛЬКО дополнения к листам, потому что очень сложно выискивать в полном файле изменения и добавлять их к существующему.

В список Банеров мы так же включаем некоторые ссылки, с которых пользователи пытаются скачать слишком много лишнего.
(test on)Squid-2.4.STABLE*
Этот материал может помочь любителям порно, теперь не придется искать новый УРЛ. 8)

Да, все же для экономии траффика баннерных систем Вам необходимо использовать редиректор, т.к. сквид все равно все баннеры тянет в кеш.

 

information, mail user, su

2007-03-08 · Posted in Unix FreeBSD

FreeBSD > Display information about the system

FreeBSD comes with different utilities, which can be use to gathered the information as per your needs.

1) Determining the Hardware Type/platform:
# uname –m

2) Determining machine processor architecture:
# uname –p

3) Determining FreeBSD release level:
# uname –r
Generally, following command is use to get all info at a time:
# uname -mrs
FreeBSD 5.0-RELEASE i386

4) Determining CPU information such as speed, make etc
# dmesg | grep CPU
CPU: Pentium 4 (1716.41-MHz 686-class CPU)
acpi_cpu0: on acpi0
acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5%

5) Determining real and available memory to FreeBSD:
# dmesg | grep memory
real memory = 201326592 (192 MB)
avail memory = 188555264 (179 MB)

OR

# sysctl -a | grep hw.*mem
# sysctl -a | grep mem


hw.physmem: 194985984
hw.usermem: 167641088
hw.cbb.start_memory: 2281701376

Note systcl has more info, just type to see rest of all info :)
# sysctl -a | less

6) Determining how long a system has been up
# uptime

7) Determining when a system was last rebooted or shutdown
# last -1 reboot
# last -1 shutdown

8) Determining swap file system usage
# swapinfo –k

9) Determining who is logged in and what they are doing
Following all commands can be use. users command displays the list of all logged in users only.
# w
# who
# users

10) Find out when user was last logged in
You can use last command as follows:
# last user-name

(a) To find out user vivek was last logged at what time use last as follows
# last vivek

FreeBSD > Init to reboot or shutdown system

FreeBSD init works different ways. In BSD style, it specifies the kernel security level as follows:
-1: Permanently insecure mode.
0: Insecure mode
1: Secure mode
2: Highly secure mode
3: Network secure mode

You can get current security level (FreeBSD runlevel) using sysctl command:
# sysctl –a | grep kern.securelevel

You can setup new security level in /etc/rc.conf file:
1) Open file in text editor
# vi /etc/rc.conf

2) Add or modify following:
kern_securelevel_enable=”YES” # kernel security level
kern_securelevel=”2″ # range: -1..3 as above

3) Save the changes. Exit and restart FreeBSD.

If init used from command line i.e as a user process, init will emulate AT&T System V UNIX behavior as follows:

0: Halt and turn the power off
1: Go to single-user mode
6: Reboot the machine
c: Block further logins
q: Rescan the /etc/ttys file

1) To halt and turn the power off type:
# init 0

2) You can also use normal halt or shutdown command to shutdown system.

FreeBSD > Sending a Message to Windows Workstation

You can use the utility smbclient (part of samba server) to send a message to windows system from FreeBSD (or even from Linux/Solaris/UNIX).

Genral syntax of to send a message is as follows:
smbclient –M <WINDOW-SYSTEM-NAME> <<EOF
Message
Message

When the message is complete, press Control-D.

1) To send a message “Meeting cancelled” to windows system called joyxp
$ smbclient –M joyxp <<EOF
Meeting cancelled
See you at coffee house in 2 hrs.
–Vivek
EOF

2) With –U you can specify the username.
$ smbclient -M myxp -U VIVEK <<EOF
Meeting cancelled
See you at coffee house in 2 hrs.
EOF

FreeBSD > Sending a Message by E-Mail

E-mail is a way of sending a message between users and administrators from command prompt for shell script. Use mail command as follows

mail -s “Subject” username-name or email-id
email message
email message

..
When the message is complete, press Control-D or type dot character and press return/enter key.

1) To send email to root user to notify printing problem
mail -s “printing problem” root@admin.test.com

Hi Admin

I am having problem with printing can you please check up what is wrong with it. It was working fine untile late evening after that it is not printing from my HP-UX workstation.

Thanks

Joy D.

FreeBSD >Sending a Message to All Users on a Remote UNIX/Linux/FreeBSD System

Traditionally we used rwall command to send a message to every user on a network. Rwall works over insecure network. Instead of that, we can use wall command over ssh as follows, which is more secure and works with almost all UNIX variant.

1) ssh with wall syntax is as follows, after EOF press enter/return key and type message. When the message is complete, type EOF:
$ ssh root@remote-system wall<<EOF
message1
message2


EOF

2) To display message “Kernel is upgraded on this server. System is schedule to reboot in 45-minute time. Please logout and save your work” to ever user on remote FreeBSD system pweb.test.com

$ ssh root@pweb.test.com wall <<EOF
Kernel is upgraded on this server $(hostname).
System is schedule to reboot in 45-minute time.
Please logout and save your work.
Current local data and time is $(date)
EOF

Please note it might prompt for password if ssh-keys not used. Once password supplied it will execute wall command on remote server pweb.test.com. In order to work this remote UNIX/BSD/Linux must have sshd (ssh server) running. Also, notice that we have executed hostname and date command using command substitution feature of shell. This tips also works with Linux and other UNIX like operating system.

FreeBSD >Sending a Message to All Users on a System

You can use the wall command to send a message to every user on a system. General syntax of wall command:
# wall
Message
Message


When the message is complete, press Control-D.

1) To display message “Disk failure system will be down for 30 minute” to all users use wall as follows:
# wall
Disk failure system will be down for 30 minute
–UNIX Admin

2) To display message “Web server under DOS attack, come to IDC # 3” to all WHEEL group member use wall command with –g option as follows:
# wall –g wheel
Web server under DOS attack, come to IDC # 3 to investigate matter further.

FreeBSD > Sending a Message to an Individual User

You can send a message to an individual FreeBSD user logged into system using the write command. Typically writing a short message to an Individual user is main usage.

1) Use write command as follows
$ write user-name
Your message
Your message

When the message is complete, press Control-D

2) Here is an example of a message:
$ write joy
Do not use IRC in C Lab session.

3) Following message will be displayed on joy’s terminal:
Message from root@fbsd.test.com on ttyp0 at 13:24 …
Do not use IRC in C Lab session.

FreeBSD > Displaying System-Specific Messages at Login

Each time a user logs in to a system, the message of the day in the file /etc/motd is displayed. Use /etc/motd to give users information specific to the system, which someone logging in would want to know. Make sure /etc/motd has read permission to others and write permission to root user only:

1) Login as root or become root user using su

2) Use text editor vi to edit /etc/motd
# vi /etc/motd

3) Edit and save the changes. Next time the user logs in she will be able to see changes.

FreeBSD > Becoming super user (su) or enabling su access to user

The superuser is a privileged user with unrestricted access to all files and commands. The superuser has the special UID (user ID) 0. You need to become super user (root) only when tasks need root permissions. Here is how to become super user:

1) At shell prompt type su and press enter key, when prompted for password supply root user password:
$ su
password:
#

2) To exit super user status type exit or press CTRL+D
# exit
$

Please note that if you get an error su: Sorry for normal user account. Then following workaround needed to get rid of this problem:
1) For security, reason FreeBSD only allows su to user if user is member of wheel group. Wheel group is a special group for administration purpose. Add your normal user to this group using pw command using following:
# pw user mod -G wheel

2) So to add user test to group wheel run command as follows:
# pw user mod test -G wheel
# groups test

test wheel

3) Now su will work for test user.

You can disable this behavior complete for all users (not recommended until and unless you trust ALL your users):
1) Open pam configuration file for su using text editor:
# vi /etc/pam.d/su

2) Look for following line and comment it out:
Line:
auth requisite pam_wheel.so no_warn auth_as_self noroot_ok exempt_if_empty
Replace with:
#auth requisite pam_wheel.so no_warn auth_as_self noroot_ok exempt_if_empty

3) Now all users can use su if then knew the root password.

IPFW – описание

2007-03-08 · Posted in Unix FreeBSD

IPFW – это IP-firewall и программа для управления формирования трафика в сети.

КРАТКОЕ ОПИСАНИЕ

ОПИСАНИЕ

ipfw – это пользовательский интерфейс для управления брандмауэром (ipfirewall) и dummynet (фиктивная сеть) – формирования трафика под FreeBSD.

Конфигурация брандмауэра выполняется при помощи списка нумерованных правил. Брандмауэр проверяет по этим правилам каждых входящий и исходящий IP-пакет, пока не будет найдено соответствующее правило. После того, как соответствующее правило найдено, пакеты могут быть введены в брандмауэр в соответствии с правилом повторно в зависимости от характера дейстия, определяемого этим правилом, а также системных установок. Все правила применимы для всех сетевых интерфейсов, так что ответственность системного администратора – записать установки правила так, чтобы пусть проверки был минимальным. Конфигурация всегда включает правило по умолчанию (DEFAULT rule, номер 65535) которое не может быть изменено и которое применяется для всех пакетов. Это правило может либо разрешать все, либо запрещать все в зависимости от конфигурации системного ядра. Если установки включают в себя одно или более правил с сохранением состояния или ограничением опций, то поведение поведение ipfwстановится статичным, т.е. ipfwбудет создавать динамические правила, соответствующие точным параметрам (адреса, порты), соответствующиего пакета до тех пор, пока это соответствие не будет найдено. Эти динамические правила, имеющие ограниченное время жизни проверяются при первом вхождении правила chech-stateили keep-state и обычно используются для открытия брандмауэра по требованию и только для желаемого трафика. Подробнее смотри разделы RULE FORMAT и ПРИМЕРЫ Об инсталляции можно также прочитать здесь.

Все правила, включая и динамические, имеют несколько связанных счетчиков: подсчет пакета, подсчет байт, регистрацию подсчетов, и timestamp – регистрация времени последнего соответствия. Счетчики могут отображаться или сбрасываться командами ipfw.

Правила могут быть добавлены при помощи команды add; удалены индивидуально при помощи команды delete, а также глобально (все сразу) при помощи команды flush (сброс); правила могут быть выведены на экран опционально вместе с содержимым счетчиков, при помощи команд list. В завершение счетчики могут быть обнулены при помощи команд zero или resetlog.

Допускаются следующие команды:

-a – при распечатке показываются значения счетчиков; команда вставки подразумевает эту опцию.

-d – при распечатке в дополнение к статическим выводятся динамические правила.

-е – при распечатке, если указана опция -d, также показывает просроченные динамические правила.

-f – не запрашивать подтверждения для команд, что может вызвать проблемы, если неверно используется, например, сброс. Заметьте, что если нет никакого tty, cвязанного с процессом, то это подразумевается.

-q – во время добавления, обнуления, очистки журналов или сброса не выводить сообщений (подразумевает -f). Эта опция полезна для корректировки правил при выполнении множества команд ipfw в скриптах (например, в sh /etc/rc.firewall’) или при обработке файла, содержащего множество правил ipfw при удаленной сессии. Если выполнен сброс (flush) в нормальном (подробном) режиме, (с конфигурацией ядра по умолчанию), то печатаются сообщения. Поскольку все правила сброшены, сообщения не могут быть доставлены в удаленную сессию. По этой причине удаленный вход будет закрыт, и все остальные правила выполнены не будут. Доступ к консоли должен быть восстановлен.

-t – при распечатке показывать соответствующие timestamp.

-N  – проверять соответствие имен и адресов при выводе.

-s [field] – при распечатке каналов сортировать, согласно одному из четырех счетчиков (подсчитывают и текущие пакеты или байты).

С целью упрощения конфигурирования правила могут быть помещены в файл, который может быть обработан ipfw, как показано в первой строке раздела synopsis. При этом должен быть использован абсолютный путь. Файл будет читаться строка за строкой, и применяться как аргументы для ipfw. Опционально препроцессор может быть указан, используя -p preproc, где pathname должен быть сквозным канальным. Полезные препроцессоры включают в себя cpp и m4. Если preproc не запускается с прямым слэшем (“/”) как его первым символом, выполняется обычный поиск пути. Необходимо соблюдать осторожность с этим в системах, где не все файловые системы (еще) смонтированы к моменту запуска ipfw или же он расположен на файловой системе NFS. Параметр -p, а также следующие за ним (опционально) -D и -U могут также передаваться препроцессору. Это позволяет создать гибкий конфигурационный файл – подобно конфигурированию локального имени хоста – и использовать макросы для централизованного конфигурирования, подобно IP-адресу.

Команды pipes ipfw используются для конфигурирования регулировщика трафика как показано разделах TRAFFIC SHAPER CONFIGURATING, приведенных ниже.

RULE FORMAT

Общий вид формата правил ipfw следующий:

Каждый пакет может быть отфильтрован на основании следующей информации, которая связана с:

Интерфейс приема/передачи (по имени или адресу)
Интерфейс приема/передачи (входящие или исходящие)
IP-адрес источника или получателя (возможна маска)
Протокол (IP. TCP, UDP, ICMP и т. д.)
Порты источника или получателя (список, диапазон или маска)
TCP-флаги
Флаг фрагментации IP
Опции IP
Типы ICMP-пакетов
Идентификаторы пользователей и/или групп в наборе, ассоциированном с этим пакетом

Заметьте, что может быть опасным фильтровать пакеты на основании IP-адреса источника или порта TCP/UDP, потому что они могут быть сравнительно легко подделаны.

prob match_probability

Число с плавающей точкой (от 0 до 1) – указание соответствующей вероятности. Это может быть полезно для ряда приложений типа случайного снижения скорости доставки пакета или (в соответствии с концепцией виртуальной сети – dummynet) для моделирования множественных путей интервала, приводящего к повреждению доставленных пакетов.

Action:

allow – разрешить пакетам, соответствующим правилу; завершает проверку; аналогами являются pass (пропустить), permit (разрешить) и accept (принять).

deny – отбрасывать пакеты, соответствующие данному правилу; прекращает поиск; drop – аналог (синоним) deny.

reject – (Deprecated, осуждаемый) – отбросить пакеты, которые соответствуют данному правилу и отправить ICMP-сообщение, что проверяемый хост недоступен. Завершает проверку.

unreach code – отбрасывает пакет, который соответствует данному правилу и отправляет ICMP-сообщение о недоступности хоста с кодом code, где code число от 0 до 255 или один из следующих псевдонимов (кодовых слов); net (сеть), host (хост), protocol (протокол), port (порт), needfrag (необходим фрагмент), scrfail (сбой источника), net-unknown (сеть неизвестна), host-unknown (хост неизвестен), isolated (изолирован), net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence (старшинство хоста) или precedence-cutoff (старшинство останова); завершает проверку.

reset – только для пакетов tcp; отбрасывает пакеты, которые сответствуют данному правилу и посылают TCP reset (RST) сообщение; завершает проверку.

count – модификация счетчиков для всех пакетов, соответствующих правилу; проверка продолжается со следующего правила.

check-state – проверяет пакет по динамическим правилам; если соответствие обнаружено, поиск прекращается; в противном случае выполняется переход к следующему правилу; eсли check-state правило не обнаружено, динамические правила проверяются по первом правилу с опцией keep-state;

divert port – переадресация пакетов, соответствующих данному правилу на divert граничное окно в порт port; проверка завершается. Подробнее о divert смотри здесь.

tee port – отправка копии пакетов, соответствующих данному правилу, на divert граничное окно в порт port; проверка завершается№; оригинал пакета принимается, но смотри раздел BUGS ниже.

fwd ipaddr [,port] – изменить next-hop (следующий отскок) для соответствующих пактов на IP-адрес ipaddr, который может быть IP-адресом в точечно-десятичной нотации или именем хоста; если IP-адрес ipaddr отсутствует в непосредственно подключенной к хосту сети, то маршрут определяется по локальной таблице маршрутизации соответствующего IP-адреса, использующегося вместо него; если IP-адрес ipaddr локальный, то производится ввод в систему с удаленного хоста и будет перенаправлен в порт port на локальной машине, сохраняя локальный IP-адрес сокета и устанавливая исходный IP-адрес для пакета, который был адресатом; это предназначено для работы с прозрачными прокси-серверами; если IP-адрес ipaddr не является локальным, то номер порта (если указан) игнорируется, и правило применяется к пакетам, уходящим из системы; это также отображает адреса к локальным портам, если пакеты сгенерированы локально; проверка завершается, если есть соответствие этому правилу; если номер порта не задан, то номер порта в пакете используется так, чтобы пакет для порта внешнего хоста Y был отправлен к локальному порту Y; системное ядро должно быть скомпилировано с опцией IPFIREWALL_FORWARD.

pipe pipe_nr – пропустить пакет через dummynet (фиктивную сеть) “pipe” c определенными параметрами – полоса пропускания, задержка и т. д.; cмотри раздел TRAFFIC SHAPER CONFIGURATION; поиск заканчивается, однако если переменная sysctl net.ionet.ip.fw.one_pass не установлена, то пакеты снова проходят через брандмауэр с просмотром следующего правила.

queue queue_nr – пропустить пакет по правилам dummynet “queue” , очередь номер queue_nr (для полосы пропускания, ограниченной с использованием WF2Q).

skipto number – пропустить все последующие правила с номерами, меньшими, чем number; поиск продолжается с первого правила, пронумерованного number или выше.

log [logamount number]

Если ядро было скомпилировано с IPFIREWALL_VERBOSE, то когда пакет, соответствующий данному правилу с ключевым словом log, сообщение будет записано в журнал syslogd cредством LOG_SECURITY; примечание: по умолчанию, они добавляются в файл /var/log/security; см. syslog.conf; если ядро скомпилировано с опцией IPFIREWALL_VERBOSE_LIMIT, то по умолчанию запись в журнал прекратится после числа пакетов, указанных в опции и полученных для этой конкретной цепочки входа и значения переменной net.inet.ip.fw.verbose_limitбудет установлено это число; однако, если используется опция logamount number, будет установлено значение, меньшее, чем net.inet.ip.fw.verbose_limit, а значение 0 снимает ограничение, очищая при этом счетчик пакетов, после чего можно вновь давать возможность регистрации; регистрация через консоль и установка динамического предела выполнятеся при помощи sysctl и основан на MIB переменной net.inet.ip.fw

proto – IP-протоколы, который определяет именем или номером (полный список приведен в файле /etc/protocols); ip или ключевое слово all указывает на соответствие всем протоколам.

src и dst:

any | me | [not] address/mask [ports]

Ключевое слово any указывает на соответствие любому IP-адресу; ключевое слово me указывает на соответствие любому IP-адресу, который присвоен конфигурируемой системе.

address/mask может быть определен следующим образом:

ipno – IP-адрес в точечно-десятичной нотации (192.168.0.2), указывает на конкретный компьютер в сети;

ipno/bits – IP-адрес с маской (длиной сетевой части) в форме 1.2.3.4/24; в этом случае будут подходить все IP-адреса от 1.2.3.0 до 1.2.3.255.

inno:mask – IP-адрес с маской в форме 1.2.3.4:255.255.240.0; в этой записи указывается на соответствие всем IP-адресам от 1.2.0.0 до 1.2.15.255

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

С протоколами TCP и UDP опционально может следовать порт. Порт указывается следующим образом:

{port | port-port | port:mask} [,port [,…]]

Символ “-” указывает на диапазон портов, включая границы. Символ “:” указывает на порт и маску, объявляя соответствие, если номер порта и пакета соответствует порту в правиле, ограничивая битами, которые регулируются маской.

Имя сервиса (из файла /etc/services) может быть использовано вместо значения номера порта. В диапазоне может быть указано только первое значение и длина списка портов, ограниченная IP_FW_MAX_PORTS (как определено в /usr/src/sys/netibet/ip_fw.h). Обратный слэш (“\”) может быть использован для выхода поле символа черточки (“-“) в названии сервиса, например:

ipfw add count tcp from any ftp\\-data-ftp to any

Фрагментированные пакеты, которые имеют ненулевое смещение (такие как, например, первый фрагмент), никогда не будут соответствовать правилу, в котором указана одна или более установок порта. См. опции фрагментов для более подробной информации о соответствии фрагментированных пакетов.

interface-spec

Допускаются следующие комбинации спецификации интерфейсов:

in – только для входящих пакетов;

out – только для исходящих пакетов;

via ifx – пакет должен быть пропущен через интерфейс ifx;

via if* – пакет должен быть пропущен через интерфейс ifX, где X – любой номер устройства;

via ipno – пакет должен быть пропущен через интерфейс, IP-address которого ipno.

Указание ключевого слова via всегда заставляет проверять интерфейс. Если указаны ключевые слова recv или xmit, то это тоже заставляет всегда проверить интерфейс. Определяя передающий и принимающий интерфейсы, есть возможность выбрать пакеты, основанные как на том, так и на другом интерфейсе, например:

ipfw add 100 deny ip from any to any out recv ed0 xmit ed1

Интерфейс recv может быть проверен или на входящие, или на исходящие пакеты, в то время как интерфейс xmit может быть проверен только на исходящие пакеты. Так out требуется (и в недопустимых случаях) всякий раз, когда используется xmit. Сочетание via вместе с xmit или с recv недопустимо.

ОПЦИИ

keep-state

После соответствия firewall создаст динамическое правило, поведение которого по умолчанию должно соответствовать двунаправленному трафику между источником и получателем; IP/порт использует тот же самый протокол; правило имеет ограниченный срок действия (определяемый набором переменных sysctl), время действия обновляется при обнаружении пакета, соответствующего правилу.

limit {src-addr | src-port | dst-addr | dst-port} N

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

bridged

Cooтветствует только bridged-пакетам. Может быть полезно для многоадресного и широковещательного трафика, который в противном случае прошел бы через брандмауэр дважды: первый раз в течение соединения, а второй раз – в момент доставки пакета локальному стеку. Кроме того, будут возникать проблемы при использовании средства pipe, так как один и тот же пакет будет доставлен дважды применительно к условиям ширины полосы пропускания, занятия очереди, а также для счетчиков.

frag

Соответствует правилу, если пакет фрагментирован и если это не первый фрагмент датаграммы; fragне может быть использован как в сочетании или с другими tcp-флагами, так и указанием портов TCP/UDP.

ipoptions spec

Соответствует, если заголовок IP-пакета содержит перечисленный через запятую список опций, указанный в spec. Поддерживаются следующие опции: ssrr (strict source route, жесткая маршрутизация от источника), lsrr (loose source route, свободная маршрутизація от источника), rr (record packet route, запись маршрута пакета) и ts (timestamp, отметка о времени). Отсутствие какой-либо опции может быть обозначено знаком ‘!”.

tcpoptions spec

Соответствует, если tcp-заголовок содержит опции, перечисленные в списке и разделенные запятыми. Поддерживаются следующие опции: mss (maximum segment size, максимальный размер сегмента), window (tcp window advertisement, рекламное окно TCP), sack (селективный опрос), ts (rfc1323, отметка о времени) и cc (rfc1644 t/tcp счетчик соединений). Отсутствие какой-либо опции может быть обозначено знаком ‘!”.

established

Только для TCP-пакетов. Соответствует пакетам, которые имеют битовые установки RST и ACK.

setup

Только для TCP-пакетов. Соответствует пакетам, которые имеют битовую установку SYN, но не имеют установки ACK.

tcpflags spec

Только для TCP-пакетов. Соответствует, если заголовок TCP-пакета содержит указанные в списке (разделенные запятыми) флаги spec. Поддерживаются следующие TCP-флаги: fin, syn, rst, psh, ack и urg. Отсутствие какой-либо опции может быть обозначено знаком ‘!”. Правило, содержащее TCP-флаги, может никогда не соответствовать фрагментированным пакетам, которые имеют ненулевое смещение. Смотрите опции фрагментации для детальной информации о соответствии фрагментированных пакетов.

icmptypes types

Только для пакетов ICMP. Соответствует, если тип ICMP-пакета соответствует типу, указанному в списке spec. Список может указывать как на любую комбинацию диапазонов, так и на индивидуальный тип, разделенный запятыми. Поддерживаются следующие ICMP-типы: echo reply (0) – ответное эхо, destination unreachable (3) – адресат недостижим, source quench (4), redirect (5) – перенаправляющий, echo request (8) – запрос эха, router advertisement (11) – реклама (объявление о себе) маршрутизатора, IP header bad (12) – повреждение заголовка IP, timestamp request (15) – запрос о метке времени, information reply (16) – ответная информация, address mask request (17) – запрос адресной маски, address mask reply (18) – ответ на запрос об адресной маске.

uid user

Указывает на соответствие всем пакетам TCP или UDP отправленным или принятым пользователем user. user может указывать на соответсвие имени пользователю или его идентификационному номеру.

gid group

Указывает на соответствие всем пакетам TCP или UDP, посланным или принятым группой group. group может соответствовать имени группы или ее идентификационному номеру.

TRAFFIC SHAPER CONFIGURATION (КОНФИГУРИРОВАНИЕ РЕГУЛИРОВЩИКА ТРАФИКА)

ipfw также является пользовательским интерфейсом для регулировщика трафика dummynet. Регулировщик трафика функционирует путем разделения пакетов в потоки, согласно маске, заданной пользователем, на основании различных полей в заголовке пакета IP. Пакеты, принадлежащие одному и тому же потоку, в этом случае передаются двум различным объектам, называемым каналом (pipe) или очередью (queue).

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

queue (очередь) – это пользовательская абстракция, реализующая политику WF2Q+. Очередь ассоциируется с каждым потоком определенного приоритета и ссылается на канал. Тогда все потоки, связанные с тем же самым каналом, отмечены по параметрам, заданным для этого канала, согласно политике WF2Q+.

Формат конфигурации pipe следующий:

pipe number config [bw bandwidth | device] [delay ms-delay] [queue {slots | size}] [plr loss_probability] [mask mask_specifier] [buckets hash-table-size] [red | gred w_q/min_th/max_p]

Формат конфигурации очереди ipfw следующий:

queue number config [pipe pipe_nr] [weight weight] [queue {slots | size] [plr loss_probability] [mask mask_specifier>] [buckets hash-table-size] [red | gred w_q/min_th/max_th/max_p]

Для конфиругирования канала (pipe) могут использоваться следующие параметры:

bw brandwidth | device

bandwidth – ширина полосы пропускания, указанная в {K | M}{bit/s | Bytes/s}.

ВНИМАНИЕ!

Следует внимательно следить за регистром символов. Следующий фрагмент кода объясняет все:

ip (*end == ‘B’ || !strncmp(end, “by”, 2)) pipe.bandwidth*=8

Отсюда видно, что значение имеют буквы “by”

Значение 0 (по умолчанию) указывает на неограниченную полосы пропускания. Непосредственно после наименования должен следовать номер, как в примере:

ipfw pipe 1 config bw 300KBit/s queue 50Kbytes

Если вместо численного значения ширины полосы пропускания указано имя-устройства (device), то используется таймер, которым снабжено данное устройство. В настоящее время эту возможность поддерживает только интерфейс PPP.

delay ms-delay

Задержка при передаче, выраженная в миллисекундах. Значение округляется до следующего такта системного таймера (типично 10 мс, но это хорошая практика, которую выполняет системное ядро с параметром HZ=1000, но это значение может быть уменьшено до 1 мс или даже меньше). Значение по умолчанию 0, что означает отсутствие задержки.

queue {slots | size Kbytes}

Размер очереди в слотах или килобайтах. Значение по умолчанию 50 слотов, что соответствует типичному значению очереди для сетевой карты Ethernet. Причем для малой скорости соединения необходимо сохранить малый размер очереди, чтобы на трафик можно было воздействовать с существенной задержкой. Так максимальный размер Ethernet-пакета – 1500 байт – среднее 600 Кбит или 20 сек очереди на канале 30 Kбит/с. Даже худший результат получается, если пакеты приходят от интерфейса с большим значением MTU, таким как интерфейс закольцовывания с размером пакета 16 K.

plr packet-loss-rate

Величина потерь пакетов. Аргумент packet-loss-rate это десятичное число от 0 до 1, где 0 обозначает отсутствие потерь, а 1 – 100% потерь; внутреннее представление величины потерь пакетов представлено 31 битом.

mask mask-specifier

dummynet предоставляет возможность создания очередей в потоке. Идентификатор потока создается маскированием IP-адресов, портов и типов протокола при установке параметров канала (pipe). Пакеты с одним и тем же идентификатором после маскирования относятся к той же самой очереди. Маска располагает комбинацией следующих спецификаторов: dst-ip mask, dst-port mask, src-port mask, proto mask, или все вместе, где последние означают все биты во всех полях являются значимыми. Когда используется в рамках конфигурации pipe, то каждому потоку назначается скорость, равная скорости канала. Когда используется в рамках конфигурации очереди (queue), то каждому потоку назначается вес, равный весу очереди и всех потоков, претендующих на ту же самую полосу пропускания, доли канала, пропорционально весу.

buckets hash-table-size

Этот параметр указывает на размер хэш-таблицы, использующейcя для сохранения переменных очереди. По умолчанию 64 управляемых sysctl переменной net.inet.ip.dumynet.hash_size; допускается диапазон от 16 до 1024.

pipe pipe_nr

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

weight weight

Определяет вес, который нужно использовать для потоков, соответствующих этой очереди. Значение weight должнj быть в диапазоне 1 … 100, и значения по умолчанию 1.

red | gred w_q/min_th/max_th/max_p

Выполняет алгоритм управления очередью RED. w_q и max_p – десятичное дробное число в диапазоне от 0 до 1 (0 не допускается), в то время как min_th и max_th – целые числа, определяющие пороги для управления очередью, вычисленные в байтах, если очередь была определена в байтах, в противном случае в слотах. dummynet поддерживает также “вежливый” (gentle) вариант – gred. Подробнее смотрите здесь. 3 переменные sysctl могут быть использованы для управлением поведением RED.

net.inet.ip.dummynet.red_lookup_depth – специфицирует точность вычисления среднего значения очереди, когда соединение простаивает (по умолчанию 256, должно быть больше 0);

net.ip.dummynet.red_avg_pkt_size указывает на ожидаемый размер пакета (по умолчанию 512, должно быть больше нуля);

net.inet.ip.dummynet.red_max_pkt_size – специфицирует ожидаемый максимальный размер пакета. Используется только в том случае, если переменные очереди выражены в байтах. По умолчанию 1500, должно быть больше 0.

CHECK-LIST

Здесь приведены некоторые важные моменты, рассматриваемые при составлении правил:

Запомните, что фильтр проверяет оба пакета – и входящие, и исходящие. Большинство соединений нуждаются в пакетах, проходящих в обоих направлениях.
Не забудьте очень тщательно проверять очередь. Хорошая идея – постоянно быть около консоли сервера при выполнении этого теста. Если это невозможно, используйте скрипт /usr/share/examples/ipfw/change_rules_sh, который восстанавливает предыдущее состояние.
Не забудьте закольцовывающий интерфейс
Имеется один пакет вида, который брандмауэр всегда будет сбрасывать, который является фрагментом с TCP-пакета со смещенным фрагментом пакета. Этот пакет допустим, но только он часто используется для обхода брандмауэра. Когда регистрация пакетов включена, эти пакеты сообщаются об исключении правилом -1.
если вы войдете по сети, загружая при этом

kld(4)

, установка

ipfw

будет не такой простой, как вам думалось. Pекомендeтся следующая командная строка:

kldload /modules/ipfw.ko && \

ipfw add 32000 allow ip from any to any

По той же самой строке:

ipfw flush

В подобном окружении это не очень хорошая идея.

Список правил фильтра

ipfw

не может изменяться, если системная норма безопасности установлена в 3 или выше.

ОТКЛОНЕНИЕ ПАКЕТА

Граница socket divert (4) определяет порт, который будет принимать все пакеты, перенаправляемые в этот порт. Если нет сокета – границы порта назначения, или если ядро не было скомпилировано с поддержкой сокета переадресовки, пакеты пропадают.

ПЕРЕМЕННЫЕ SYSCTL

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

net.inet.ip.fw.debug: 1 Управляет отладочными сообщениями, генерируемыми ipfw.

net.inet.ip.fw.one_pass: 1 Когда установлено, пакет, выходящий из потока dummynet, не проходит через брандмауэр повторно, В противном случае, после обработки канала пакет повторно вводится в брандмауэр по следующему правилу.

net.inet.ip.fw.verbose: 1 Разрешены подробные сообщения.

net.inet.ip.fw.enable: 1 Брандмауэр включен. Установка значения этой переменной в 0 запускает машину без брандмауэра, даже если при компиляции брандмауэр включен.

net.inet.ip.fw.verbose_limit: 0 Значение, ограничивающее число подробных сообщений, генерируемых брандмауэром.

net.inet.ip.fw.dyn_buckets: 256

net.inet.ip.fw.curr_dyn_buckets: 256

Конфигурация и текущее значение хешированной таблицы, используемой для хранения динамических правил. Это должно быть 2. Таблица может быть изменена только если она пустая, так что изменяя ее “на лету”, Вы вероятно должны будете сбросить ее на жесткий диск и перезагрузить установки правил.

net.inet.ip.fw.dyn_count: 3 Текущее число динамических правил (только на чтение).

net.inrt.ip.fw.dyn_ack_lifetime: 300

net.inrt.ip.fw.dyn_syn_lifetime: 20

net.inrt.ip.fw.dyn_fin_lifetime: 1

net.inrt.ip.fw.dyn_rst_lifetime: 1

net.inrt.ip.fw.dyn_rst_lifetime: 5

net.inrt.ip.fw.dyn_short_lifetime: 30

Эти переменные управляют временем жизни в секундах динамических правил. SYN заменяется время жизни сохраняется коротким, затем увеличен, после оба SYN были замечены, затем уменьшены снова в течение конечной FIN когда RST.

Установка Postfix SMTP mail server, POP3 сервер (popper) и Каspersky Mail Server

2007-03-08 · Posted in Unix FreeBSD

Установка Postfix SMTP mail server, POP3 сервер (popper) и Каspersky Mail Server

(c) by Lucky
Оригинал статьи:

В этой мане я попытаюсь изложить как настроить на базе свежеустановленного маршрутизатора почтовый POP3/SMTP сервер с антвирусом касперкого.

Нам понадобятся:

1) Исходники Postfix версии 2.0.16. Качаем с http://www.postfix.org/;

2) Всем известный POP3-сервер popper. Качаем из портов.

3) Антиврус Касперского. Покупаем у официальных дилеров в регионе.

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

Установка popper

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

# pkg_add qpopper-4.0.5.tgz

Правим /etc/inetd.conf:

# cd /etc

# ee inetd.conf

pop3 stream tcp nowait root /usr/local/libexec/qpopper qpopper -s

И, перезапустив inetd, проверим что inetd "слушает" 110 порт:

# killall -HUP inetd

# sockstat | grep 110

Если на файерволе открыт 110 порт, результатом должно быть примерно следующее:

root        inetd        77        6        tcp4         *:110        *.*

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

/sbin/ipfw -q add pass tcp from any to any 25,110

/sbin/ipfw -q add pass tcp from any 25,110 to any

Поверяем telnet'ом:

# telnet

telnet> open localhost 110

Connected to localhost.

Escape character is '^]'.

+OK Qpopper (version 4.0.5) at your_domain.ru starting. <29992.1089701756@your_domain.ru>

user <user_name>

+OK Password required for <user_name>.

pass <user_password>

+OK user <user_name> has 0 visible messages (0 hidden) in 0 octets.

quit

+OK Pop server at your_domain.ru signing off.

Connection closed by foreign host.

На этом устновка POP3-сервера закочена.

Установка и настройка postfix

Postfix достаточно быстрый, надежный, и гибко конфигурируемый сервер. Все остальные его плюсы и минусы могут быть найдены в интернете. Например, на сайте opennet.ru. Я выбрал его потому, что sendmail настроенный с касперским, все ж частично пропускал вирусы.

Сначала необходимо добавить соответствующих пользователя и группу в group и master.passwd

# ee group

postfix:*:12345:postfix

postdrop:*:12346:postfix

# ee master.password

postfix:*:12345:12345::0:0:postfix daemon:/noexistent:/sbin/nologin

# vipw

:wq

Далее, разворачиваем исходники:

# tar zxvf postfix-2.0.16.tar.gz

# cd ./postfix-2.0.16

# make

# make install

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

install_root: [/]

temp_dir: [/usr/local/src/postfix-2.0.16]

config_directory: [/etc/postfix]

daemon_directory: [/usr/libexex/postfix]

command_directory: [/usr/sbin]

queue_directory: [/var/spool/postfix]

sendmail_path: [/usr/sbin/sendmail]

newaliases_path: [/usr/bin/newaliases]

mailq_path: [/usr/bin/mailq]

mail_owner: [postfix]

setgid_group: [postdrop]

manpage_directory: [/usr/local/man]

sample_directory: [/etc/postfix]

readme_directory: [no]

Правим rc.conf:

sendmail_enable="NONE"

Проверяем наличие sendmail:

top | grep senmail

Если получен результат, т.е. sendmail присутствует в процессах:

killall sendmail

Правим main.cf – основной конфигурационный файл postfix:

# cd /etc/postfix

# ee main.cf

Далее будет приведены строки, и необходимые для них комментарии, на которые стоит обратить особое внимание. Готовый файл можно взять здесь.

myhostname = relay.your_host.ru

# запись MX для всшего домена. Необходимо помнить, что эта запись должна быть у вашего провайдера. Если вы сами держите зону DNS, то она соответственно должна присутствовать в вашей зоне DNS.

mydomain = your_domain.ru

# запись для домена

inet_interfaces = 192.168.0.254, localhost, 123.123.123.10

#здесь указаны интерфейсы, котореы будут "слушать" 25 порт, т.е внешняя, внутреняя и localhost. Можно также указать слово "all".

mydestination = $myhostname, localhost, $mydomain

# параметр, определяющий имена доменов для получения почты. Если нужно использовать почту для нескольких доменов, не нужно указывать их здесь. Для этого существует специальный файл. (domain)

unknown_local_recipient_reject_code = 550

#Код ошибки для неизветных локальных получателей почты.

mynetworks = 192.168.0.0/24, 127.0.0.0/8, 123.123.123.10

# параметр, определяющий каким сетям разрешно релэить через postfix.

virtual_alias_maps = hash:/etc/postfix/virtual

virtual_alias_domains = /etc/postfix/domain

#Хэш для виртуальных алиасов и поддержки нескольких доменов при необходимости.

smtpd_recipient_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/client_access, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_destination,reject_rbl_client list.dsbl.org, reject_rbl_client relays.ordb.org, reject_rbl_client dynablock.wirehub.net, reject_rbl_client

blackholes.wirehub.net, reject_rbl_client dnsbl.njabl.org

# параметр, опредялющий разрешения для получателей. Именно здесь можно прицепить различные фильтры, такие как проверка recepient black list и т.д.

header_checks = regexp:/etc/postfix/header_checks

body_checks = regexp:/etc/postfix/body_checks

#также еще один важный момент, на котором бы хотелось остановиться, это параметры headers_check и body_cheks. Если вкупе с postfix, поставить какой-нибудь спам-фильтр, то это даст возможость фильтровать входящую почту. Файлы headers_check и body_cheks могут быть взять отсюда или отсюда и отсюда.

smtpd_banner = ESMTP Mail Server v1.0 (Build 2195)

# поменяем вывеску, для повышения секьюрности.

alias_maps = hash:/etc/postfix/aliases

# база с алиасами

# в качестве меры безопасности, лучше использовать алиасы. Далее будет показано, как это сделать.

Сохраняем main.cf и переходим к созданию дополнительных конфигурационных файлов.

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

# ee client_access

123.123.132.10 OK

В этом случае для любого клиента с IP 123.123.132.10 этот релей будет окрытым. Не забудем сделать хэш:

# makemap hash client_access.db < client_access

После этого создаем файл virtual.db. Это делается для повышения безопасности. Совсем правильно будет поставить postfix в jail, если вы не собираетесь предоставлять услуги как провайдер. В одной из ман я расскажу как сделать jail. Насколько я в курсе, jail есть только во FreeBSD, и это еще один плюс в выбор этой ОС в качестве маршрутизатора.

# cd /etc/postfix

# ee virtual

popuser1        name_user1@your_domain.ru

popuser2        name_user2@your_domain.ru

# makemap hash        virtual.db < virtual

Естественно, что пользователи popuser1 и popuser2 должын быть в master.passwd в группе mail, например:

popuser1:sEcRTk2kDnF1E:1000:6::0:0:popuser1:/nonexistent:/sbin/nologin

Если нужно принимать почту на несколько доменов, то раскомментируем нужную строку в main.cf и создадим файл domain, в котором столбиком пропишем все те домены, для которых получаем почту. Необходимо также помнить, что для всех этих доменов должна быть соответствующая MX запись в DNS.

# ee domain

your_domain.ru

another.your_domain.ru

Соответственно, можно указать пользователей различных доменов в virtual

popuser1        name_user1@your_domain.ru

popuser2        name_user2@another.your_domain.ru

# makemap hash virtual.db < virtual

Еще один важный момент, на котором нужно остановиться – это возможность отправки почты пользователями, находящимися ВНЕ вашей локальной сети, так как по умолчанию postfix им позволить отправлять только пользователям вашей сети. Итак, раскомментируем соответствующую строку в main.cf и создадим файл:

# ee sender_access

user1@your_domain.ru        OK

Часто приходилось видеть, как вирусописатели любят использовать e-mail admin@ для своих гнусных целей, поэтому неплохо было бы запретить хождение с этого адреса:

admin@your_domain.ru        REJECT

Не забываем создать хэш:

# makemap hash sender_access.db < sender_access

Не забудем подправить /etc/postfix/aliases и создать хэш, чтобы была возможномть получать, почту на root, postmaster, etc.

На этом устновка postfix без касперского закончена, проверяем, что все изменения корректны:

# postfix check

Если все в порядке, пробуем запустить:

# postfix start

# sockstat |grep :25

postfix smtpd 31082 6 tcp4 192.168.1.250:25 *:*

postfix smtpd 31082 7 tcp4 127.0.0.1:25 *:*

postfix smtpd 31082 8 tcp4 123.123.123.10:25 *:*

root master 226 11 tcp4 192.168.1.250:25 *:*

root master 226 12 tcp4 127.0.0.1:25 *:*

root master 226 13 tcp4 123.123.123.10:25 *:*

Должны получить демон, слущающий 25 порт. Проверяем telnet'ом:

# telnet

telnet> open relay.your_domain.ru 25

Trying 123.123.123.10…

Connected to your_domain.ru.

Escape character is '^]'.

220 ESMTP Mail Server v1.0 (Build 2195)

mail from: info@lucky.ymrc.ru

250 Ok

rcpt to: postmaster@your_domain.ru

250 Ok

data

354 End data with .

.

250 Ok: queued as E445AA58B

На это установка и настройка POP3/SMTP сервера закончена. Осталось настроить только почтовые клиенты.

Шаг номер три: прикручиваем Касперского

Для начала нужно раздобыть готовый антвивирус с ключом как package. У меня это был kav4mailservers-freebsd-4.x-5.0.2.1.tgz с лицензией на год.

Добавляем package:

# pkg_add kav4mailservers-freebsd-4.x-5.0.2.1.tgz

На данном этпае нужно лишь быть внимательным с указанием путей. Все изменения будут вноситься автоматически. Единственное, что пришлось сделать после уставновки Каспеского – залить антивирусные базы с помощью /usr/local/share/kav/bin/kavupdater и прописать пользователей, для которых нужно будет проверять входящую почту в /var/db/kav/5.0/kav4mailservers/keys.

После этого необходимо запустить бинарник /usr/local/share/kav/bin/aveserver и проверить работу антивирусного фильтра. У меня для этих целей была тулзовниа delpart.com, которая по Enter уничтожает партиции жесткого диска.

Открываем почтовго клиента и посылаем письмо на свой собственный ящик c каким либо заботливо припасенным трояном. Получаем ответ:

Alarm! Virus found in message to you!

Для себя я еще также сделал автоматическое обновление антивирусных баз в кроне:

1 8 * * * root /usr/local/share/kav/bin/kavupdater

Не забудье в пути cron'а указать путь к wget:

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin

На этом установка касперского закончена.

mpd и ipfw – проблема

2007-03-08 · Posted in Unix FreeBSD

Стоит FreeBSD 5.2.1 на ней установлен mpd (для клиентов windows xp).
если в ipfw разрешено all from any to any, то клиенты нормально коннектятся.
а если разрешено только tcp from any to me 1723 то не пашет.

{my_addr} – IP адрес, на который происходить соединение
{iface} – внешний интерфейс, на который происходит соединение