5) Необходимо настроить iptables

#!/bin/sh
cd ${0%${0##*/}}.
. ./conf.sh


/sbin/iptables -F -t nat
/sbin/iptables -F -t filter

/sbin/iptables -P PREROUTING DROP -t nat # правило не работает: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited
/sbin/iptables -P FORWARD DROP # запретная политика на проходящие пакеты, иначе добавление и удаление ip клиентов в таблицу FORWARD не имеет смысла, так как все попадает под политику ACCEPT и пролетает между интерфейсами, даже при отключении клиента


#external interface #####################################################################################
#ssh
/sbin/iptables -A PREROUTING -s ! $WIFI_NET -t nat -p tcp --dport 22 -d $EXTERNAL_IP -j ACCEPT # iptables ругается на некорректный формат правила
/sbin/iptables - t nat -A PREROUTING ! -s $WIFI_NET -d $EXTERNAL_IP -p tcp -m tcp --dport 22 -j ACCEPT

#drop others from external interface
/sbin/iptables -A PREROUTING -s ! $WIFI_NET -t nat -j DROP # в моей версии iptables фильтрация в таблице nat очень не рекомендуется
#end of external interface #################################################################



#internal interface ###################################################################################################

#before wifi chain we must add redirects for authorized users
/sbin/iptables -A PREROUTING -t nat -p tcp --dport 80 -d $EXTERNAL_IP -j REDIRECT --to-ports $PORTAL_HTTP_PORT
/sbin/iptables -A PREROUTING -t nat -p tcp --dport 443 -d $EXTERNAL_IP -j REDIRECT --to-ports $PORTAL_HTTPS_PORT


#chain for WiFi (accept rules for authorized users)

/sbin/iptables --delete-chain $WIFI_CHAIN_NAME -t nat
/sbin/iptables -N $WIFI_CHAIN_NAME -t nat
/sbin/iptables -A PREROUTING -j $WIFI_CHAIN_NAME -t nat

#below is rules for internal not authorized users :

#dns
/sbin/iptables -A PREROUTING -t nat -p udp --dport 53 -j ACCEPT

#http
/sbin/iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-ports $PORTAL_HTTP_PORT
/sbin/iptables -A PREROUTING -t nat -p tcp --dport $PORTAL_HTTP_PORT -j ACCEPT

#https
/sbin/iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-ports $PORTAL_HTTPS_PORT
/sbin/iptables -A PREROUTING -t nat -p tcp --dport $PORTAL_HTTPS_PORT -j ACCEPT

#statistics
/sbin/iptables -A PREROUTING -t nat -p tcp --dport 8080 -d $EXTERNAL_IP -j ACCEPT


# NAT
iptables -A POSTROUTING -o $EXTERNAL_INTERFACE -s $WIFI_NET -j SNAT -t nat --to-source $EXTERNAL_IP

#RST packets for dropping estblished connections
/sbin/iptables -A FORWARD -p tcp -j REJECT --reject-with tcp-reset

2) Защита WiFi-сети от ARP-спуффинга

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

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

/sbin/iptables -P PREROUTING DROP -t nat # правило не работает: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited
/sbin/iptables -P FORWARD DROP # запретная политика на проходящие пакеты, иначе добавление и удаление ip клиентов в таблицу FORWARD не имеет смысла, так как все попадает под политику ACCEPT и пролетает между интерфейсами, даже при отключении клиента

Хм. значит в старых версиях iptables это работало . Но вы кажется тоже неправильно сделали . Потому как была цель закрыть все, ..а вы получается закрыли только forward . Лучше уж тогда сделать то же самое что и было, но в таблице mangle .
Схема прохождения пакетов вот :
http://www.opennet.ru/docs/RUS/iptables ... averse.jpg

#external interface #####################################################################################
#ssh
/sbin/iptables -A PREROUTING -s ! $WIFI_NET -t nat -p tcp --dport 22 -d $EXTERNAL_IP -j ACCEPT # iptables ругается на некорректный формат правила
/sbin/iptables - t nat -A PREROUTING ! -s $WIFI_NET -d $EXTERNAL_IP -p tcp -m tcp --dport 22 -j ACCEPT

depreacated. Поменялся синтаксис iptables .Хорошо исправим документацию . Возможно вообще это оттуда уберем и поместмм в wiki . Кстати это правило работает вместе с вашим верхним исправлением . Но так как вы там испраивли , тот тут тоже менять тоже тогда надо . Т.е надо все сразу подогнать

пропинговать сеть можно по одному ip, а не по всей сетке, даже если фильтровать сеть по ICMP, по команде arp -a -n видно все маки и айпи

речь идет о одноранговой сети, сеть работает по TCP/IP, соответственно по ARP, и если подмена идет одновременно и MAC и IP, то статическая arp таблица нужна на шлюзе + привязка MAC еще где-то, иначе нельзя обеспечить нормальную работу сети.

Пример для локальной сети: все порты ethrenet коммутатора имеют привязку по MAC, а шлюз через который выходит пользователь имеет статическую таблицу ARP
Пример для adsl-сети: на adsl-коммутаторах на каждом порту есть привязка MAC, шлюз через который выходит пользователь имеет статическую таблицу ARP

А как гарантировать невозможность подмены IP и MAC в нашем случае?

#drop others from external interface
/sbin/iptables -A PREROUTING -s ! $WIFI_NET -t nat -j DROP # в моей версии iptables фильтрация в таблице nat очень не рекомендуется

тогда уж лучше использовать mangle наверное ..И в первом вашем исправлении тоже

Использование того же самого mac и ip - непонятно как это быдет работаьь при одноврменной работе , скорее всего конфликт будет . и от этого схема не защищает

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

защиты на все случае жизни нет ..Заказчик этой фичи хотел именно этот вариант. Как вы предлагаете это реализоваить ?

таблицу mangle не нужно использовать для фильтрации, только для маркировки и работы с QoS

возник еще один вопрос

допустим выделяется сеть ip-адресов для клиентов, работающих через wifi портал - это сеть 10.2.1.0/24, из нее посредством DHCP клиент получил адрес 10.2.1.1
после авторизации на странице портала, клиент получил доступ во внешний интернет, естественно с ip-адресом 10.2.1.1
для этого же адреса идет подсчет трафика, ip, который прописан в договоре (в модуле dialup) почему то игнорируется

После получения ip от dhcpd он жестко закрепится в arp-таблице шлюза и клиент не сможет его подменит там ..

dialup вер. 4.6 сборка 200 от 06.10.2009 18:25:37
ipn вер. 4.6 сборка 212 от 06.10.2009 13:00:43
BGDialupWiFiAgent 4.6.213