1 (18.02.2013 04:16:18 отредактировано Liber)

Всем привет! Я начинающий пользователь linux. Так уж сложились обтоятельства, что мне приходится разбираться с наладкой маршрутизатора под управлением Debian 6. Понятное дело, по ходу возникает немало вопросов. Нижеприведенные вопросы я уже размещал на ЛОРе, но с ответами пока как-то негусто. Я подумал: может тут мне смогут помочь?..


Настраиваю роутер с NAT. Вроде даже все завелось. Но в том, что касается настройки iptables поначитался всякого - и манов, и статей, в голове каша. Не уверен, что все верно понимаю.

Есть пара вопросов. Если вдруг кому не жаль времени поглядеть - буду благодарен за ответы.

Схема сети следующая: домашние машины => коммутатор => маршрутизатор под управлением Debian с 2 ethernet интерфейсами => внутренняя сеть прова (с различными сервисами, включая DC, игровые серверы и т.п.) => IPsec VPN для доступа в интернет.

Правила настраиваются скриптом '/etc/network/if-pre-up.d/NAT'. Представляет собой компиляцию материалов из нескольких нагугленных статей, плюс некоторые личные дополнения:

#!/bin/bash

# Устанавливаем переменные окружения:
LAN="eth1"
WAN="eth0"
VPN="ppp0"
LAN_IP_RANGE="192.168.110.0/24"
LAN_IP="192.168.110.1"
WAN_IP="172.20.85.281"
LIBER_IP="192.168.110.100"
SNAKE_IP="192.168.110.101"
SSH_PORT="22828"

# Включаем форвардинг пакетов и подгружаем модули:
echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# Очищаем существующие таблицы правил:
iptables --flush
iptables --delete-chain
iptables --table nat --flush
iptables --table nat --delete-chain
iptables --table mangle --flush
iptables --table mangle --delete-chain

# Устанавливаем политики запрета всего:
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

# Разрешаем локальный траффик для loopback:
iptables --append INPUT --in-interface lo --jump ACCEPT
iptables --append OUTPUT --out-interface lo --jump ACCEPT
iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT

# Явно разрешаем доступ к SSH из внутренней сети:
iptables --append INPUT --protocol tcp --in-interface $LAN --destination-port $SSH_PORT --jump ACCEPT

# Явно разрешаем пинг:
iptables --append INPUT --protocol icmp --icmp-type 8 --jump ACCEPT

# Запрещаем все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса:
iptables --append INPUT --match state --state INVALID --jump DROP
iptables --append FORWARD --match state --state INVALID --jump DROP

# Приводит к связыванию системных ресурсов, так что реальный обмен данными становится невозможным, запрещаем:
iptables --append INPUT --protocol tcp ! --syn --match state --state NEW --jump DROP
iptables --append OUTPUT --protocol tcp ! --syn --match state --state NEW --jump DROP

# Разрешаем траффик для внутренней сети:
iptables --append INPUT --in-interface $LAN --jump ACCEPT
iptables --append OUTPUT --out-interface $LAN --jump ACCEPT

# Разрешаем входящие пакеты уже инициированных соединений, а также дочерние от них:
iptables --append INPUT --protocol all --match state --state ESTABLISHED,RELATED --jump ACCEPT
# Разрешаем исходящие пакеты новых, а так же уже инициированных и их дочерних соединений:
iptables --append OUTPUT --protocol all --match state --state NEW,ESTABLISHED,RELATED --jump ACCEPT
# Разрешаем форвардинг для новых, а так же уже инициированных и их дочерних соединений:
iptables --append FORWARD --protocol all --match state --state NEW,ESTABLISHED,RELATED --jump ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU:
iptables --insert FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

# Разрешаем доступ из внутренней сети наружу:
iptables --append FORWARD --in-interface $LAN --out-interface $WAN --jump ACCEPT
iptables --append FORWARD --in-interface $LAN --out-interface $VPN --jump ACCEPT

# Разрешаем доступ снаружи во внутреннюю сеть:
iptables --append FORWARD --in-interface $WAN --out-interface $LAN --jump ACCEPT
iptables --append FORWARD --in-interface $VPN --out-interface $LAN --jump ACCEPT

# NAT-маскарадинг:
iptables --table nat --append POSTROUTING --out-interface $WAN --source $LAN_IP_RANGE --jump MASQUERADE
iptables --table nat --append POSTROUTING --out-interface $VPN --source $LAN_IP_RANGE --jump MASQUERADE


################
#
# Проброс портов
#
# Правила для каждого проброса:
# 1 - Проброс внешнего порта на адрес в LAN
# 2 - Перенаправление пакетов через NAT при обращении LAN-клиента к LAN-службе по ее WAN адресу
# 3 - На случай, если клиент - сам маршрутизатор
# 4 - Разрешающее правило для форвардинга из WAN в LAN

# Greylink DC++
iptables --table nat --append PREROUTING \
        --protocol tcp --destination $WAN_IP --dport 22612 --jump DNAT --to-destination $LIBER_IP

iptables --table nat ---append POSTROUTING \
        --protocol tcp --destination $LAN_IP --dport 22612 --jump SNAT --to-source $LIBER_IP

iptables --table nat --append OUTPUT \
        --protocol tcp --destination $WAN_IP --dport 22612 --jump DNAT --to-destination $LIBER_IP

iptables --insert FORWARD 1 \
        --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \
        --destination $LIBER_IP --dport 22612 --jump ACCEPT

iptables --table nat --append PREROUTING \
        --protocol tcp --destination $WAN_IP --dport 22682 --jump DNAT --to-destination $LIBER_IP

iptables --table nat ---append POSTROUTING \
        --protocol tcp --destination $LAN_IP --dport 22682 --jump SNAT --to-source $LIBER_IP

iptables --table nat --append OUTPUT \
        --protocol tcp --destination $WAN_IP --dport 22682 --jump DNAT --to-destination $LIBER_IP

iptables --insert FORWARD 1 \
        --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \
        --destination $LIBER_IP --dport 22682 --jump ACCEPT

Собственно вопросы:

1) Если все будет работать и так, то подгрузку модулей (modprobe ...) из скрипта лучше убрать?

2) Правильно ли я понимаю, что политики (iptables --policy) представляют собой нечто вроде глобальных правил по умолчанию? Т.е. если не найдено правило, условия которого соответствуют параметрам IP пакета, то выполняются действия, заданные политиками. Так?

3) Правило: iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT наверное, лучше заменить на DROP? Т.е. не будет ли лучшим ответом на такой пакет покерфейс и ледяное молчание?

4) Что касается раздела «Разрешаем доступ снаружи во внутреннюю сеть». При текущих правилах получается такая картина:

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

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

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

iptables --table nat ---append POSTROUTING \
        --protocol tcp --destination $LAN_IP --dport 22612 --jump SNAT --to-source $LIBER_IP

6) Еще по пробросу... Сейчас выглядит довольно неуклюже из-за обилия правил (по правилу для каждого порта). Я в курсе о расширении multiport, но сам его применять не стал, опасаясь напортачить в синтаксисе. Может быть, кто-нибудь сможет привести пример, как добавить порты?

7) И снова о пробросе: допустимо ли применение списка протоколов? Т.е. можно ли указать опцию --protocol tcp,udp и завязать оба протокола на один порт (для того же DC)?

8) Как я понимаю, проброс портов на VPN интерфейсе нужно делать отдельно (для торрент-клиента, например или того же DC++ при подключении к интернет-хабам). У меня сейчас динамический IP, можно ли указать в правиле --in-interface вместо --destination (т.е. название интерфейса вместо его IP)?

P.S. Ну и в целом буду благодарен за общие поправки по перечисленным правилам и указания на корявости и упущения, которые, уверен, я тут наляпал.

Большое спасибо!

2

Что, неужели не к чему придраться? Ни за что не поверю...  ac

3 (18.02.2013 10:20:52 отредактировано Kettler)

Liber пишет:

Что, неужели не к чему придраться? Ни за что не поверю...  ac

Вам что тут техподдержка платного продукта? Придут ребята глянут что и как.

Ищу дополнительный заработок (удалёнка).
Пьянка без секса – признак алкоголизма.

4

Раз делаете

# Разрешаем доступ из внутренней сети наружу:
iptables --append FORWARD --in-interface $LAN --out-interface $WAN --jump ACCEPT
iptables --append FORWARD --in-interface $LAN --out-interface $VPN --jump ACCEPT

# Разрешаем доступ снаружи во внутреннюю сеть:
iptables --append FORWARD --in-interface $WAN --out-interface $LAN --jump ACCEPT
iptables --append FORWARD --in-interface $VPN --out-interface $LAN --jump ACCEPT

Тогда уш проще

iptables -P FORWARD ACCEPT

При выше изложенных правилах  зачем это

iptables --insert FORWARD 1 \
        --protocol tcp --match tcp --in-interface $WAN --out-interface $LAN \
        --destination $LIBER_IP --dport 22682 --jump ACCEPT
Ищу дополнительный заработок (удалёнка).
Пьянка без секса – признак алкоголизма.

5 (18.02.2013 10:33:16 отредактировано Kettler)

Проброс делается в PREROUTING и не как в POSTROUTING
То что взяли за основу чужие конфиги это хорошо для понимания.
Но ещё лучше тогда почитать man.

Ищу дополнительный заработок (удалёнка).
Пьянка без секса – признак алкоголизма.

6 (18.02.2013 15:53:13 отредактировано Liber)

Kettler пишет:

Вам что тут техподдержка платного продукта? Придут ребята глянут что и как.

Да нет конечно. Не терпится просто уже маленько. Просмотров много, а ответов нет. На ЛОРе вон вообще никто ничего отвечать не стал (
Спасибо, что уделили время!

Kettler пишет:

Тогда уш проще

iptables -P FORWARD ACCEPT

Вот у меня по этому поводу сомнения (п.4 первого поста). Наверное, все-таки лучше для каждого проброшенного порта разрешающие правила добавлять, а не так глобально?

Kettler пишет:

При выше изложенных правилах  зачем это

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

Kettler пишет:

Проброс делается в PREROUTING и не как в POSTROUTING

Если честно, не очень я этот момент понимаю... То есть, неправильно в статейке было написано, и проброс сейчас не работает? Похоже, тут мне еще основательно повникать придется...

Еще раз спасибо!

7

Еще, если не осложнит... можно живой пример синтаксиса расширения multiport?

8

Liber пишет:

1) Если все будет работать и так, то подгрузку модулей (modprobe ...) из скрипта лучше убрать?

Особой разницы нет, только если срипт при загрузе не стартует, а используется iptables-save/restore.

Liber пишет:

3) Правило: iptables --append INPUT ! --in-interface lo --destination 127.0.0.0/8 --jump REJECT наверное, лучше заменить на DROP? Т.е. не будет ли лучшим ответом на такой пакет покерфейс и ледяное молчание?


Если и так политики в DROP смысла нет в этом правиле.

Liber пишет:

Сейчас выглядит довольно неуклюже из-за обилия правил (по правилу для каждого порта).

Нормально всё выглядит.

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

9

zenon пишет:

Особой разницы нет, только если срипт при загрузе не стартует, а используется iptables-save/restore.

Ясно.

zenon пишет:

Если и так политики в DROP смысла нет в этом правиле.

Понятно. Я просто собирал наиболее интересные правила из разных источников. В том числе, чтобы:
а) не забыть
б) на случай дальнейшего изменения политик/других правил

Хотя это, конечно, лишнее правило, с которым нужно сверяться... Лучше пока его закомментировать, да?

Спасибо!

10

zenon пишет:

Нормально всё выглядит.

То есть можно не заморачиваться? Если сделать список портов через запятую, разве не красивше вид будет?

Кстати, а перечислять протоколы: --p tcp,udp можно или недопустимо? (Конечно, если в опциях ничего конфликтного нет: например, опций, неприменимых к udp-датаграмам?)

11

Почитай гентушные доки
Межсетевые экраны
Iptables_для_начинающих
Подробная_настройка_iptables
Логика_и_правила_iptables

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

12

Мне понравилась вот такая реализация - это если красиво.

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

13

Большое спасибо за материалы! Поштудирую.

14

zenon пишет:

Почитай гентушные доки
...
Логика_и_правила_iptables

Немного не пойму вот этого участка из приведенного источника:

# 2. Входящий SSH трафик
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N ssh-in
  $IPTABLES -F ssh-in
  $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT
# Защита о флуда по SSH
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Сперва правилом $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT безусловно разрешаются входящие TCP соединения на 22й порт. А потом добавляется ворох правил с ограничением по времени в качестве защиты от флуда. Какой в этом смысл? Ведь до них просто не будет до ходить дело: будет постоянно отрабатывать первое разрешающее правило. И если его поставить после правил с limit, это тоже играть роли не будет.

В чем я не прав?

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

Спасибо!

15

P.S. тогда уж сделать правило таким:

$IPTABLES -A ssh-in -m limit ! --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j DROP

(если я верно понял описание этого модуля из доков)

16

Пытаюсь сам вниктуть в ssh-in цепочку, созданную там, вроде идея при политиках DROP завернуть 22 порт в ssh-in и пропустить только то что можно... как-то не стыкуется немного. _:(

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

17

Мне кажется, там все-таки ошибка...  bw
Вот как предложено в другом источнике из списка:

  #Incoming traffic
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood protection
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Тут, по крайней мере, все понятно и логично...

Правда, я не совсем понимаю сути этой защиты... Если какой-то усердный товарищ будет долбить 22й порт такими пакетами, то ведь и "честный" пользователь будет испытывать проблемы при подключении? Тут уж кому повезет - чей пакет первым проскочит в очередную секунду, разве нет?

18

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

1 iptables -N ssh_brute_check 
2 iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 600 --hitcount 3 -j DROP
3 iptables -A ssh_brute_check -m recent --set -j ACCEPT
4 iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_brute_check

1 Создаем цепочку для проверки попыток соединений на защищаемый порт
2 Если за последние 10 минут (600 секунд) с одного адреса было 3 или более новых соединений — блокируем этот адрес
3 В противном случае — разрешаем
4 Все попытки открыть новое соединение по SSH направляем на проверку
...
Есди правило такое:

iptables -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT

Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Всё остальное на усмотрение установленной политики (DROP в нормальном варианте).

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

19

За живой пример защиты от брута спасибо большое! Как раз уже начинал ломать голову над тем, как защитить входящее ВПН подключение.

> Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Это я понял... Я не понял смысла такой меры. Исключительно защита буфера от зафлуживания?

Например, при усердном флуде SSH порта SYN пакетами с подменой IP отправителя (даже с одной машины можно генерировать кучу пакетов в секунду) переполнения буфера полуоткрытых соединений не произойдет, но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

20

Liber пишет:

но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

Законопослушный пользователь с ip адресом отправителя флуда?

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

21 (02.03.2013 18:14:03 отредактировано Liber)

bw Я в разделе "limit" мана ничего про IP не нашел... Это ограничение действует для отдельных хостов? То есть, для каждого IP счетчик пакетов в секунду отдельный?

zenon пишет:

Законопослушный пользователь с ip адресом отправителя флуда?

Мне казалось, что отправитель флуда в поле source_address флуд-пакетов может указывать что угодно (в том числе IP законопослушных пользователей - для пущего смеха): ему ведь не нужны ответы сервера... Т.е. он может генерировать случайный IP для каждого пакета.

22

Liber пишет:

Мне казалось, что отправитель флуда в поле source_address флуд-пакетов может указывать что угодно (в том числе IP законопослушных пользователей - для пущего смеха): ему ведь не нужны ответы сервера... Т.е. он может генерировать случайный IP для каждого пакета.

Это тоже легко прикрывается. А именно - дропать упорных это правильно. Но всё равно в журнале все равно регистрируются такие попытки. Однако стоит перенести 22-й порт, на который лезет пионЭрия, на какой угодно случайно выбранный номер где-то там, наверху, а 22-й закрыть перманентно, как количество попыток подбора пароля сокращается на порядки. Проверено лично. Как только порт перенес - ни одной попытки подбора нет.
Ну и к этому еще маленькая фишка - у меня в интернет смотрит роутер (тупой до безобразия), который умеет редиректить порты, внешние, случайно выбранные, на стандартные порты реальных хостов в LAN. И чтобы работать с реальными хостами (на стандартных портах) - поднимаем VPN (openVPN). Или, если VPN нет, то тогда идем "через порты роутера".

23 (03.03.2013 06:33:13 отредактировано Liber)

Cruiser78 пишет:

Однако стоит перенести 22-й порт, на который лезет пионЭрия

Спасибо за советы! Это я первым делом сделал. Самое простое и очевидное. К тому же, доступ разрешен только из LAN и входящих ВПН подключений.

Cruiser78 пишет:

Это тоже легко прикрывается. А именно - дропать упорных это правильно.

Я к тому - а как в подобном случае отличать упорных от неупорных? Ведь все подряд будут отметаться, а через сито 1 раз в секунду будут проходить случайные пакеты. В том числе - флудерские. Вернее: в большинстве своем флудерские, ибо их на порядки больше, нежели "честных".

Я сам принцип все в толк взять никак не могу.  ab
То есть, на время флуда правило:
iptables -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
сам зафлуживаемый сервис доступнее никак не делает. То есть, по сути, происходит успешный DoS (если флуд достаточно интенсивный).

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

Я таки верно мыслю или совсем чего-то не понимаю?..  bw

24

zenon пишет:

Законопослушный пользователь с ip адресом отправителя флуда?

Liber пишет:

Я в разделе "limit" мана ничего про IP не нашел... Это ограничение действует для отдельных хостов? То есть, для каждого IP счетчик пакетов в секунду отдельный?

Вы о расширении recent?

25 (04.03.2013 07:33:30 отредактировано Liber)

Спрошу иначе: при каком значении limit: 1/second или 50/second; SSH-сервис будет работать надежнее (с большей вероятностью отзовется на запрос законопослушного клиента) под SYN-flood DoS атакой?

Почитал на тему (D)DoS атак, вопрос снят. Всем спасибо!

26

Еще вопрос по ULOG. Хочу сделать несколько разных лог-файлов под разные задачи (например, лог ошибок/лог активности юзверей). Как я понял, он не умеет распихивать сообщения из разных nlgroup по разным лог-файлам. То есть, для этого надо запускать несколько экземпляров ulogd с разными конфигами, в которых указаны разные nlgroup и лог-файлы. Что не очень удобно.

Нашел в гугле инфу про тулзу 'specter' (форк от улога с поддержкой нескольких nlgroup одним демоном). Но вот подумал, что может быть есть что-то более новое/удобное. Не могли бы вы посоветовать что-то конкретное? Желательно что-то элементарное, навроде ulog'а.

Спасибо!

27 (14.03.2013 09:03:26 отредактировано Kettler)

syslog-ng ток использовал log

Ищу дополнительный заработок (удалёнка).
Пьянка без секса – признак алкоголизма.