Подскажите пожайлуста как наиболее эффективно (производительно) блокировать доступ к серванту для определенных IP-адресов. Блокировка осуществляется к apache'у к примеру (про файл host.allow host.deny я знаю, не думаю в данном случае он неприменим). И к примеру как осуществить блокировку IP-адресов при их доступе к серванту, но не наоборот, к любому сервису.
IP-адресов много, они не упорядочены и блокировка типа
{
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.222 -j DROP
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.2 -j DROP
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.77 -j DROP
$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.155 -j DROP
}
я думаю неочень хорошо сказывается на производительности IPTABLES. А представляете что вот таких IP-адресов полсотни, что же получается - 50 строк для осуществления блокировки !Хотя может быть и нет другого выхода.....
Также про патч, который может подставлять диапазон IP-адресов тоже знаю (адреса то невсегда идут непрерывно).
Жругими словами нежен PATCH для IPTABLES для подстановки разных IP адресов как что то вроде -mport.Совсем забыл сказать какая система - FEDORE CORE 2, хотя какая разница правила всеравно примерно одни и теже.
Заранее спасибо.....
>Подскажите пожайлуста как наиболее эффективно (производительно) блокировать доступ к серванту для определенных
>IP-адресов. Блокировка осуществляется к apache'у к примеру (про файл host.allow host.deny
>я знаю, не думаю в данном случае он неприменим). И к
>примеру как осуществить блокировку IP-адресов при их доступе к серванту, но
>не наоборот, к любому сервису.
>IP-адресов много, они не упорядочены и блокировка типа
>{
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.222 -j DROP
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.2 -j DROP
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.77 -j DROP
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.155 -j DROP
>}
>я думаю неочень хорошо сказывается на производительности IPTABLES. А представляете что вот
>таких IP-адресов полсотни, что же получается - 50 строк для осуществления
>блокировки !
>
>Хотя может быть и нет другого выхода.....
>
>Также про патч, который может подставлять диапазон IP-адресов тоже знаю (адреса то
>невсегда идут непрерывно).
>Жругими словами нежен PATCH для IPTABLES для подстановки разных IP адресов как
>что то вроде -mport.
>
>Совсем забыл сказать какая система - FEDORE CORE 2, хотя какая разница
>правила всеравно примерно одни и теже.
>Заранее спасибо.....
http://www.netfilter.org/downloads.html#pom-20031219
а что, одно правило с пятьюдесятью IP-адресами лучше? используй отдельную таблицу, в которую все IP-ы и загоняй...
>а что, одно правило с пятьюдесятью IP-адресами лучше? используй отдельную таблицу, в
>которую все IP-ы и загоняй...Конечно использование отдельной таблицы для проверки валидности IP-адресов повышает наглядность сктипта применения правил брандмаура но не повышает производительность его работы... или я не прав (все равно где бы ни стояла эта таблица проверять на валидность придется все входящие запросы)
А вот интересно есть ли возможность прикрытить к IPTABLES всешний файл соответственно в нем и будут находиться эти нежелательные IP-адреса и также впоследствии обнаружения сканирования или что-то другого, можно как добавить так и удалить оттуда некоторый IP-адрес
..... или это уже функции специальных программ защиты?
Вы уверены, что 1 правило с 50 IP-ами обрабатывается быстрее, чем 50 по 1? Я нет. И в любом случае, не уверен, что эти проверки будут влиять на скорость. Какое-то древнее сравнение показывало, что на Р1-сколько-то порядка 1000 правил почти не добавляло задержку. У вас, наверное, уже не р1? И плавил поменее...Это функция iptabless-restore, если я правильно понял...
>>а что, одно правило с пятьюдесятью IP-адресами лучше? используй отдельную таблицу, в
>>которую все IP-ы и загоняй...
>
>Конечно использование отдельной таблицы для проверки валидности IP-адресов повышает наглядность сктипта применения
>правил брандмаура но не повышает производительность его работы... или
>я не прав (все равно где бы ни стояла эта
>таблица проверять на валидность придется все входящие запросы)
>
>А вот интересно есть ли возможность прикрытить к IPTABLES всешний файл соответственно
>в нем и будут находиться эти нежелательные IP-адреса и также впоследствии
>обнаружения сканирования или что-то другого, можно как добавить так и удалить
>оттуда некоторый IP-адрес
>..... или это уже функции специальных программ защиты?
Блокировка по IP не будет сильно тормозить машину. Разве что у тебя там стоит первый пень или 486, или количество строк превалит за несколько десятков тысяч, или трафик сумасшедший. А насчет эффективного добавления исключения... Фирмы производящие IDS давно бы разорились, если бы кто-нибудь придумал эффективный и несложный способ делать это!
>>>а что, одно правило с пятьюдесятью IP-адресами лучше? используй отдельную таблицу, в
>>>которую все IP-ы и загоняй...
>>
>>Конечно использование отдельной таблицы для проверки валидности IP-адресов повышает наглядность сктипта применения
>>правил брандмаура но не повышает производительность его работы... или
>>я не прав (все равно где бы ни стояла эта
>>таблица проверять на валидность придется все входящие запросы)
>>
>>А вот интересно есть ли возможность прикрытить к IPTABLES всешний файл соответственно
>>в нем и будут находиться эти нежелательные IP-адреса и также впоследствии
>>обнаружения сканирования или что-то другого, можно как добавить так и удалить
>>оттуда некоторый IP-адрес
>>..... или это уже функции специальных программ защиты?
>
>
>Блокировка по IP не будет сильно тормозить машину. Разве что у тебя
>там стоит первый пень или 486, или количество строк превалит за
>несколько десятков тысяч, или трафик сумасшедший. А насчет эффективного добавления исключения...
>Фирмы производящие IDS давно бы разорились, если бы кто-нибудь придумал эффективный
>и несложный способ делать это!Спасибо за ответ!
На самом деле у меня процессор немного посерьезнее P-I (P-IV), так что будем использовать отдельныую таблицу с целью проверки валидности IP-адресов, Неважно что в ней будет много правил. Причем при обнаружение сканирования или прочмх неприятных моментов всегда можно добать на ходы правилов эту таблицу..
>>>>а что, одно правило с пятьюдесятью IP-адресами лучше? используй отдельную таблицу, в
>>>>которую все IP-ы и загоняй...
>>>
>>>Конечно использование отдельной таблицы для проверки валидности IP-адресов повышает наглядность сктипта применения
>>>правил брандмаура но не повышает производительность его работы... или
>>>я не прав (все равно где бы ни стояла эта
>>>таблица проверять на валидность придется все входящие запросы)
>>>
>>>А вот интересно есть ли возможность прикрытить к IPTABLES всешний файл соответственно
>>>в нем и будут находиться эти нежелательные IP-адреса и также впоследствии
>>>обнаружения сканирования или что-то другого, можно как добавить так и удалить
>>>оттуда некоторый IP-адрес
>>>..... или это уже функции специальных программ защиты?
>>
>>
>>Блокировка по IP не будет сильно тормозить машину. Разве что у тебя
>>там стоит первый пень или 486, или количество строк превалит за
>>несколько десятков тысяч, или трафик сумасшедший. А насчет эффективного добавления исключения...
>>Фирмы производящие IDS давно бы разорились, если бы кто-нибудь придумал эффективный
>>и несложный способ делать это!
>
>Спасибо за ответ!
>На самом деле у меня процессор немного посерьезнее P-I (P-IV), так что
>будем использовать отдельныую таблицу с целью проверки валидности IP-адресов, Неважно
>что в ней будет много правил. Причем при обнаружение сканирования или
>прочмх неприятных моментов всегда можно добать на ходы правилов эту таблицу..
>насчёт добавить при сканировании: portsentry поможет
(смотри KILL_ROUTE)
>Подскажите пожайлуста как наиболее эффективно (производительно) блокировать доступ к серванту для определенных
>IP-адресов много, они не упорядочены и блокировка типа
>{
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.222 -j DROP
>$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s 192.168.2.2 -j DROP
imho, наиболее эффективно будет работать именно в таком последовательном прогоне через все правила,а эффектно это реализовано здесь (обработка whitelist и blacklist)
http://hacks.oreilly.com/pub/h/45
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Creating a Firewall from the Command Line of any Server
You don't have to have a dedicated firewall to benefit from using iptablesThe netfilter firewall (available in Linux 2.4 and later) allows for very flexible firewall manipulation from the command line. Using iptables can take a while to get used to, but it allows for a very expressive syntax that lets you create complex (and hopefully useful ;) firewall rules.
Even if your machine isn't a "real" firewall (that is, it only has one network interface and isn't protecting other machines) the filter functionality can be very useful. Suppose you want to allow telnet access to this machine (just in case something happens to ssh or its libraries) but don't want to permit it from just anywhere on the Net. You could use a tcpwrapper (by populating /etc/hosts.allow and /etc/hosts.deny, and setting up /etc/inetd.conf appropriately). Or, you could use iptables with a line like this:
iptables -A INPUT -t filter -s ! 208.201.239.36 -p tcp --dport 23 -j DROP
Generally, most people want to permit unrestricted access from trusted hosts, block all access from known problem hosts, and allow something in between for everyone else. Here is one method for using a whitelist, blacklist, and restricted port policy simultaneously.#!/bin/sh
#
# A simple firewall initialization script
#
WHITELIST=/usr/local/etc/whitelist.txt
BLACKLIST=/usr/local/etc/blacklist.txt
ALLOWED="22 25 80 443"#
# Drop all existing filter rules
#
iptables -F#
# First, run through $WHITELIST, accepting all traffic from the hosts and networks
# contained therein.
#
for x in `grep -v ^# $WHITELIST | awk '{print $1}'`; do
echo "Permitting $x..."
iptables -A INPUT -t filter -s $x -j ACCEPT
done#
# Now run through $BLACKLIST, dropping all traffic from the hosts and networks
# contained therein.
#
for x in `grep -v ^# $BLACKLIST | awk '{print $1}'`; do
echo "Blocking $x..."
iptables -A INPUT -t filter -s $x -j DROP
done#
# Next, the permitted ports: What will we accept from hosts not appearing
# on the blacklist?
#
for port in $ALLOWED; do
echo "Accepting port $port..."
iptables -A INPUT -t filter -p tcp --dport $port -j ACCEPT
done#
# Finally, unless it's mentioned above, and it's an inbound startup request,
# just drop it.
#
iptables -A INPUT -t filter -p tcp --syn -j DROP
Be sure to specify all of the ports you'd like to include in the $ALLOWED variable at the top of the script. If you forget to include 22, you won't be able to ssh into the box!The /usr/local/etc/blacklist.txt file is populated with IP addresses, host names, and networks like this:
1.2.3.4 # Portscanned on 8/15/02
7.8.9.0/24 # Who knows what evil lurks therein
r00tb0y.script-kiddie.coop # $0 s0rR33 u 31337 h4x0r!
Likewise, /usr/local/etc/whitelist.txt contains the "good guys" that should be permitted no matter what the other rules specify:11.22.33.44 # My workstation
208.201.239.0/26 # the local network
Since we're only grabbing lines that don't start with #, you can comment out an entire line if you need to. The next time you run the script, any commented entries will be ignored. We run an iptables -F at the beginning to flush all existing filter entries, so you can simply run the script again when you make changes to blacklist.txt, whitelist.txt, or the ports specified in $ALLOWED.Also note that this script only allows for TCP connections. If you need to also support UDP, ICMP, or some other protocol, run another pass just like the $ALLOWED for loop, but include your additional ports and protocols (passing -p udp or -p icmp to iptables, for example).
Be careful about using whitelists. Any IPs or networks appearing on this list will be permitted to access all ports on your machine. In some circumstances, a clever miscreant may be able to send forged packets apparently originating from one of those IPs, if they can find out ahead of time (or logically deduce) what IPs appear on your whitelist. This kind of attack is difficult to perform, but it is possible. If you are particularly paranoid, you might only allow whitelist addresses from networks that aren't routable over the Internet but are used on your internal network.
It is extremely useful to have console access while working with new firewall rules (you can't lock yourself out of the console with iptables!) If you get confused about where you are when working with iptables, remember that you can always list out all rules with iptables -L, and start over by issuing iptables -F. If iptables -L seems to hang, try iptables -L -n to show the rules without doing any DNS resolution -- your rules might accidentally be prohibiting DNS requests.
You can do a lot with simple filtering, but there's much more to iptables than just the filter target.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
такой вариантопределяются политики - в конторе есть некие группы, которых туда пущать, а сюда нет (как вариант - доступ по портам к коммуникационному серверу)
для каждой группы создается своя цепочка
iptables -N (имя цепочки вход. траффик, например IN_q1)
iptables -N (имя цепочки на исход. траффик, например OUT_q1)и прописываются правила внутри, например
# для SMTP
iptables -A IN_q1 -j ACCEPT -p tcp --destination-port 25
iptables -A OUT_q1 -j ACCEPT -p tcp --source-port 25
# для POP3
iptables -A IN_q1 -j ACCEPT -p tcp --destination-port 110
iptables -A OUT_q1 -j ACCEPT -p tcp --source-port 110
ну и так далее
и в конце цепочки
iptables -A IN_q1 -j DROP
iptables -A OUT_q1 -j DROP
т.е. все,ч то не разрешено в цепочке ранее, отклонитьтакие независимые цепочки делаются для каждой группы безопастности
после чего для IP внутренней сети назначается обработка в нужной цепочкеiptables -A -i eth0 -s 1.2.3.4/32 -j IN_q1
iptables -A -o eth0 -d 1.2.3.4/32 -j OUT_q1это, ессно, частный случай, но он показателен
дальше по аналогии