Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: Доводка до ума скрипта iptables, тонкая настройка.  (Прочитано 3022 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн _set_

  • Автор темы
  • Участник
  • *
  • Сообщений: 227
    • Просмотр профиля
Настроен сервер на базе Ubuntu 12.04, выступает в ролях: dhcp, сервер доступа, билинг, шлюз, БД Mysql. Netfilter настроен на базе скрипта из учебного пособия из «Руководство по iptables (Iptables Tutorial 1.1.19)», под спойлером.
У сервака реальный постоянный ip-адрес, и есть еще другая реальная подсеть /24, часть которой, примерно 20-30 ip, нужно прикрутить к трансляции. Т.е. Я в билинге нарезаю подсети с маской /27 и соотвественно "форвардю" и "натю" их iptables, что бы вся сеть не сидела на одном адресе. Сейчас есть три серых сети, которые натятся на три реальных адреса: основная група абонов на реальный ip сервера и две гуппы со своими реальными адресами из другой сети. Также есть несколько служебных компов, которые работают по прямому нату, т. е. без pppoe.
Как, и нужно ли, сделать красиво что бы не «натить» набор сетей 20-30 правилами?
Нужно разрешить весь абонентский трафик для форвардинга, стоит ли открыть все порты udp и tcp выше 1024 или хватит текущей конфигурации?
Еще меня беспокоит достаточно большое (а может и нет, опыта маловато сказать наверняка) количество отброшеных новых, не syn, пакетов.
Dec 25 09:51:10 localhost kernel: [87597.711267] New not syn:IN=eth0 OUT= MAC=00:1b:21:6f:e8:3c:00:11:43:34:40:67:08:00 SRC=54.225.249.246 DST=172.16.0.15 LEN=128 TOS=0x00 PREC=0x00 TTL=43 ID=25883 DF PROTO=TCP SPT=4244 DPT=55317 WINDOW=113 RES=0x00 ACK PSH URGP=0
Dec 25 09:51:46 localhost kernel: [87633.737024] New not syn:IN=eth0 OUT= MAC=00:1b:21:6f:e8:3c:00:11:43:34:40:67:08:00 SRC=195.**.***.** DST=172.16.0.15 LEN=41 TOS=0x00 PREC=0x00 TTL=58 ID=25019 DF PROTO=TCP SPT=8000 DPT=50873 WINDOW=4 RES=0x00 ACK URGP=0
Можна ли этим принебречь и просто подавить логирование таких пакетов?
Какие правила можно/нужно переместить в очереди?
В общем, господа, любые замечания приветствуются.

(Нажмите, чтобы показать/скрыть)
« Последнее редактирование: 09 Января 2014, 12:32:00 от _set_ »

Оффлайн _set_

  • Автор темы
  • Участник
  • *
  • Сообщений: 227
    • Просмотр профиля
В сети большинство абонентов на серых адресах есть группа с реальными, возникла задача сделать доступ абонентов к своему оборудованию с реальными IP и разрешить пинги на него. Решил таким правилом:
$IPT -A FORWARD -i $INET_IFACE -d $INET_NET -j ACCEPTНо оно мне кажется слишком общим, а с другой стороны, по-идее, все равно не даст из локальной сети ($LAN_IFACE) ходить на реальные адреса, т.е. правило должно быть таким:
$IPT -A FORWARD -d $INET_NET -j ACCEPTПоправьте меня, пожалуйста.

Пользователь решил продолжить мысль 09 Января 2014, 15:46:28:
Блин, то ли я глупые вопросы задаю, то ли слишком заумные...
« Последнее редактирование: 09 Января 2014, 15:46:28 от _set_ »

Оффлайн aviacliff

  • Участник
  • *
  • Сообщений: 100
    • Просмотр профиля
Цитировать
Как, и нужно ли, сделать красиво что бы не «натить» набор сетей 20-30 правилами?

На мой взгляд 20-30 правил не так уж и много, попробуйте такой скрипт помучать:

#/bin/sh

#Разрешаем форводинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Разрешаем трафик на loopback-интерфейсе
iptables -A INPUT -i lo -j ACCEPT

# Разрешаем доступ извнутренней сети наружу
iptables -A FORWARD -i eth2 -o eth3 -j ACCEPT

# ВключаемNAT
iptables -t nat -A POSTROUTING -o eth3 -j MASQUERADE
#iptables -t nat -A POSTROUTING -o eth3 -j  NAT –to-source 192.168.zz.vv

# Разрешаем ответы из внешней сети
iptables -A FORWARD -i eth3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Запрещаем доступ снаружи во внутреннюю сеть
iptables -A FORWARD -i eth3 -o eth2 -j REJECT

можно добавить в правила

$IPT -A INPUT   -i $INET_IFACE -d ! $INET_IP  -j DROP
Цитировать
Нужно разрешить весь абонентский трафик для форвардинга, стоит ли открыть все порты udp и tcp выше 1024 или хватит текущей конфигурации?

Думаю можно прислушаться к совету:
 печально известные порты:
 0 - tcpmux; у SGI есть уязвимость, через которую можно атаковать
13 - daytime
98 - Linuxconf
111 - sunrpc (portmap)
137:139, 445 - Microsoft
SNMP: 161,2
Флотилия Squid: 3128, 8000, 8008, 8080
1214 - Morpheus или KaZaA
2049 - NFS
3049 - очень заразный троян для Linux, часто путаемый с NFS
Часто атакуемые: 1999, 4329, 6346
Частые трояны 12345 65535
 COMBLOCK="0:1 13 98 111 137:139 161:162 445 1214 1999 2049 3049 4329 6346 3128 8000 8008 8080 12345 65535"
Порты TCP:
 98 - Linuxconf
512-515 - rexec, rlogin, rsh, printer(lpd)
#[очень серьезеные уязвимости; продолжаются ежедневные атаки]
1080 - прокси-серверы Socks
6000 - X (ЗАМЕЧАНИЕ. X через SSH - безопасен, и работает на порту TCP 22)
Блокировка 6112 (CDE у Sun и HP)
 TCPBLOCK="$COMBLOCK 98 512:515 1080 6000:6009 6112"
Порты UDP:
161:162 - SNMP
520=RIP, 9000 - Sangoma
517:518 - talk и ntalk (самые надоедливые)

Напоминаю, "UBUNTU" переводится как "ЧЕЛОВЕЧНОСТЬ"

Оффлайн _set_

  • Автор темы
  • Участник
  • *
  • Сообщений: 227
    • Просмотр профиля
Цитировать
На мой взгляд 20-30 правил не так уж и много, попробуйте такой скрипт помучать:
20-30 правил только для НАТ, в целом правил больше чем в приведенном скрипте (некоторые решил не светить).
Цитировать
# Запрещаем доступ снаружи во внутреннюю сеть
iptables -A FORWARD -i eth3 -o eth2 -j REJECT
это мне не подойдет поскольку абонам как раз нужно иметь доступ к своему оборудованию в моей сети. Или я неправильно понимаю идеологию этого правила?
Цитировать
можно добавить в правила

Код: [Выделить]
$IPT -A INPUT   -i $INET_IFACE -d ! $INET_IP  -j DROP
Вот это интересно, против каких атак используется?
Цитировать
Думаю можно прислушаться к совету:
 печально известные порты:
 0 - tcpmux; у SGI есть уязвимость, через которую можно атаковать
13 - daytime
98 - Linuxconf
111 - sunrpc (portmap)
137:139, 445 - Microsoft
SNMP: 161,2
Флотилия Squid: 3128, 8000, 8008, 8080
1214 - Morpheus или KaZaA
2049 - NFS
3049 - очень заразный троян для Linux, часто путаемый с NFS
Часто атакуемые: 1999, 4329, 6346
Частые трояны 12345 65535
 COMBLOCK="0:1 13 98 111 137:139 161:162 445 1214 1999 2049 3049 4329 6346 3128 8000 8008 8080 12345 65535"
Порты TCP:
 98 - Linuxconf
512-515 - rexec, rlogin, rsh, printer(lpd)
#[очень серьезеные уязвимости; продолжаются ежедневные атаки]
1080 - прокси-серверы Socks
6000 - X (ЗАМЕЧАНИЕ. X через SSH - безопасен, и работает на порту TCP 22)
Блокировка 6112 (CDE у Sun и HP)
 TCPBLOCK="$COMBLOCK 98 512:515 1080 6000:6009 6112"
Порты UDP:
161:162 - SNMP
520=RIP, 9000 - Sangoma
517:518 - talk и ntalk (самые надоедливые)
Мммм, а можно ссылку на даную статью? Выглядит как рекомендации для цепочки INPUT да и SNMP нужен, думаю просто ограничить адресом с которого приходят запросы на 161-162.

В сети большинство абонентов на серых адресах есть группа с реальными, возникла задача сделать доступ абонентов к своему оборудованию с реальными IP и разрешить пинги на него. Решил таким правилом:
$IPT -A FORWARD -i $INET_IFACE -d $INET_NET -j ACCEPTНо оно мне кажется слишком общим, а с другой стороны, по-идее, все равно не даст из локальной сети ($LAN_IFACE) ходить на реальные адреса, т.е. правило должно быть таким:
$IPT -A FORWARD -d $INET_NET -j ACCEPTПоправьте меня, пожалуйста.
Отвечу сам себе - открываем всю сеть и настраиваем защиту на конкретных станциях из этой сети.

Оффлайн aviacliff

  • Участник
  • *
  • Сообщений: 100
    • Просмотр профиля
Статья называется: Подробная настройка iptables
http://aidalinux.ru/w/%D0%9F%D0%BE%D0%B4%D1%80%D0%BE%D0%B1%D0%BD%D0%B0%D1%8F_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_iptables

Может пригодится еще вот такое: Сетевой брандмауер (Часть 1)
Статья не особо свежая,но изложена хорошо
http://rus-linux.net/MyLDP/BOOKS/redhatsec/glava07.htm


Пользователь решил продолжить мысль 19 Января 2014, 19:29:50:
Цитировать
Но оно мне кажется слишком общим, а с другой стороны, по-идее, все равно не даст из локальной сети ($LAN_IFACE) ходить на реальные адреса, т.е. правило должно быть таким:

Я думаю в правилах нужно сделать привязку к IP адресам для увеличения безопасности.
Если оперируешь только с  интерфейсами уязвисостей больше.
« Последнее редактирование: 21 Января 2014, 17:55:46 от aviacliff »
Напоминаю, "UBUNTU" переводится как "ЧЕЛОВЕЧНОСТЬ"

 

Страница сгенерирована за 0.019 секунд. Запросов: 22.