[mdk-re] RE: [mdk-re] Два вопроса

[mdk-re] RE: [mdk-re] Два вопроса

[Зуев Дмитрий Федорович]

>Есть 2 проги под названиями:
>1. poledit
>2. restriсk
>3. wintune
>С помощью них можно закрыть доступ к настройкам компа и к реестру.
Например, 
>может вообще исчезнуть пункт главного меню "Настройка". С помощю этих прог
я 
>в школе (!!!) заставил детей учиться, а не баловаться с Win95. Причем они 
>стоят уже 2-й год и ничего с ними не происходит.

Мне собственно постоянный IP адрес на рабочей станции нужен был для
следующей цели:
установил у себя дома радиокарту на сервере с линуксом для доступа в
интернет. Протянул в соседние подъезды локалку своим знакомым. Трафик в инет
считаю с помощью ipchains. Теперь появились желающие подключиться к нашей
сети, кто для игр кто для доступа в инет. Вот тут я и задумался. Когда мы в
четвером в сети были ни у кого и мысли не было что бы за счет другого инетом
попользоваться. А теперь если подключать ещё народ, то уже всё возможно. В
этой ситуации ни административные меры ни установка на рабочие станции
специальных програм не применишь. Остаётся только либо вообще все сервисы
кроме HTTP убрать, либо найти надёжный способ считать трафик от каждой
тачки. Буду благодарен за идею.

Дмитрий Зуев.

Re: [mdk-re] RE: [mdk-re] Двавопроса

[Sergei]

 4 Апрель 2001 08:00 Вы написали:
> Мне собственно постоянный IP адрес на рабочей станции нужен был для
> следующей цели:
> установил у себя дома радиокарту на сервере с линуксом для доступа в
> интернет. Протянул в соседние подъезды локалку своим знакомым. Трафик в
> инет считаю с помощью ipchains. Теперь появились желающие подключиться к
> нашей сети, кто для игр кто для доступа в инет. Вот тут я и задумался.
> Когда мы в четвером в сети были ни у кого и мысли не было что бы за счет
> другого инетом попользоваться. А теперь если подключать ещё народ, то уже
> всё возможно. В этой ситуации ни административные меры ни установка на
> рабочие станции специальных програм не применишь. Остаётся только либо
> вообще все сервисы кроме HTTP убрать, либо найти надёжный способ считать
> трафик от каждой тачки. Буду благодарен за идею.
Посмотрите про Fwctl, может поможет.
Также может помочь пакет iplog и ipchains.

-- 
С уважением, Епифанов Сергей

Re: [mdk-re] RE: [mdk-re] ä×Á ×ÏÐÒÏÓÁ

[Ivan Kudryashov]

Hello, Зуев Дмитрий Федорович!

04.04.2001 08:00:47, you wrote:

ЗДФ> Мне  собственно  постоянный IP адрес на рабочей станции нужен был
ЗДФ> для следующей цели: установил у себя дома радиокарту на сервере с
ЗДФ> линуксом  для  доступа  в  интернет. Протянул в соседние подъезды
ЗДФ> локалку  своим знакомым. Трафик в инет считаю с помощью ipchains.
ЗДФ> Теперь  появились желающие подключиться к нашей сети, кто для игр
ЗДФ> кто  для  доступа  в  инет.  Вот  тут  я  и задумался. Когда мы в
ЗДФ> четвером  в  сети  были  ни у кого и мысли не было что бы за счет
ЗДФ> другого  инетом  попользоваться.  А  теперь  если  подключать ещё
ЗДФ> народ,  то  уже всё возможно. В этой ситуации ни административные
ЗДФ> меры  ни  установка  на  рабочие  станции  специальных програм не
ЗДФ> применишь.  Остаётся  только  либо  вообще все сервисы кроме HTTP
ЗДФ> убрать,  либо  найти  надёжный  способ  считать  трафик от каждой
ЗДФ> тачки. Буду благодарен за идею.

Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
раздать   им   статические   IP,   написать  скрипт,  который  врубает
маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
обязан будет войти на сервер (можно заставить делать это через telnet,
или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
зарегистрированный  на  него. Естественно, обойти это можно, но только
путём  кражи  или подбора пароля, но надёжность пароля - головная боль
пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.

-------------------------------------------
С уважением, 
Ivan Kudryashov <jony@chat.ru> ICQ 1547081

[mdk-re] Re: [mdk-re] RE: [mdk-re] Два вопроса

[Волков Сергей]

----- Original Message -----
From: Ivan Kudryashov <jony@chat.ru>
To: Зуев Дмитрий Федорович <mandrake-russian@altlinux.ru>
Sent: Wednesday, April 04, 2001 9:13 AM
Subject: Re: [mdk-re] RE: [mdk-re] Два вопроса


> Hello, Зуев Дмитрий Федорович!
>
> 04.04.2001 08:00:47, you wrote:
>
> ЗДФ> Мне  собственно  постоянный IP адрес на рабочей станции нужен был
> ЗДФ> для следующей цели: установил у себя дома радиокарту на сервере с
> ЗДФ> линуксом  для  доступа  в  интернет. Протянул в соседние подъезды
> ЗДФ> локалку  своим знакомым. Трафик в инет считаю с помощью ipchains.
> ЗДФ> Теперь  появились желающие подключиться к нашей сети, кто для игр
> ЗДФ> кто  для  доступа  в  инет.  Вот  тут  я  и задумался. Когда мы в
> ЗДФ> четвером  в  сети  были  ни у кого и мысли не было что бы за счет
> ЗДФ> другого  инетом  попользоваться.  А  теперь  если  подключать ещё
> ЗДФ> народ,  то  уже всё возможно. В этой ситуации ни административные
> ЗДФ> меры  ни  установка  на  рабочие  станции  специальных програм не
> ЗДФ> применишь.  Остаётся  только  либо  вообще все сервисы кроме HTTP
> ЗДФ> убрать,  либо  найти  надёжный  способ  считать  трафик от каждой
> ЗДФ> тачки. Буду благодарен за идею.
>
> Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
> раздать   им   статические   IP,   написать  скрипт,  который  врубает
> маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
> вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
> обязан будет войти на сервер (можно заставить делать это через telnet,
> или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
> входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
> зарегистрированный  на  него. Естественно, обойти это можно, но только
> путём  кражи  или подбора пароля, но надёжность пароля - головная боль
> пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.
>
> -------------------------------------------
> С уважением,
> Ivan Kudryashov <jony@chat.ru> ICQ 1547081

Иван ты предлагаешь написать прогу которая грубо говоря является клиент
серверной и при условии правильной авторизации пользователь работает в инете
в противном случае нет
Просто я к чему -- около двух лет назад у меня вставала такая проблема в
общежитиях университета РУДН, тогда попытка решить эту задачу остановилась
на уровне списка разрешенных MAC адресов, однако народ быстро начал это дело
пытаться обойти, в добавок ко всему было выявлено что некоторые (особенно
старые) сетевые карты (ISA) могут самопроизвольно менять МАК адреса и так
далее, но тогда у меня не долшли руки писать прогу

Так что лучше написать прогу которая всех авторизует по некоторой базе??

Волков Сергей, vserge@menatepspb.msk.ru

Re: [mdk-re] RE: [mdk-re] ä×Á ×ÏÐÒÏÓÁ

[Alexandr Zhegallo]

> ЗДФ> Мне  собственно  постоянный IP адрес на рабочей станции нужен был
> ЗДФ> для следующей цели: установил у себя дома радиокарту на сервере с
> ЗДФ> линуксом  для  доступа  в  интернет. Протянул в соседние подъезды
> ЗДФ> локалку  своим знакомым. Трафик в инет считаю с помощью ipchains.
> ЗДФ> Теперь  появились желающие подключиться к нашей сети, кто для игр
> ЗДФ> кто  для  доступа  в  инет.  Вот  тут  я  и задумался. Когда мы в
> ЗДФ> четвером  в  сети  были  ни у кого и мысли не было что бы за счет
> ЗДФ> другого  инетом  попользоваться.  А  теперь  если  подключать ещё
> ЗДФ> народ,  то  уже всё возможно. В этой ситуации ни административные
> ЗДФ> меры  ни  установка  на  рабочие  станции  специальных програм не
> ЗДФ> применишь.  Остаётся  только  либо  вообще все сервисы кроме HTTP
> ЗДФ> убрать,  либо  найти  надёжный  способ  считать  трафик от каждой
> ЗДФ> тачки. Буду благодарен за идею.
> 
> Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
> раздать   им   статические   IP,   написать  скрипт,  который  врубает
> маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
> вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
> обязан будет войти на сервер (можно заставить делать это через telnet,
> или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
> входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
> зарегистрированный  на  него. Естественно, обойти это можно, но только
> путём  кражи  или подбора пароля, но надёжность пароля - головная боль
> пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.
Вот только не через telnet ! ssh либо ssl ,IMHO , иначе в некоммутируемой сети 
пароль можно просто посмотреть любым снифером .

Re: [mdk-re] Re: [mdk-re] RE: [mdk-re] ä×Á ×ÏÐÒÏÓÁ

[Ivan Kudryashov]

Hello, Волков Сергей!

04.04.2001 09:16:20, you wrote:


>> Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
>> раздать   им   статические   IP,   написать  скрипт,  который  врубает
>> маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
>> вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
>> обязан будет войти на сервер (можно заставить делать это через telnet,
>> или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
>> входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
>> зарегистрированный  на  него. Естественно, обойти это можно, но только
>> путём  кражи  или подбора пароля, но надёжность пароля - головная боль
>> пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.

ВС> Иван ты предлагаешь написать прогу которая грубо говоря является клиент
ВС> серверной и при условии правильной авторизации пользователь работает в инете
ВС> в противном случае нет

Да.  Прошу  пардону  за  некоторую сумбурность изложения, я сегодня по
дороге на работу ногу подвернул, болит, зараза, соображать мешает...

ВС> Просто  я  к  чему  --  около двух лет назад у меня вставала такая
ВС> проблема  в общежитиях университета РУДН, тогда попытка решить эту
ВС> задачу  остановилась  на  уровне  списка  разрешенных MAC адресов,
ВС> однако  народ  быстро начал это дело пытаться обойти, в добавок ко
ВС> всему  было выявлено что некоторые (особенно старые) сетевые карты
ВС> (ISA) могут самопроизвольно менять МАК адреса и так

Про  что  я и говорю. В принципе, вопрос можно поставить так: можно ли
как-то  идентифицировать  компьютер, подключенный к сети, при условии,
что  его  пользователь  может  произвольным образом менять _любые_ его
настройки?  Общий  ответ  на  этот  вопрос:  если сетка - Ethernet, то
нельзя.  Если  витая  пара,  то  можно  попробовать  сделать  проверку
авторизации  на уровне хабов, но это довольно нетривиальная задача. Я,
например,  даже  отдалённо  не  представляю,  как за неё браться (хотя
способ, конечно, есть, надо в доках копаться).

По  этой  причине  единственный  выход  -  авторизовать  не  комп,   а
пользователя.  Кстати, в win-сетях это можно сделать на уровне домена.
Очевидный,  дедовский  способ  авторизации  - заставить ввести пароль.
Дальше всё понятно.

Простейший способ (на мой взгляд, для маленькой сети оптимальный) - не
писать собственные проги, а просто прописать поднятие маскарадинга для
IP,  зарегистрированного  на  пользователя,  в его входных скриптах. И
отключение,  соответственно,  при  выходе. Естественно, надо запретить
редактирование  этих скриптов пользователю. Надо в инет - зайди по ssh
или  telnet,  введи  пароль  -  и всё работает. Как только вышел - всё
отрубилось.  Единственное  неудобство  -  болтающееся на десктопе окно
телнета.  Но это не страшно, ИМХО. При таком способе любые манипуляции
с  IP, MAC - адресами, даже точкой подключения к сети, ничего не дают.
Если  пользователь изменит данную ему настройку, он просто не выйдет в
инет  (ну,  изменил  ты IP на соседский, пароль-то свой остался... так
что  при  входе поднимется не его, а твой IP). Надёжность этой системы
ограничивается   только   надёжностью   криптозащиты  и  корректностью
действий  пользователей  по  защите своих паролей от компрометации. Но
тут  надо  просто  договориться,  что  каждый  будет  платить столько,
сколько  отработано  от  его имени, и никаких разговоров на тему "я не
работал, меня хакнули". Хакнули - значит хреново пароль бережёшь.

Если  предусматривать дальнейшее расширение сети - можно действительно
написать  CS-программку,  которая  будет  заниматься  всеми описанными
делами на клиенте. Но при объёме в десяток - другой пользователей это,
ИМХО, излишняя трата времени и сил.

-------------------------------------------
С уважением, 
Ivan Kudryashov <jony@chat.ru> ICQ 1547081

Re[2]: [mdk-re] RE: [mdk-re] ä×Á ×ÏÐÒÏÓÁ

[Ivan Kudryashov]

Hello, Alexandr Zhegallo!

04.04.2001 09:52:12, you wrote:

AZ> Вот  только  не  через  telnet  !  ssh  либо  ssl  ,IMHO , иначе в
AZ> некоммутируемой сети пароль можно просто посмотреть любым снифером

Согласен.

-------------------------------------------
С уважением, 
Ivan Kudryashov <jony@chat.ru> ICQ 1547081

[mdk-re] Re: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два вопроса

[Волков Сергей]

----- Original Message -----
From: Ivan Kudryashov <jony@chat.ru>
To: Волков Сергей <mandrake-russian@altlinux.ru>
Sent: Wednesday, April 04, 2001 9:58 AM
Subject: Re: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два вопроса


> Hello, Волков Сергей!
>
> 04.04.2001 09:16:20, you wrote:
>
>
> >> Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
> >> раздать   им   статические   IP,   написать  скрипт,  который  врубает
> >> маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
> >> вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
> >> обязан будет войти на сервер (можно заставить делать это через telnet,
> >> или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
> >> входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
> >> зарегистрированный  на  него. Естественно, обойти это можно, но только
> >> путём  кражи  или подбора пароля, но надёжность пароля - головная боль
> >> пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.
>
> ВС> Иван ты предлагаешь написать прогу которая грубо говоря является
клиент
> ВС> серверной и при условии правильной авторизации пользователь работает в
инете
> ВС> в противном случае нет
>
> Да.  Прошу  пардону  за  некоторую сумбурность изложения, я сегодня по
> дороге на работу ногу подвернул, болит, зараза, соображать мешает...
>
> ВС> Просто  я  к  чему  --  около двух лет назад у меня вставала такая
> ВС> проблема  в общежитиях университета РУДН, тогда попытка решить эту
> ВС> задачу  остановилась  на  уровне  списка  разрешенных MAC адресов,
> ВС> однако  народ  быстро начал это дело пытаться обойти, в добавок ко
> ВС> всему  было выявлено что некоторые (особенно старые) сетевые карты
> ВС> (ISA) могут самопроизвольно менять МАК адреса и так
>
> Про  что  я и говорю. В принципе, вопрос можно поставить так: можно ли
> как-то  идентифицировать  компьютер, подключенный к сети, при условии,
> что  его  пользователь  может  произвольным образом менять _любые_ его
> настройки?  Общий  ответ  на  этот  вопрос:  если сетка - Ethernet, то
> нельзя.  Если  витая  пара,  то  можно  попробовать  сделать  проверку
> авторизации  на уровне хабов, но это довольно нетривиальная задача. Я,
> например,  даже  отдалённо  не  представляю,  как за неё браться (хотя
> способ, конечно, есть, надо в доках копаться).
ну не знаю хаб устройство тупое и ему не прикажешь отдавать все адреса и
даже не обратишся к нему :((

>
> По  этой  причине  единственный  выход  -  авторизовать  не  комп,   а
> пользователя.  Кстати, в win-сетях это можно сделать на уровне домена.
> Очевидный,  дедовский  способ  авторизации  - заставить ввести пароль.
> Дальше всё понятно.
>
это обходится нажатием простого ESC, однако согласен что по умолчанию всем
пользователям присоить по DHCP можно принудительно левую сеть с роутингом в
никуда

> Простейший способ (на мой взгляд, для маленькой сети оптимальный) - не
> писать собственные проги, а просто прописать поднятие маскарадинга для
> IP,  зарегистрированного  на  пользователя,  в его входных скриптах. И
> отключение,  соответственно,  при  выходе. Естественно, надо запретить
> редактирование  этих скриптов пользователю. Надо в инет - зайди по ssh

а как менять на ходу IP если пользователь вошел с другого IP address

> или  telnet,  введи  пароль  -  и всё работает. Как только вышел - всё
> отрубилось.  Единственное  неудобство  -  болтающееся на десктопе окно
> телнета.  Но это не страшно, ИМХО. При таком способе любые манипуляции
> с  IP, MAC - адресами, даже точкой подключения к сети, ничего не дают.
> Если  пользователь изменит данную ему настройку, он просто не выйдет в
> инет  (ну,  изменил  ты IP на соседский, пароль-то свой остался... так
> что  при  входе поднимется не его, а твой IP). Надёжность этой системы
> ограничивается   только   надёжностью   криптозащиты  и  корректностью
> действий  пользователей  по  защите своих паролей от компрометации. Но
> тут  надо  просто  договориться,  что  каждый  будет  платить столько,
> сколько  отработано  от  его имени, и никаких разговоров на тему "я не
> работал, меня хакнули". Хакнули - значит хреново пароль бережёшь.
>
> Если  предусматривать дальнейшее расширение сети - можно действительно
> написать  CS-программку,  которая  будет  заниматься  всеми описанными
> делами на клиенте. Но при объёме в десяток - другой пользователей это,
> ИМХО, излишняя трата времени и сил.

а еще эта задача похоже очень актуальна для домашних сетей, которых так
много сейчас??
кто знает как она сейчас решается???
>
> -------------------------------------------
> С уважением,
> Ivan Kudryashov <jony@chat.ru> ICQ 1547081
>
>
>
> _______________________________________________
> Mandrake-russian mailing list
> Mandrake-russian@altlinux.ru
> http://altlinux.ru/mailman/listinfo/mandrake-russian
>

Re: [mdk-re] Re: [mdk-re] Re: [mdk-re] RE: [mdk-re] ä×Á ×ÏÐÒÏÓÁ

[Ivan Kudryashov]

Hello, Волков!

Wednesday, April 04, 2001, 10:21:22 AM, you wrote:

ВС> ну не знаю хаб устройство тупое и ему не прикажешь отдавать все адреса и
ВС> даже не обратишся к нему :((

Ну,  хабы  бывают разные... И потом, дело здесь не в устройстстве, а в
структуре  сети, которая позволяет определить физический шнурок, через
который идёт соединение. А в случае с Ethernet - фигушки...

>> По  этой  причине  единственный  выход  -  авторизовать  не  комп,   а
>> пользователя.  Кстати, в win-сетях это можно сделать на уровне домена.
>> Очевидный,  дедовский  способ  авторизации  - заставить ввести пароль.
>> Дальше всё понятно.
>>
ВС> это обходится нажатием простого ESC, однако согласен что по умолчанию всем

Я  имею  в  виду  систему с авторизацией пользователя через контроллер
домена,  которая  обычно  применяется  в  сетях  с  сервером  на  NT и
станциями  на Win95/98. Отключение авторизации через контроллер домена
(или отказ от неё нажатием ESC) автоматически отрубает пользователя от
всех ограниченных этим контроллером ресурсов сети.

ВС> пользователям присоить по DHCP можно принудительно левую сеть с роутингом в
ВС> никуда

>> Простейший способ (на мой взгляд, для маленькой сети оптимальный) - не
>> писать собственные проги, а просто прописать поднятие маскарадинга для
>> IP,  зарегистрированного  на  пользователя,  в его входных скриптах. И
>> отключение,  соответственно,  при  выходе. Естественно, надо запретить
>> редактирование  этих скриптов пользователю. Надо в инет - зайди по ssh

ВС> а как менять на ходу IP если пользователь вошел с другого IP address

А  зачем  его  на ходу менять? Задача - домашняя (подъездная) сеть. IP
раздаются  статические,  каждому  свой.  При  авторизации  поднимается
именно  тот IP, который приписан к данному конкретному пользователю. В
результате  невозможно  ни  поставить  на  свой комп чужой IP, ни даже
поработать   с   другого   компа,  не  поставив  там  _свой_  IP,  что
автоматически делает пользователя плательщиком. Что и требовалось.

ВС> а  еще  эта  задача  похоже  очень  актуальна  для домашних сетей,
ВС> которых так много сейчас?? кто знает как она сейчас решается???

В  домашних  сетях  это,  как  раз,  ИМХО,  совершенно  неактуально. В
пределах  семьи  можно  чисто административными методами принудительно
установить  на  все  машины  софт,  который  обеспечит  авторизацию. В
описанных  случаях  (подъезд,  общага)  ситуация другая: нет доступа к
клиентским  машинам  и  практически  ничего  (кроме  отключения      и
мордобития) невозможно сделать с "хакерами". А как решается - MS для
этого и предлагает механизм авторизации через сервер, про который я
уже дважды говорил. А в остальном - тишина.

--------------------------------------------
С уважением, 
Ivan Kudryashov <jony@chat.ru> ICQ: 1547081

Re: [mdk-re] Re[2]: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два в опроса

[Mikhail Nikitin]

> MN> Мысль которая приходит в голову:
>
> MN> Авторизация парольным методом здесь никоим образом не проведешь,
> MN> кроме использования внешних серверов (типа NT domain controller).
>
> Можно к гейту ход под принудительный IPsec поставить. Некая проблема
> будет заключаться в том, что несправедливо тарифицировать доступ к
> своему прокси, не порождающий внешнего трафика (по крайней мере, по
> тем же тарифам, что и доступ наружу), а биллинговой системы, умеющей
> это разделять, я не знаю.

Да хоть PGPnet. Дело в том что пока нет FreeS/WAN под 2.4.x (или я отстал от 
жизни?). Btw, изо всех ли систем можно наладить IPSec с head-server под Linux?
(просто интересно). Траффик локала и внешней сети умеет хорошо разделять ntop.

> MN> ntop (www.ntop.org). С теми кто подменяет MAC/IP - бороться
> административными MN> мерами (никто не будет рисковать отключением от сетки
> из-за $5-$10)
>
> MN> Такой метод подсчета траффика показал отличные результаты при
> MN> практическом применении в сетке где я был админом....
>
> Э, нет, административные методы работают в административной ситуации,
> т.е. внутри фирмы, а речь, вроде, шла о домовой сети.

Вот я как раз про дом и писал... в офисе можно человека наказать деньгами а 
здесь - просто отключить от сети без права переподключения. 
(Т.е. придумать нечто вроде policy)

[mdk-re] Re: [mdk-re] RE: [mdk-re] Два вопроса

[Ivan Zakharyaschev]

	Hello!

On Wed, 4 Apr 2001, Ivan Kudryashov wrote:

> Hello, Зуев Дмитрий Федорович!
>
> 04.04.2001 08:00:47, you wrote:
>
> ЗДФ> Мне  собственно  постоянный IP адрес на рабочей станции нужен был
> ЗДФ> для следующей цели: установил у себя дома радиокарту на сервере с
> ЗДФ> линуксом  для  доступа  в  интернет. Протянул в соседние подъезды
> ЗДФ> локалку  своим знакомым. Трафик в инет считаю с помощью ipchains.
> ЗДФ> Теперь  появились желающие подключиться к нашей сети, кто для игр
> ЗДФ> кто  для  доступа  в  инет.  Вот  тут  я  и задумался. Когда мы в
> ЗДФ> четвером  в  сети  были  ни у кого и мысли не было что бы за счет
> ЗДФ> другого  инетом  попользоваться.  А  теперь  если  подключать ещё
> ЗДФ> народ,  то  уже всё возможно. В этой ситуации ни административные
> ЗДФ> меры  ни  установка  на  рабочие  станции  специальных програм не
> ЗДФ> применишь.  Остаётся  только  либо  вообще все сервисы кроме HTTP
> ЗДФ> убрать,  либо  найти  надёжный  способ  считать  трафик от каждой
> ЗДФ> тачки. Буду благодарен за идею.

Предупреждаю: я никогда сетями не занимался, поэтому все, что я скажу,
просто домыслы. Как-то слышал такое название: PPP over Ethernet. По-моему,
эта вещь во многом должна быть похожа на описанное ниже (по тому, как при
взгляде со стороны будет работать), только сделанная специально для таких
задач. Ну а внутри устроена по-другому. Я себе это в действие представляю
так: пусть локальная сеть сама по себе живет, а на случай, если кому-то
надо в Интернет, для него заводится на сервере ppp-пользовательи он,
логинясь туда, получает IP и работает в Интернете. При этом весь его
внешний трафик идет чеерз ppp-соединение (поверх локалки). Не знаю только,
как такой способ соединения будет поддерживаться на клиентской стороне.

> Зарегистрировать   всех  инет-юзеров  на  сервере  как  пользователей,
> раздать   им   статические   IP,   написать  скрипт,  который  врубает
> маскарадинг  для  IP  пользователя  при  входе  в  систему и автоматом
> вырубает  его  же  при  выходе.  Тогда для работы в инете пользователь
> обязан будет войти на сервер (можно заставить делать это через telnet,
> или  ещё как-нибудь). Соответственно, будет безразлично, с какой тачки
> входит   пользователь,   но   при  его  входе  будет  подниматься  IP,
> зарегистрированный  на  него. Естественно, обойти это можно, но только
> путём  кражи  или подбора пароля, но надёжность пароля - головная боль
> пользователя. И, кстати, DHCP в такой ситуации не нужен вообще.

PS В принципе, PPP-соединение нормально работает через терминал (например,
ssh, telnet), поэтому сейчас, осознав это, я даже не понимаю, зачем
специальное название придумали: PPP over Ethernet. Возможно, там терминал
не используется...

Best reagrds,
Ivan.

Re: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два в опроса

[Mikhail Nikitin]

Мысль которая приходит в голову:

Авторизация парольным методом здесь никоим образом не проведешь,
кроме использования внешних серверов (типа NT domain controller). 
Вопрос в том - нужна ли данная авторизация вообще? Если нужна -
то, думаю поможет Socks-Proxy с авторизацией и Squid с авторизацией.
Если основной траффик предполагается от игр (типа Counter-Strike ^:)
то считать просто траффик от фиксированного IP (без DHCP) с помощью
ntop (www.ntop.org). С теми кто подменяет MAC/IP - бороться административными
мерами (никто не будет рисковать отключением от сетки из-за $5-$10)

Такой метод подсчета траффика показал отличные результаты при
практическом применении в сетке где я был админом....

[mdk-re] Re[2]: [mdk-re] Re[2]: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два в опроса

[Maksim Otstavnov]

Hello Mikhail,

Wednesday, April 04, 2001, 9:05:11 PM, you wrote:

>> Можно к гейту ход под принудительный IPsec поставить. Некая проблема
>> будет заключаться в том, что несправедливо тарифицировать доступ к
>> своему прокси, не порождающий внешнего трафика (по крайней мере, по
>> тем же тарифам, что и доступ наружу), а биллинговой системы, умеющей
>> это разделять, я не знаю.

MN> Да хоть PGPnet.

А где там биллинг???

MN> Дело в том что пока нет FreeS/WAN под 2.4.x (или я отстал от
MN> жизни?). Btw, изо всех ли систем можно наладить IPSec с head-server под Linux?
MN> (просто интересно).

Надо полагать, что изо всех, реализующих IPsec. FreeS/WAN очень хорошо
проходит (неформальные) тесты на стандартность.

MN> Траффик локала и внешней сети умеет хорошо разделять ntop.

Вопрос был: в каком месте делить?

>> Э, нет, административные методы работают в административной ситуации,
>> т.е. внутри фирмы, а речь, вроде, шла о домовой сети.

MN> Вот я как раз про дом и писал... в офисе можно человека наказать деньгами а 
MN> здесь - просто отключить от сети без права переподключения.
MN> (Т.е. придумать нечто вроде policy)

Рисковано такое делать, не имея хотя бы теоретической процедуры
разрешения конфликта. Т.е. рано или поздно или побьют, или в суд
потащат, если голословно обвинять в нарушении policy.

-- 
-- Maksim

[mdk-re] Re[2]: [mdk-re] Re: [mdk-re] RE: [mdk-re] Два в опроса

[Maksim Otstavnov]

Hello Mikhail,

Wednesday, April 04, 2001, 6:57:50 PM, you wrote:

MN> Мысль которая приходит в голову:

MN> Авторизация парольным методом здесь никоим образом не проведешь,
MN> кроме использования внешних серверов (типа NT domain controller).

Можно к гейту ход под принудительный IPsec поставить. Некая проблема
будет заключаться в том, что несправедливо тарифицировать доступ к
своему прокси, не порождающий внешнего трафика (по крайней мере, по
тем же тарифам, что и доступ наружу), а биллинговой системы, умеющей
это разделять, я не знаю.

MN> ntop (www.ntop.org). С теми кто подменяет MAC/IP - бороться административными
MN> мерами (никто не будет рисковать отключением от сетки из-за $5-$10)

MN> Такой метод подсчета траффика показал отличные результаты при
MN> практическом применении в сетке где я был админом....

Э, нет, административные методы работают в административной ситуации,
т.е. внутри фирмы, а речь, вроде, шла о домовой сети.

-- 
-- Maksim

[mdk-re] Re: [mdk-re] Два вопроса

[Mikhail Zabaluev]

Hello Волков,

On Wed, Apr 04, 2001 at 10:21 +0400, Волков Сергей wrote:
>
> > По  этой  причине  единственный  выход  -  авторизовать  не  комп,   а
> > пользователя.  Кстати, в win-сетях это можно сделать на уровне домена.
> > Очевидный,  дедовский  способ  авторизации  - заставить ввести пароль.
> > Дальше всё понятно.
> >
> это обходится нажатием простого ESC, однако согласен что по умолчанию всем
> пользователям присоить по DHCP можно принудительно левую сеть с роутингом в
> никуда
> 
> > Простейший способ (на мой взгляд, для маленькой сети оптимальный) - не
> > писать собственные проги, а просто прописать поднятие маскарадинга для
> > IP,  зарегистрированного  на  пользователя,  в его входных скриптах. И
> > отключение,  соответственно,  при  выходе. Естественно, надо запретить
> > редактирование  этих скриптов пользователю. Надо в инет - зайди по ssh
> 
> а как менять на ходу IP если пользователь вошел с другого IP address
> 
> > или  telnet,  введи  пароль  -  и всё работает. Как только вышел - всё
> > отрубилось.  Единственное  неудобство  -  болтающееся на десктопе окно
> > телнета.  Но это не страшно, ИМХО. При таком способе любые манипуляции
> > с  IP, MAC - адресами, даже точкой подключения к сети, ничего не дают.
> > Если  пользователь изменит данную ему настройку, он просто не выйдет в
> > инет  (ну,  изменил  ты IP на соседский, пароль-то свой остался... так
> > что  при  входе поднимется не его, а твой IP). Надёжность этой системы
> > ограничивается   только   надёжностью   криптозащиты  и  корректностью
> > действий  пользователей  по  защите своих паролей от компрометации. Но
> > тут  надо  просто  договориться,  что  каждый  будет  платить столько,
> > сколько  отработано  от  его имени, и никаких разговоров на тему "я не
> > работал, меня хакнули". Хакнули - значит хреново пароль бережёшь.
> >
> > Если  предусматривать дальнейшее расширение сети - можно действительно
> > написать  CS-программку,  которая  будет  заниматься  всеми описанными
> > делами на клиенте. Но при объёме в десяток - другой пользователей это,
> > ИМХО, излишняя трата времени и сил.
> 
> а еще эта задача похоже очень актуальна для домашних сетей, которых так
> много сейчас??
> кто знает как она сейчас решается???

Насколько я знаю, в коммерческих сетях масштаба микрорайона (о где вы,
где вы, эти микрорайоны) решаются сразу две проблемы - авторизация и
исключение "нюхачей" - путем установки IPSec или подобных
защищенных соединений между машиной клиента и провайдерской точкой
доступа и accounting'а. Конечно, потребуется поддержка на стороне клиента,
но в нашем любимом дистрибутиве этого добра в ядре хватает :)

-- 
Stay tuned,
  MhZ
___________
Moderation is a fatal thing.  Nothing succeeds like excess.
		-- Oscar Wilde

[mdk-re] Re: [mdk-re] Re: [mdk-re] Два вопроса

[Волков Сергей]

----- Original Message -----
From: Mikhail Zabaluev <mookid@sigent.ru>
To: <mandrake-russian@altlinux.ru>
Sent: Wednesday, April 04, 2001 12:38 PM
Subject: [mdk-re] Re: [mdk-re] Два вопроса


> Hello Волков,
>
> On Wed, Apr 04, 2001 at 10:21 +0400, Волков Сергей wrote:
> >
> > > По  этой  причине  единственный  выход  -  авторизовать  не  комп,   а
> > > пользователя.  Кстати, в win-сетях это можно сделать на уровне домена.
> > > Очевидный,  дедовский  способ  авторизации  - заставить ввести пароль.
> > > Дальше всё понятно.
> > >
> > это обходится нажатием простого ESC, однако согласен что по умолчанию
всем
> > пользователям присоить по DHCP можно принудительно левую сеть с
роутингом в
> > никуда
> >
> > > Простейший способ (на мой взгляд, для маленькой сети оптимальный) - не
> > > писать собственные проги, а просто прописать поднятие маскарадинга для
> > > IP,  зарегистрированного  на  пользователя,  в его входных скриптах. И
> > > отключение,  соответственно,  при  выходе. Естественно, надо запретить
> > > редактирование  этих скриптов пользователю. Надо в инет - зайди по ssh
> >
> > а как менять на ходу IP если пользователь вошел с другого IP address
> >
> > > или  telnet,  введи  пароль  -  и всё работает. Как только вышел - всё
> > > отрубилось.  Единственное  неудобство  -  болтающееся на десктопе окно
> > > телнета.  Но это не страшно, ИМХО. При таком способе любые манипуляции
> > > с  IP, MAC - адресами, даже точкой подключения к сети, ничего не дают.
> > > Если  пользователь изменит данную ему настройку, он просто не выйдет в
> > > инет  (ну,  изменил  ты IP на соседский, пароль-то свой остался... так
> > > что  при  входе поднимется не его, а твой IP). Надёжность этой системы
> > > ограничивается   только   надёжностью   криптозащиты  и  корректностью
> > > действий  пользователей  по  защите своих паролей от компрометации. Но
> > > тут  надо  просто  договориться,  что  каждый  будет  платить столько,
> > > сколько  отработано  от  его имени, и никаких разговоров на тему "я не
> > > работал, меня хакнули". Хакнули - значит хреново пароль бережёшь.
> > >
> > > Если  предусматривать дальнейшее расширение сети - можно действительно
> > > написать  CS-программку,  которая  будет  заниматься  всеми описанными
> > > делами на клиенте. Но при объёме в десяток - другой пользователей это,
> > > ИМХО, излишняя трата времени и сил.
> >
> > а еще эта задача похоже очень актуальна для домашних сетей, которых так
> > много сейчас??
> > кто знает как она сейчас решается???
>
> Насколько я знаю, в коммерческих сетях масштаба микрорайона (о где вы,
> где вы, эти микрорайоны) решаются сразу две проблемы - авторизация и
> исключение "нюхачей" - путем установки IPSec или подобных
> защищенных соединений между машиной клиента и провайдерской точкой
> доступа и accounting'а. Конечно, потребуется поддержка на стороне клиента,
> но в нашем любимом дистрибутиве этого добра в ядре хватает :)
>
> --
> Stay tuned,
>   MhZ
А глупая вида как с ней быть как к ней прикрутить такую штуку и если можно
по подробенне про структуру соединения ??