FreeBSD + VPN + MAC + IP, аутентификация локальной сети, ?!?

[Pukite]

Привет, коллеги !

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

- привязка IP к MAC адресу;
- как избежать подмены MAC адреса;
- как организовать все это при помощи VPN;

Заранее благодарю за советы.

[hooch]

Привет, коллеги !

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

- привязка IP к MAC адресу;
- как избежать подмены MAC адреса;
- как организовать все это при помощи VPN;

Заранее благодарю за советы.

First goal can be (and usually I think) accomplished through a firewall.
Second: protiv loma net priema
Not sure I understand your third question correctly, but VPN is actually used to connect securely networks over the Internet, it has nothing to do with user/computer authorizaion.

[Palych]

PPP Over Ethernet???

I heard DHCP allows to have some authentication...

[Волчара]

Привет, коллеги !

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

- привязка IP к MAC адресу;
- как избежать подмены MAC адреса;
- как организовать все это при помощи VPN;

Заранее благодарю за советы.

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

Если просто хотите обеспечить секьюрный коннект с авторизацией - это випиэн.
На красной шапке делается за 3 часа макс, на фрибсд не делал. Волшебное слово для гугля mppe

[KYKAH]

Задача поставлена некорректно.
Кого и от чего надо защищать?

LAN_PC1 ot LAN_PC2?
Давать authorised Internet access?
Делать VPN from Internet to LAN_PC?


P.S. Have you done ANY Internet research on that AT ALL before going out to forum? А то за-RTFM-лю
_________________
Lamers must ... learn!

[A. Fig Lee]

Привет, коллеги !

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

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

Можно попробовать
"arp -s" "arp -S"
man arp короче.

[Vasik]

Для линукса когда стянул с zuzino.ru такой вот интересный материал - посмотрите, может и на фре будет работать:

Известно, что пользователи локальной сети с выходом в интернет никогда не останавливаются на достигнутом. Легенда о халяве неубиваема в России с давних времен (см. "Сказка о рыбаке и рыбке", "По щучьему велению" и т.д.), в частности, легенда о "халявном интернете".
Однако за трафик так или иначе кто-то платит - в домашней сети это обычно администратор-координатор, если за пользователем не уследил
То бишь, форменное воровство получается, а его надо пресекать.
Начнем с как-бы-теории. Для начала сделаем...


>$ man arp
...и порадовавшись собственной пытливости и знанию английского языка, на этом завершим теоретическую часть и приступим к практической - собственно автоматизации процесса.

Итак, для начала нам нужно сделать образцовый файл, в котором будет прописано соответствие MAC-адресов и IP-адресов. Естесственно, правильное соответствие. Как мы уже вычитали в доках этот файл должен обзываться ethers и лежать в /etc - то есть /etc/ethers

Формат этого файла таков: MAC-адрес__IP-адрес. Например:

00:80:48:89:ED:C6 192.168.3.1
00:00:E8:DA:6B:F6 192.168.3.2
00:80:48:DB:43:22 192.168.3.18
00:80:AD:97:0C:68 192.168.3.19
...

Соответствия для этого файла можно постепенно собрать в процессе работы пользователей, используя команду arp.
Сотворив этот файл, можно приступить к процессу автоматизации контроля за тем, не меняют ли коварные пользователи свой IP, дабы трафик засчитывался не им, а кому-либо другому.
Для этого сотворим вот такую программку на Perl, пояснения к которой даются прямо в теле, в виде комментариев:

#-------------------------------8<-----------------------------------
#!/usr/bin/perl
# Смотрим, кто из пользователей онлайн
$ipmc = `/sbin/arp -n | grep ether`;
@ipmc = split("\n", $ipmc);
# Выделяем их IP и MAC адреса, запоминаем в ассоциативном массиве
foreach $str (@ipmc) {
s/\t/ /g;
@strng = split(" ", $str);
$ip_mac{$strng[0]} = $strng[2];
}

# Теперь загружаем из созданного эталонного файла правильные
# соответствия MAC - IP
$ipmc = `cat /etc/ethers`;
@ipmc = split("\n", $ipmc);
foreach $str (@ipmc) {
($mac_def, $ip_def) = split("\t", $str);
$ip_fix{$ip_def} = $mac_def;
# Здесь небольшая хитрость - для облегчения процесса сравнения.
$ipfixip{$mac_def} = $ip_def;
}

# Данных у нас хоть завались - можно проверять. Для этого ставим признак
# наличия плохого парня в 0 и просто тотально проверяем все подряд,
# а данные по плохим парням засовываем в массив $ip_lamer
$set_err = 0;
foreach $ip (sort keys %ip_mac) {
if ($ip_mac{$ip} ne $ip_fix{$ip}) {
$ip_lamer{$ip} = $ip_mac{$ip};
$set_err = 1;
}
}

# Если признак наличия плохого парня не равен нулю - валим полученныq
# компромат в файл, из которого потом можно и в сетке показать... Кто
# трафик ворует... Если вора не жалко...
if ($set_err ne 0) {
$dttoday = `date`;
chop($dttoday);
# Например, можно валить полученные данные по плохим парням в файл
# в корне www-сервера, чтоб удобнее показывать миру.
open (BADUSER, ">>/var/httpd/html/private/badusers");
foreach $ip (sort keys %ip_lamer) {
$madmac = $ip_fix{$ip};
print (BADUSER "$dttoday\t$ipfixip{$madmac}\t$ip_lamer{$ip}\t$ip\n");
# Еще один элемент лени - при запуске скрипта вручную вывод будет в
# консоль, при запуске из cron - вывод мылом на root@ придет.
print "Defined lame user.\n $dttoday\nFrom: $ipfixip{$madmac}\nMAC:$ip_lamer{$ip}\nTo: $ip\n";
}
}
close BADUSER;
#-------------------------------8<-----------------------------------

Теперь осталось немного. Придать файлу аттрибуты 755, задвинуть его в полезное место, где подобные ленилки администраторские лежат, и записать его выполнение через cron раз в 5 минут, например. А можно и 10, 20 - все равно если кто-то задумает плохое - рано или поздно попадется...

Известно, что иногда хочется не геммороиться вычислением, кто подменяет IP-адреса на карте, а просто прибить их намертво к сетевой карте и все.
Сделать это не особо сложно. Здась нам опять пригодится волшебный файл /etc/ethers, который мы уже рассматривали

Для начала, соответственно,

>$ man arp
далее радуемся и делаем простую процедуру прибивания:
>$ arp -f /etc/ethers
Аллес. В смысле - готово. Теперь мы не сможем посмотреть, кто из абонентов онлайн (по команде arp), но зато и они не смогут подменить IP-адрес. просто ничего не произойдет, и в сеть они не попадут.
Частное следствие из этого такое. Если вам необходимо напрочь запереть доступ в сеть абоненту, делаем так:

>$ arp -s 00:00:00:00:00:00 IP_адрес_абонента
Вот примерно так...

[KYKAH]

Для линукса когда стянул с zuzino.ru такой вот интересный материал - посмотрите, может и на фре будет работать:

Это все хорошо, но это не защитит от несанкционированного поключения к LAN

Или надо на всех компах static arp делать, и подом либо dynamic arp вырубать (не уверен, что возможно), либо на всех компах что-то типа tcp-wrappers ставить.

[f_evgeny]

Для линукса когда стянул с zuzino.ru такой вот интересный материал - посмотрите, может и на фре будет работать:

Это все хорошо, но это не защитит от несанкционированного поключения к LAN

Или надо на всех компах static arp делать, и подом либо dynamic arp вырубать (не уверен, что возможно), либо на всех компах что-то типа tcp-wrappers ставить.

Никогда не делал ничего подобного. (Слава богу, пользователи пока не такие продвинутые и я могу их контролировать в том числе и административно), но, думаю, что единственным полноценным решением будет что-нибудь вроде автоматического поднятия/опускания маскарадинга (НАТ) для пользователей, авторизованных в NT домене в случае клиентов на Виндовс.

[Katz]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

[Волчара]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

как будто запрет подключаться к dhcp левому юзеру запретит ему торчать в этой сетке со статиком.

Я лично вопроса ваще не понял. То ли человеку надо организовать авторизацию подключения через гейт, тогда это достаточно просто - випиэн тот же. То ли организовать авторизацию юзеров в локалке - это хрен так просто сделаешь, разве что через IDS заморачиваться

[Vasik]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

Ну дык не все же клиенты используют DHCP!
Я вот вообще этот сервис не люблю, хотя на работе в силу традиции конторы приходится поддерживать.
Кстати MAC-адрес тоже поменять можно - многие платы позволяют это, так что если кто то знающий решит воспользоваться, то он отследит в сети чей нибудь MAC и IP и когда тот только отключится от сети, перенастроит свой сетевой интерфейс и сможет прорваться. То есть решение это действительно от ламеров. Если вы контролируете физическое подключение, то ещё можно поставить современные коммутаторы (Cisco например), которые умеют прибивать соответствие мак-адреса к подключенному порту и хоть меняй этот адрес - толку не будет. Но это дорого и больше каткит чисто для внутреннего корпоративного решения.
Нужно искать решение для грамотной авторизации, что бы уберечь свои ресурсы.

[Katz]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

как будто запрет подключаться к dhcp левому юзеру запретит ему торчать в этой сетке со статиком.

Можно вылавливать новые МАК-адреса arpwatch-ем и посылать алерт.

[Волчара]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

как будто запрет подключаться к dhcp левому юзеру запретит ему торчать в этой сетке со статиком.

Можно вылавливать новые МАК-адреса arpwatch-ем и посылать алерт.

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

На сам деле тут только две вещи можно сделать ИМНСХО

1. физическая секьюрити
2. IDS

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

[Katz]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

Ну дык не все же клиенты используют DHCP!
Я вот вообще этот сервис не люблю, хотя на работе в силу традиции конторы приходится поддерживать.
Кстати MAC-адрес тоже поменять можно - многие платы позволяют это, так что если кто то знающий решит воспользоваться, то он отследит в сети чей нибудь MAC и IP и когда тот только отключится от сети, перенастроит свой сетевой интерфейс и сможет прорваться. То есть решение это действительно от ламеров. Если вы контролируете физическое подключение, то ещё можно поставить современные коммутаторы (Cisco например), которые умеют прибивать соответствие мак-адреса к подключенному порту и хоть меняй этот адрес - толку не будет. Но это дорого и больше каткит чисто для внутреннего корпоративного решения.
Нужно искать решение для грамотной авторизации, что бы уберечь свои ресурсы.

Да в свитчах сиско есть такая фича secure port filtering. Ее можно использовать для параноидальных энвайронментс. Но все равно можно подключиться к тому же порту с тем же (измененным) МАК-адресом. Ничего не спасет, короче. Можно правда везде encryption использовать, тогда ничего не поможет. Подключайся, не подключайся, все по фигу.

[Волчара]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

Ну дык не все же клиенты используют DHCP!
Я вот вообще этот сервис не люблю, хотя на работе в силу традиции конторы приходится поддерживать.
Кстати MAC-адрес тоже поменять можно - многие платы позволяют это, так что если кто то знающий решит воспользоваться, то он отследит в сети чей нибудь MAC и IP и когда тот только отключится от сети, перенастроит свой сетевой интерфейс и сможет прорваться. То есть решение это действительно от ламеров. Если вы контролируете физическое подключение, то ещё можно поставить современные коммутаторы (Cisco например), которые умеют прибивать соответствие мак-адреса к подключенному порту и хоть меняй этот адрес - толку не будет. Но это дорого и больше каткит чисто для внутреннего корпоративного решения.
Нужно искать решение для грамотной авторизации, что бы уберечь свои ресурсы.

Да в свитчах сиско есть такая фича secure port filtering. Ее можно использовать для параноидальных энвайронментс. Но все равно можно подключиться к тому же порту с тем же (измененным) МАК-адресом. Ничего не спасет, короче. Можно правда везде encryption использовать, тогда ничего не поможет. Подключайся, не подключайся, все по фигу.

Такой уровень секьюрности разве для CIA... а у них в Риге вроде отделения еще нет

[Katz]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

Ну дык не все же клиенты используют DHCP!
Я вот вообще этот сервис не люблю, хотя на работе в силу традиции конторы приходится поддерживать.
Кстати MAC-адрес тоже поменять можно - многие платы позволяют это, так что если кто то знающий решит воспользоваться, то он отследит в сети чей нибудь MAC и IP и когда тот только отключится от сети, перенастроит свой сетевой интерфейс и сможет прорваться. То есть решение это действительно от ламеров. Если вы контролируете физическое подключение, то ещё можно поставить современные коммутаторы (Cisco например), которые умеют прибивать соответствие мак-адреса к подключенному порту и хоть меняй этот адрес - толку не будет. Но это дорого и больше каткит чисто для внутреннего корпоративного решения.
Нужно искать решение для грамотной авторизации, что бы уберечь свои ресурсы.

Да в свитчах сиско есть такая фича secure port filtering. Ее можно использовать для параноидальных энвайронментс. Но все равно можно подключиться к тому же порту с тем же (измененным) МАК-адресом. Ничего не спасет, короче. Можно правда везде encryption использовать, тогда ничего не поможет. Подключайся, не подключайся, все по фигу.

Такой уровень секьюрности разве для CIA... а у них в Риге вроде отделения еще нет

Я кажется понял чего ей надо. IPv6 (IPSec included) + DHCP server with MAC address bounded to IP.

[f_evgeny]

Зачем такие сложности?
Есть такая програмка arpwatch. Собирает MAC-адреса автоматически.
DHCP сервер дает возможность жестко привязать IP address to MAC address.

Ну дык не все же клиенты используют DHCP!
Я вот вообще этот сервис не люблю, хотя на работе в силу традиции конторы приходится поддерживать.
Кстати MAC-адрес тоже поменять можно - многие платы позволяют это, так что если кто то знающий решит воспользоваться, то он отследит в сети чей нибудь MAC и IP и когда тот только отключится от сети, перенастроит свой сетевой интерфейс и сможет прорваться. То есть решение это действительно от ламеров. Если вы контролируете физическое подключение, то ещё можно поставить современные коммутаторы (Cisco например), которые умеют прибивать соответствие мак-адреса к подключенному порту и хоть меняй этот адрес - толку не будет. Но это дорого и больше каткит чисто для внутреннего корпоративного решения.
Нужно искать решение для грамотной авторизации, что бы уберечь свои ресурсы.

Да в свитчах сиско есть такая фича secure port filtering. Ее можно использовать для параноидальных энвайронментс. Но все равно можно подключиться к тому же порту с тем же (измененным) МАК-адресом. Ничего не спасет, короче. Можно правда везде encryption использовать, тогда ничего не поможет. Подключайся, не подключайся, все по фигу.

Да тут ясное дело 100% не помогает привязка MAC к IP, так как это легко подсмотреть и подменить. В общем то, что я предлагал выше должно выглядеть так:
Неважно какой MAC или IP все строится вокруг авторизации.
1. При входе в сеть надо логинится в домен NT.
2. По логину надо на сервере запускать скрипт, который поднимет НАТ или маскарадинг, в зависимости от платформы, для IP, с которого залогинилсся пользователь.
3. Еще надо придумать, как убирать НАТ когда пользователь разлогинился. Думаю это решаемо.
4. Для линуксов/юниксов думаю можно замутить что нибудь на базе ssh или NIS
5. Если нужен только HTTP, можно посмотреть в google что нибудь типа squid+samba+pdc, ну в общем ясно.

[KYKAH]

Неважно какой MAC или IP все строится вокруг авторизации.
1. При входе в сеть надо логинится в домен NT.
2. По логину надо на сервере запускать скрипт, который поднимет НАТ или маскарадинг, в зависимости от платформы, для IP, с которого залогинилсся пользователь.
3. Еще надо придумать, как убирать НАТ когда пользователь разлогинился. Думаю это решаемо.

Изврат конкретный
Есть такай программка -- Checkpoint Firewall-1 называется...

[f_evgeny]

Неважно какой MAC или IP все строится вокруг авторизации.
1. При входе в сеть надо логинится в домен NT.
2. По логину надо на сервере запускать скрипт, который поднимет НАТ или маскарадинг, в зависимости от платформы, для IP, с которого залогинилсся пользователь.
3. Еще надо придумать, как убирать НАТ когда пользователь разлогинился. Думаю это решаемо.

Изврат конкретный
Есть такай программка -- Checkpoint Firewall-1 называется...

1.
2. Ну на самом деле это просто - пара строчек на shell.

[KYKAH]

Неважно какой MAC или IP все строится вокруг авторизации.
1. При входе в сеть надо логинится в домен NT.
2. По логину надо на сервере запускать скрипт, который поднимет НАТ или маскарадинг, в зависимости от платформы, для IP, с которого залогинилсся пользователь.
3. Еще надо придумать, как убирать НАТ когда пользователь разлогинился. Думаю это решаемо.

Изврат конкретный
Есть такай программка -- Checkpoint Firewall-1 называется...

1.
2. Ну на самом деле это просто - пара строчек на shell.

Правила будут неоптимальные

Хотя если нужна такая степень безопасности, то хрен с ними, с правилами.

[f_evgeny]

Неважно какой MAC или IP все строится вокруг авторизации.
1. При входе в сеть надо логинится в домен NT.
2. По логину надо на сервере запускать скрипт, который поднимет НАТ или маскарадинг, в зависимости от платформы, для IP, с которого залогинилсся пользователь.
3. Еще надо придумать, как убирать НАТ когда пользователь разлогинился. Думаю это решаемо.

Изврат конкретный
Есть такай программка -- Checkpoint Firewall-1 называется...

1.
2. Ну на самом деле это просто - пара строчек на shell.

Правила будут неоптимальные

Хотя если нужна такая степень безопасности, то хрен с ними, с правилами.

Мне, что-то более оптимальное для данных условий задачи ничего не придумывается. По моему здесь именно необходимый минимум.
1. Гарантию, что пользователь не подменен, в сетях TCP/IP может дать только авторизация.
2. На каждого пользователя нужно отдельное правило
Ну, конечно, можно заменить НАТ роутингом. Хотя как правило в интернет ходят обычно именно через НАТ.
Еще вариант - поковырять ssh, но там возможен неслабый дополнительный геморрой на клиентах.

[KYKAH]

Уважаемая Pukiite, проявите, пожалуйста, уважение к публике и дайте какой-либо feedback по поводу того, были ли решены проблемы.

[Pukite]

Планируется использовать следующие действия: http://www.unixfaq.ru/index.pl?req=qs&id=169

[KYKAH]

Планируется использовать следующие действия: http://www.unixfaq.ru/index.pl?req=qs&id=169

Хммм, 802.1x это интересно, надо бы изучить...