Slackware 13.1. Только что установил, ничего еще не настраивал кроме файла rc.inet1.conf.
Iptables не настраивал.#ip addr
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 1c:bd:b9:e6:cf:a3 brd ff:ff:ff:ff:ff:ff
inet x.x.x.2/24 brd x.x.x.255 scope global eth1
inet6 fe80::1ebd:b9ff:fee6:cfa3/64 scope link
valid_lft forever preferred_lft forever
3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 1c:bd:b9:e6:cf:7c brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:e6:66:f3:df brd ff:ff:ff:ff:ff:ff
inet 192.168.42.7/24 brd 192.168.42.255 scope global eth0
inet6 fe80::216:e6ff:fe66:f3df/64 scope link
valid_lft forever preferred_lft foreverI. Подключаю к сети встроенную карту(eth0), только эту сетевую карту, т.е кабель один. Пингую адрес 192.168.42.7, он пингуется
Пингую адрес x.x.x.2, он почему-то тоже пингуется????
II. Вытаскиваю кабель из eth0 - эти адреса(192.168.42.7, x.x.x.2) не пигуются, ну то есть в сети других таких нет(хотя тоже не факт, думаю что нет).
III. Подключаю внешнюю сетевую карту, думаю что это eth1 т.к. пингую шлюз x.x.x.1 с самого сервера(со второй внешней шлюз не пингуется). Ну и с лан сети адреса 192.168.42.7, x.x.x.2 не пингуются через подключенную eth1.
ip_forward выставлен в 0.Компьютер в лан сети с которого пингую этот комп настроен только на подсеть 192.168.42.0.
Не понимаю почему пинг проходит через eth0 до ip-шника что висит на eth1? Неужели так и должно работать?
>[оверквотинг удален]
> то есть в сети других таких нет(хотя тоже не факт, думаю
> что нет).
> III. Подключаю внешнюю сетевую карту, думаю что это eth1 т.к. пингую шлюз
> x.x.x.1 с самого сервера(со второй внешней шлюз не пингуется). Ну и
> с лан сети адреса 192.168.42.7, x.x.x.2 не пингуются через подключенную eth1.
> ip_forward выставлен в 0.
> Компьютер в лан сети с которого пингую этот комп настроен только на
> подсеть 192.168.42.0.
> Не понимаю почему пинг проходит через eth0 до ip-шника что висит на
> eth1? Неужели так и должно работать?
>> eth1? Неужели так и должно работать?
> http://www.opennet.me/openforum/vsluhforumID1/86766.htmlСпасибо!
Сколько пересмотрел примеров скриптов\правил в iptables в нете, вроде не замечал правила блокировки этой возможности проскакивания пакетов на другой интерфейс.
Как то не упоминалось об этом.
Насколько эта возможность опасна? Как/Чем профессиональней задропить эту возможность?
Ebtables?
>>> eth1? Неужели так и должно работать?
>> http://www.opennet.me/openforum/vsluhforumID1/86766.html
> Спасибо!
> Сколько пересмотрел примеров скриптов\правил в iptables в нете, вроде не замечал правила
> блокировки этой возможности проскакивания пакетов на другой интерфейс.вообще то пакет не проскакивает на другой интерфейс, а попав в ядро определяется что он прибыл на челевую машину, даже если пришел через интерфейс с другим ip.
> Как то не упоминалось об этом.
> Насколько эта возможность опасна? Как/Чем профессиональней задропить эту возможность?зависит от того что именно хотите запретить.
> Ebtables?
> зависит от того что именно хотите запретить.Вообще, мне представилась следующий механизм взлома, не факт, что он работает, это просто домыслы из-за непонимания, в связи с чем и вопросы, читать буду еще конечно. Если кто-то с внешней сети поставит у себя в качестве gw внешний ip моего сервера, и при знании внутреннего ip моего сервера, сможет подключиться к сервисам что висят на локальном интерфейсе..т.к. пакеты которые приходят на сервер от злоумышленика будут распозноваться как INPUT(являться как раз целевыми для моего сервера) а не FORWARD, отправляться на внутренний интерфейс где как раз сервисы-то и прослушивают соединения(ssh, webmin например). Как-то так. От этого бы и хотелось защититься.
Ну то есть вопрос сводится к следующему, а будут ли в этом случае доступны сервисы которые висят только на внутреннем интерфейсе(или как это правильнее сказать доступны только с локальной сети, так как с внешней порты заблокированы iptables)..
>> зависит от того что именно хотите запретить.
> Вообще, мне представилась следующий механизм взлома, не факт, что он работает, это
> просто домыслы из-за непонимания, в связи с чем и вопросы, читать
> буду еще конечно. Если кто-то с внешней сети поставит у себя
> в качестве gw внешний ip моего сервера, и при знании внутреннего
> ip моего сервера, сможет подключиться к сервисам что висят на локальномдля этого еще и провайдер должен эти пакеты смаршрутизировать или вас с ним держать в одной подсети.
точней доставить, а не смаршрутизировать
> интерфейсе..т.к. пакеты которые приходят на сервер от злоумышленика будут распозноваться
> как INPUT(являться как раз целевыми для моего сервера) а не FORWARD,
> отправляться на внутренний интерфейс где как раз сервисы-то и прослушивают соединения(ssh,
> webmin например). Как-то так. От этого бы и хотелось защититься.
> Ну то есть вопрос сводится к следующему, а будут ли в этом
> случае доступны сервисы которые висят только на внутреннем интерфейсе(или как это
> правильнее сказать доступны только с локальной сети, так как с внешней
> порты заблокированы iptables)..для этого и рекомендуют на внешнем интерфейсе блокировать пакеты идущие на серые ip
-I INPUT -i eth0 -d ip_eth1 -j DROP
> для этого и рекомендуют на внешнем интерфейсе блокировать пакеты идущие на серые
> ip
> -I INPUT -i eth0 -d ip_eth1 -j DROPАга. конечно. Прям так сразу "-I INPUT" =)
-I FORWARD после правила с "-m state --state ESTABLISHED,RELATED" или фильтровать в PREROUTING mangle.
>> для этого и рекомендуют на внешнем интерфейсе блокировать пакеты идущие на серые
>> ip
>> -I INPUT -i eth0 -d ip_eth1 -j DROP
> Ага. конечно. Прям так сразу "-I INPUT" =)
> -I FORWARD после правила с "-m state --state ESTABLISHED,RELATED" или фильтровать в
> PREROUTING mangle.причем тут FORWARD , если разговор об интерфейсах локальной машины
>>> для этого и рекомендуют на внешнем интерфейсе блокировать пакеты идущие на серые
>>> ip
>>> -I INPUT -i eth0 -d ip_eth1 -j DROP
>> Ага. конечно. Прям так сразу "-I INPUT" =)
>> -I FORWARD после правила с "-m state --state ESTABLISHED,RELATED" или фильтровать в
>> PREROUTING mangle.
> причем тут FORWARD , если разговор об интерфейсах локальной машинымммда, я чето про внутреннюю локалку подумал, да, маленько прощелкал.
Получается это не замечание, а скорее дополнение.
>[оверквотинг удален]
> то есть в сети других таких нет(хотя тоже не факт, думаю
> что нет).
> III. Подключаю внешнюю сетевую карту, думаю что это eth1 т.к. пингую шлюз
> x.x.x.1 с самого сервера(со второй внешней шлюз не пингуется). Ну и
> с лан сети адреса 192.168.42.7, x.x.x.2 не пингуются через подключенную eth1.
> ip_forward выставлен в 0.
> Компьютер в лан сети с которого пингую этот комп настроен только на
> подсеть 192.168.42.0.
> Не понимаю почему пинг проходит через eth0 до ip-шника что висит на
> eth1? Неужели так и должно работать?В общем такое возможно и даже должно быть!
Подробнее:
ip привязка получается из arp протокола таким образом устанавливая адрес для одной сетевой карты мы говорим о нашем адресе.
есть такие параметры /proc/sys/net/ipv4/conf/eth*/arp_*
В общем, сейчас точно не помню но этими файлами задается поведение интерфейса(ов) в области arp. И если машина с адресом на одной карточке получает/отправляет ответ/запрос через другую, то у нее есть все шансы получить в кеш доступность данных x.x.x.2 через другой интерфейс. Задается вышеуказанными параметрами. Более подробно не скажу давненько это все было. но у меня на внутренних интерфейсах стоит строка:
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
И в этом случае подобный эффект пропадает, но перед тем как делать почитать.ps:
там несколько файлов, не помню что именно каждый из них дает но приведу их все (что есть у меня):
arp_accept
arp_announce
arp_filter
arp_ignore
arp_notify
> на внутренних интерфейсах стоит строка:
> echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
> И в этом случае подобный эффект пропадает, но перед тем как делать
> почитать.Выполнил строку, эффект не пропал. Ладно почитаем, спасибо!