контроль mac адреса....

[-anton-]

Народ помогите советом, как можно контролировать связь IP<-->mac, есть сеть, в которой порядка 40 машин, IP адреса прописаны руками, все машины ходять в инет через шлюз, как можно контролировать не только IP  адреса и запрещать определённые ресурсы, но и mac адрес, ну например если пользователь поменял IP, то чтобы он не смог выходить в инет. Ну и можно ли всё это делать в ipfw?

[visual]

Народ помогите советом, как можно контролировать связь IP<-->mac

[snapback]8675[/snapback]

сменить mac на сетевой карточке плевое дело. используй port security на свитчах, если они у тебя управляемые. иначе смотри в сторону arpwatch.

[Alloy]

man arp

arp -S 192.168.1.1 00:XX:XX:XX:XX:XX
arp -S 192.168.1.2 00:YY:YY:YY:YY:YY
....
# кому низя
arp -S 192.168.1.41 00:00:00:00:00:00
arp -S 192.168.1.42 00:00:00:00:00:00

...
arp -S 192.168.1.254 00:00:00:00:00:00

[visual]

man arp
arp -S 192.168.1.1 00:XX:XX:XX:XX:XX
arp -S 192.168.1.2 00:YY:YY:YY:YY:YY

[snapback]8685[/snapback]

что совершенно не спасает от "умников", которые меняя IP, меняют и MAC.

[-ud-]

либо управляемые коммутаторы либо pppoe

[Alloy]

начинать надо с простого,
не у всех есть управляемые коммутаторы.

IPsec еще есть, policy покрутить нужным образом и ключи раздать.

[visual]

начинать надо с простого,
не у всех есть управляемые коммутаторы.

если это домашняя сеть, то согласен. их зачастую строят на всяком хламе. не буду называть "бренды", чтобы никого не обидеть

IPsec еще есть, policy покрутить нужным образом и ключи раздать.

[snapback]8695[/snapback]

опять же, если это домашняя сетка, то машинка выполняющая роль шлюза должна иметь приличные вычислительные возможности, чтобы потянуть несколько десятков vpn-ов на 100 мбит/сек каждый. а если вспомнить что на таких машинках крутится полный комплект сетевых сервисов (dns, dhcp, samba, ftp, web, billing, etc.), то нагрузка в виде vpn сервера с обозначенными ранее требованиями, может стать непосильной ношей. imho лучше сразу вложиться в нормальную инфраструктуру. начать хотя бы с 3Com® Baseline Switch 2226 Plus, который реально купить за 220-240 баксов.

[-ud-]

начинать надо с простого,
не у всех есть управляемые коммутаторы.

Вот управляемые коммутаторы это как раз самое простое
от 200$ за 26 портов и 2 гигабита думаю не деньги если вы не лютики собираете, а предоставляете услуги.

[Alloy]

опять же, если это домашняя сетка, то машинка выполняющая роль шлюза должна иметь приличные вычислительные возможности, чтобы потянуть несколько десятков vpn-ов на 100 мбит/сек каждый.

про VPN я не говорил,
я говорит про тупую проверку подлинности IP с помощью AH IPsec,
туннелирование и шифрование не нужно.

http://en.wikipedia.org/wiki/IPsec

[visual]

про VPN я не говорил,
я говорит про тупую проверку подлинности IP с помощью AH IPsec,
туннелирование и шифрование не нужно.
http://en.wikipedia.org/wiki/IPsec

[snapback]8709[/snapback]

м.б. я чего-то не понимаю, покажи pls рабочий вариант, при котором шлюз "G" будет проверять проверять аутентичность заголовков в пакетах идущих от клиента "С" к серверу "S": С --> G --> S. если я правильно понимаю, то G не будет ничего проверять, если пакет адресован не ему, т.к. "IPsec uses a cryptographic checksum that incorporates a shared secret key known only to the two communicating IPsec peers". поправь pls, если я не прав.

[Alloy]

м.б. я чего-то не понимаю, покажи pls рабочий вариант, при котором шлюз "G" будет проверять проверять аутентичность заголовков в пакетах идущих от клиента "С" к серверу "S": С --> G --> S. если я правильно понимаю, то G не будет ничего проверять, если пакет адресован не ему, т.к. "IPsec uses a cryptographic checksum that incorporates a shared secret key known only to the two communicating IPsec peers". поправь pls, если я не прав.

[snapback]8713[/snapback]

все правильно понимаешь.
рабочий вариант, когда до S ему никто не даст дойти (с фейковыми IP - тем более), только до G, а дальше socks, http proxy, etc с ограничением на *forum*.*, *sex*.* и *ads*.*

[visual]

все правильно понимаешь.
рабочий вариант, когда до S ему никто не даст дойти (с фейковыми IP - тем более), только до G, а дальше socks, http proxy, etc с ограничением на *forum*.*, *sex*.* и *ads*.*

[snapback]8716[/snapback]

такой подход не применишь в домашней сети, народ из такой сети просто побежит.
P.S. а фейковые адреса никто не мешает маскарадить.
P.S.S. а если речь шла о сети предприятия, и эта сеть построена на неуправляемых свитчах... это извините п#$%ц.

[nuclight]

Альтернатива VPN и управляемым свитчам - самодельная аутентификация юзеров по логину/паролю, с разрешением доступа в файрволе. Во фре начиная с 5.3 есть пришедший из Openbsd файрвол pf, в нем есть подобная тулзень - типа шелл, пока ssh-сессия с роутером держится, интернет у юзера работает. Смотреть в сторону man authpf и гугля :)

[visual]

Альтернатива VPN и управляемым свитчам - самодельная аутентификация юзеров по логину/паролю, с разрешением доступа в файрволе. Во фре начиная с 5.3 есть пришедший из Openbsd файрвол pf, в нем есть подобная тулзень - типа шелл, пока ssh-сессия с роутером держится, интернет у юзера работает. Смотреть в сторону man authpf и гугля

[snapback]8757[/snapback]

при этом пользователи, держащие на домашних машинках ftp/web/etc, идут лесом. сервисы живущие сами по себе, не сделают аутентификацию на firewall-е.

[demiurg]

Альтернатива VPN и управляемым свитчам - самодельная аутентификация юзеров по логину/паролю, с разрешением доступа в файрволе. Во фре начиная с 5.3 есть пришедший из Openbsd файрвол pf, в нем есть подобная тулзень - типа шелл, пока ssh-сессия с роутером держится, интернет у юзера работает. Смотреть в сторону man authpf и гугля

[snapback]8757[/snapback]

Очень похоже на велосипед с квадратными колесами.
Чего только люди не придумают.....