Собственно столкнулся с проблемой. Начальство хочет в любой момент времени знать - кто, куда и зачем ходил, даже внутри локальной сети. Можно ли такое организовать? Посмотрел в сторону sflow, но по ходу он не обеспечит такой детальной статистики.Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство хочет знать - кто с 13 до 14 обращался на эти порты. Т.е. надо фиксировать даже единичный случай.
> Собственно столкнулся с проблемой. Начальство хочет в любой момент времени знать -
> кто, куда и зачем ходил, даже внутри локальной сети. Можно ли
> такое организовать? Посмотрел в сторону sflow, но по ходу он не
> обеспечит такой детальной статистики.
> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
> хочет знать - кто с 13 до 14 обращался на эти
> порты. Т.е. надо фиксировать даже единичный случай.Бюджетный вариант - всех загнать в ВПН и снимать с впн гейта все инфомрацию куда ходили
Альтернативный вариант, подключить всех клиентов в отдельным портам на очень умных свичах с снимать потоки с каждого порта в отдельности.
> Бюджетный вариант - всех загнать в ВПН и снимать с впн гейта
> все инфомрацию куда ходилиот vpn больше неудобства, чем пользы.
> Альтернативный вариант, подключить всех клиентов в отдельным портам на очень умных свичах с снимать потоки с каждого порта в отдельности.
имеется ввиду sflow/netflow?
Ни netflow, ни sflow не смогут ответить на вопрос, который Вами поставлен в первом сообщении. Да и "куда" ходил пользователь - НетФлоу тоже "отвечает" довольно посредственно. Ибо выдает данные только L3.
> Ни netflow, ни sflow не смогут ответить на вопрос, который Вами поставлен
> в первом сообщении. Да и "куда" ходил пользователь - НетФлоу тоже
> "отвечает" довольно посредственно. Ибо выдает данные только L3.мне как бы L3 достаточно ;)
> Ни netflow, ни sflow не смогут ответить на вопрос, который Вами поставлен
> в первом сообщении. Да и "куда" ходил пользователь - НетФлоу тоже
> "отвечает" довольно посредственно. Ибо выдает данные только L3.а для того и виланы были предложены, чтоб внутри локалки по L3. тем более никаких нормальных вариантов, кроме netflow, при 300 клиентах (как ниже написано) просто быть не может.
>> Ни netflow, ни sflow не смогут ответить на вопрос, который Вами поставлен
>> в первом сообщении. Да и "куда" ходил пользователь - НетФлоу тоже
>> "отвечает" довольно посредственно. Ибо выдает данные только L3.
> а для того и виланы были предложены, чтоб внутри локалки по L3.
> тем более никаких нормальных вариантов, кроме netflow, при 300 клиентах (как
> ниже написано) просто быть не может.А что, netflow гарантирует "попадание в статистику" даже единичную попытку? Насколько я понял там могут данные расходится на 5-10% от реальности
> А что, netflow гарантирует "попадание в статистику" даже единичную попытку? Насколько я
> понял там могут данные расходится на 5-10% от реальности1)
единичную попытку чего? при успешном ТСП-конекте по любому больше одного пакета пройдет - дальше как агрегацию и последующую обработку данных организуете.2)
протокол простейший. при желании свой демон написать (под конкретную реализацию протокола дело 1-2-х дней - сам такое делал). будет хоть каждый пакет в отдельный поток совать (готовьте терабайтные накопители для хранения этой лабуды)3)
можете предложить альтернативу?4)
о чем вообще вопрос если Вам L3 достаточно? виланами режем всех гадов на L2 - они ходят по L3 (если разрешим), а мы снимает статистику с flow и радуемся. на 300 клиентов дешево и сердито.
> 1) > единичную попытку чего? при успешном ТСП-конекте по любому больше одного пакета пройдет - дальше как агрегацию и последующую обработку данных организуете.Вася набирает telnet 192.168.217.100 3306. Допустим в сесии было всего 3-4 пакета, я увижу этот конект в netflow?
> 2) > протокол простейший. при желании свой демон написать (под конкретную реализацию протокола
> дело 1-2-х дней - сам такое делал). будет хоть каждый пакет
> в отдельный поток совать (готовьте терабайтные накопители для хранения этой лабуды)если бы все было так просто , то почему его до сих пор нет ни на одном из оборудований кроме cisco? ;)
> 3) можете предложить альтернативу?
я нет, а вы?
> 4) > о чем вообще вопрос если Вам L3 достаточно? виланами режем всех гадов
> на L2 - они ходят по L3 (если разрешим), а мы
> снимает статистику с flow и радуемся. на 300 клиентов дешево и
> сердито.я так понимаю на dlink это называется protected ports? Но проблема в том, что у меня есть как HP (2510) так и Dlink (3028). И вот как это все реализовать на разном оборудовании?!
>> 1) > единичную попытку чего? при успешном ТСП-конекте по любому больше одного пакета пройдет - дальше как агрегацию и последующую обработку данных организуете.
> Вася набирает telnet 192.168.217.100 3306. Допустим в сесии было всего 3-4 пакета,
> я увижу этот конект в netflow?Какаой смысл 3-4 пакета ловить? syn + syn-ack + rst/fin = 3-4 пакета. TCP-сессия без передачи данных.
Flow в терминах протокола - это пакеты с одинаковыми src_addr, dst_addr, src_port и dst_port. Как вы настроите агрегацию flow - так и будет. Хоть каждый пакет в отдельный flow пихайте (тут конечно от конкретной реализации софта зависит - ибо обычно нижний предел, в качестве "защиты от дурака", есть), если мощностей и накопителей хватит.
Просто задумайтесь над тем сколько пакетов за секунду пролетает ч/з сенсор - если не будет агрегации данных, то система просто захлебнется при сохранении информации по каждому отдельному пакету (да и анализ данных потом нереальное время займет).
>> 2) > протокол простейший. при желании свой демон написать (под конкретную реализацию протокола
>> дело 1-2-х дней - сам такое делал). будет хоть каждый пакет
>> в отдельный поток совать (готовьте терабайтные накопители для хранения этой лабуды)
> если бы все было так просто , то почему его до сих
> пор нет ни на одном из оборудований кроме cisco? ;)Как это нет? Полно open-source решений для сенсоров+коллекторов netflow и сопуствующих им анализаторов. Благо данные по сети можно куда угодно отправлять. Кто мешает мирорить трафик на порт какого-нибуль свича (или сервер) и снимать там информацию полюбившимся софтом (без всяких cisco)?
А если Вы конкретно про оборудование, то посмотрите откуда у протокола netflow ноги растут и все станет ясно.
>> 3) можете предложить альтернативу?
> я нет, а вы?Смысла для разработки алтернативных вариантов не вижу. Протокол netflow достаточно гибок. Если Вам не подходят сушествующие open-sourece коллекторы - напишите свой (я так в свое время и сделал в одном специфичном случае - за 2-а дня демон на C нашкрябал, как попутную задачу).
IPFIX? Суть дальнейшее развитие Netflow, так что в рамках поставленой задачи не вижу смысла рассмтривать.
>> 4) > о чем вообще вопрос если Вам L3 достаточно? виланами режем всех гадов
>> на L2 - они ходят по L3 (если разрешим), а мы
>> снимает статистику с flow и радуемся. на 300 клиентов дешево и
>> сердито.
> я так понимаю на dlink это называется protected ports? Но проблема в
> том, что у меня есть как HP (2510) так и Dlink
> (3028). И вот как это все реализовать на разном оборудовании?!Какая разница, как производители железа в меню интерфейсов своих поделок это именуют? Протоколы 801 dot для кого писаны? Да - бывает, что иногда производители частично или коряво реализуют их на своем железе, но обычно особых заморочек с тем, чтобы подружить разное оборудование по этому протоколу проблем не представляет.
PS
3-4 пакета? тотальная слежка? это имеет смысл организовывать только за подозрительными лицами, а не за всеми клиентами - иначе никаких мощностей и времени на анализ собранных данных не хватит. да и вообще - это отдельная тема (другие подходы и другие методы).
> Какаой смысл 3-4 пакета ловить? syn + syn-ack + rst/fin = 3-4
> пакета. TCP-сессия без передачи данных.вот начальство даже такое хочет видеть, скажем так - параноя :)
> А если Вы конкретно про оборудование, то посмотрите откуда у протокола netflow
> ноги растут и все станет ясно.да я про железки, а не софт под linux
> Какая разница, как производители железа в меню интерфейсов своих поделок это именуют?
> Протоколы 801 dot для кого писаны? Да - бывает, что иногда
> производители частично или коряво реализуют их на своем железе, но обычно
> особых заморочек с тем, чтобы подружить разное оборудование по этому протоколу
> проблем не представляет.вы предлагаете создавать 300 vlan?! А вы представляете сколько они (интерфейсы) будут подниматься на том же linux? И какой приймут вид правила iptables.
У меня сейчас около 20 vlan и поднимаются они около минуты (секунд 30-40 так точно) ;)
> PS
> 3-4 пакета? тотальная слежка? это имеет смысл организовывать только за подозрительными
> лицами, а не за всеми клиентами - иначе никаких мощностей и
> времени на анализ собранных данных не хватит. да и вообще -
> это отдельная тема (другие подходы и другие методы).да, хотят знать все и про всех :)
>[оверквотинг удален]
> да я про железки, а не софт под linux
>> Какая разница, как производители железа в меню интерфейсов своих поделок это именуют?
>> Протоколы 801 dot для кого писаны? Да - бывает, что иногда
>> производители частично или коряво реализуют их на своем железе, но обычно
>> особых заморочек с тем, чтобы подружить разное оборудование по этому протоколу
>> проблем не представляет.
> вы предлагаете создавать 300 vlan?! А вы представляете сколько они (интерфейсы) будут
> подниматься на том же linux? И какой приймут вид правила iptables.
> У меня сейчас около 20 vlan и поднимаются они около минуты (секунд
> 30-40 так точно) ;)Не передергивайте ). Из Вашего предыдушего поста я понял, что у Вас какие-то сложности в организации виланов на базе оборудования от разных производителей. Именно этот момент я и прокоментировал.
300 vlan я не предлагаю). Логически разделите пользователей по группам, а сервера (mysql, etc) конечно каждый в отдельный вилан. Получится, что отдельные группы пользователей (слежка м/ду которыми не нужна) будут общаться м/ду собой напрямую, а попытки выйти в инет и доступ к серверам будут только по L3, при наличии разрешения с Вашей стороны (а тут уже и netflow подключаем).
>> PS
>> 3-4 пакета? тотальная слежка? это имеет смысл организовывать только за подозрительными
>> лицами, а не за всеми клиентами - иначе никаких мощностей и
>> времени на анализ собранных данных не хватит. да и вообще -
>> это отдельная тема (другие подходы и другие методы).
> да, хотят знать все и про всех :)Ну и настраивайте значит Ваши сенсоры и коллекторы netflow в соответствии с задачей. Если мощностией железа хватит при высоких PPS, то никто не запрещает.
> Не передергивайте ). Из Вашего предыдушего поста я понял, что у Вас
> какие-то сложности в организации виланов на базе оборудования от разных производителей.
> Именно этот момент я и прокоментировал.не правильно поняли, сейчас vlan отлично работают в связке HP Pro Curve + Dlink DES. Проблема именно в технологии "удобной" изоляции пользователей
>> Не передергивайте ). Из Вашего предыдушего поста я понял, что у Вас
>> какие-то сложности в организации виланов на базе оборудования от разных производителей.
>> Именно этот момент я и прокоментировал.
> не правильно поняли, сейчас vlan отлично работают в связке HP Pro Curve
> + Dlink DES. Проблема именно в технологии "удобной" изоляции пользователейчто значит "удобной"? "удобно" критерий субъективный, который тех-оценке не поддается ). а в общем (не мне Вас учиить):
- по Л2 на виланах
- по L3 на маршрутизаторах (+PPP-всякие с авторизацией, etc)PS
начальный пост совсем другие задачи ставил )
[del]
>[оверквотинг удален]
>>> какие-то сложности в организации виланов на базе оборудования от разных производителей.
>>> Именно этот момент я и прокоментировал.
>> не правильно поняли, сейчас vlan отлично работают в связке HP Pro Curve
>> + Dlink DES. Проблема именно в технологии "удобной" изоляции пользователей
> что значит "удобной"? "удобно" критерий субъективный, который тех-оценке не поддается
> ). а в общем (не мне Вас учиить):
> - по Л2 на виланах
> - по L3 на маршрутизаторах (+PPP-всякие с авторизацией, etc)
> PS
> начальный пост совсем другие задачи ставил )Создавать 300 вланов/VPN будет не удобно, если так будет понятней :)
>> Какаой смысл 3-4 пакета ловить? syn + syn-ack + rst/fin = 3-4
>> пакета. TCP-сессия без передачи данных.
> вот начальство даже такое хочет видеть, скажем так - параноя :)Тут я конечно немного загнул (ибо flow считается перечача данных в одном направлении), но сенсор и это скушает. И отправит данные на коллектор по окончанию сессии или после таймаута.
>[оверквотинг удален]
> вы предлагаете создавать 300 vlan?! А вы представляете сколько они (интерфейсы) будут
> подниматься на том же linux? И какой приймут вид правила iptables.
> У меня сейчас около 20 vlan и поднимаются они около минуты (секунд
> 30-40 так точно) ;)
>> PS
>> 3-4 пакета? тотальная слежка? это имеет смысл организовывать только за подозрительными
>> лицами, а не за всеми клиентами - иначе никаких мощностей и
>> времени на анализ собранных данных не хватит. да и вообще -
>> это отдельная тема (другие подходы и другие методы).
> да, хотят знать все и про всех :)
>> Бюджетный вариант - всех загнать в ВПН и снимать с впн гейта
>> все инфомрацию куда ходили
> от vpn больше неудобства, чем пользы.вот тут непонятно. обоснуйте )
А много клиентов? А то может просто им маску /32 и на маршрутизаторе tcpdump-ом просто в файлик текстовый. А дальше - раз в час запускать скрипт, который будет парсить текстовый файлик и писать результаты в какую-нибудь базу, из которой уже можно будет удобно доставать запросами всё, чего душа пожелает.
Ну опять же tcpdump-ом не всё подряд снимать, а скажем только syn-пакеты из tcp-сессий.
> А много клиентов? А то может просто им маску /32 и на
> маршрутизаторе tcpdump-ом просто в файлик текстовый. А дальше - раз в
> час запускать скрипт, который будет парсить текстовый файлик и писать результаты
> в какую-нибудь базу, из которой уже можно будет удобно доставать запросами
> всё, чего душа пожелает.
> Ну опять же tcpdump-ом не всё подряд снимать, а скажем только syn-пакеты
> из tcp-сессий.клиентов ~300. Не знаю много это или нет :)
> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
> хочет знать - кто с 13 до 14 обращался на эти
> порты. Т.е. надо фиксировать даже единичный случай.тогда каждому пользователю по отдельному аккаунту на каждый сервис и парсить логи )
одно непонятно, какой в этом весь смысл?
поищите ценник на специальный сервер "обнаружения оттак" и предоставьте его руководству, пусть задумается.
А то постановка задачи, сделайте мне самолет, и бесплатно.
> одно непонятно, какой в этом весь смысл?
> поищите ценник на специальный сервер "обнаружения оттак" и предоставьте его руководству,
> пусть задумается.
> А то постановка задачи, сделайте мне самолет, и бесплатно.а при чем тут IDS к логированию?
> а при чем тут IDS к логированию?IDS не умеет логировать?
далее, зачем вам просто логи? вам нужны алерты, такой-то такой стучится зачем-то сюда, и все это красивенькими таблицами для начальства.
Если вам сейчас они не нужны, то завтра понадобятся, и что вы будете делать?
ФЗ 152?
>> а при чем тут IDS к логированию?
> IDS не умеет логировать?умеет, но по определенным критериям, а мне нужно все
> далее, зачем вам просто логи? вам нужны алерты, такой-то такой стучится зачем-то
> сюда, и все это красивенькими таблицами для начальства.чтобы когда меня спросят, а кто месяц назад лазил вот сюда и сюда, я смог ответить на этот вопрос
> Если вам сейчас они не нужны, то завтра понадобятся, и что вы
> будете делать?
> ФЗ 152?см выше
> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
> хочет знать - кто с 13 до 14 обращался на эти
> порты. Т.е. надо фиксировать даже единичный случай.Запросите КП у контор, которые торгуют продуктами по ИБ, типа Infowatch. Они вам пришлют КП на несколько миллионов рублей. Вы с этим КП пойдёте к начальству. Начальство скажет: "молодец, а есть что-нибудь дешевле?" - а вы: "Вы что! Экономить на Безопасности!!!"
Всё, вопрос закрыт.
>> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
>> хочет знать - кто с 13 до 14 обращался на эти
>> порты. Т.е. надо фиксировать даже единичный случай.
> Запросите КП у контор, которые торгуют продуктами по ИБ, типа Infowatch. Они
> вам пришлют КП на несколько миллионов рублей. Вы с этим КП
> пойдёте к начальству. Начальство скажет: "молодец, а есть что-нибудь дешевле?" -
> а вы: "Вы что! Экономить на Безопасности!!!"
> Всё, вопрос закрыт.Это все понятно, отмазку всегда можно найти. Но вот провайдер мне сказал, что у них даже СБУ принимает трафик по нетфлоу :D
> Это все понятно, отмазку всегда можно найти. Но вот провайдер мне сказал,
> что у них даже СБУ принимает трафик по нетфлоу :DВам шашечки или ехать? ) Сдается мне все ответы Вы и так уже знаете.
>> Это все понятно, отмазку всегда можно найти. Но вот провайдер мне сказал,
>> что у них даже СБУ принимает трафик по нетфлоу :D
> Вам шашечки или ехать? ) Сдается мне все ответы Вы и так
> уже знаете.да, направление я понял. Осталось определиться с реализацией. Так как на оборудование разных вендоров будет сложно реализуемо.
>>> Это все понятно, отмазку всегда можно найти. Но вот провайдер мне сказал,
>>> что у них даже СБУ принимает трафик по нетфлоу :D
>> Вам шашечки или ехать? ) Сдается мне все ответы Вы и так
>> уже знаете.
> да, направление я понял. Осталось определиться с реализацией. Так как на оборудование
> разных вендоров будет сложно реализуемо.сложного-то ничего нет. разные только настройки и (умничиние девайса). данные на коллектор все равно по стандартному протоколу отправляются. так что в первую очередь следует обратить внимание на реализацию сенсоров netflow на конкретном оборудовании.
> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
> хочет знать - кто с 13 до 14 обращался на эти
> порты. Т.е. надо фиксировать даже единичный случай.Ну вообще тут может быть самопальное пешение на основе ident rfc1413
>> Конкретный пример - "на компьютере А были установлены VNC/MySQL/FireBird". Так вот начальство
>> хочет знать - кто с 13 до 14 обращался на эти
>> порты. Т.е. надо фиксировать даже единичный случай.
> Ну вообще тут может быть самопальное пешение на основе ident rfc1413Фактически ident сервера есть в Unix и должны быть для Windows (это те которые сообщают на запрос кто коннектится с порта X этой машины). На защищаемой машине несложный прокси который редиректит порты 1 2 3 на 4 5 6, но приподключении на 1 2 или 3 делает запрос ident, если получает ответ то редиректит и пишет ответ в лог, а если не получает ответ (умный пользователь отключил ident сервер) то рвёт соединение. Не узнал кто коннектится - отлупил. Нормальный программер напишет за день.
http://www.google.ru/#newwindow=1&tbo=d&output=search&sclien...,or.r_gc.r_pw.r_qf.&bvm=bv.42553238,d.bGE&fp=4c4418196fe18d4f&biw=1920&bih=798
>[оверквотинг удален]
>>> порты. Т.е. надо фиксировать даже единичный случай.
>> Ну вообще тут может быть самопальное пешение на основе ident rfc1413
> Фактически ident сервера есть в Unix и должны быть для Windows (это
> те которые сообщают на запрос кто коннектится с порта X этой
> машины). На защищаемой машине несложный прокси который редиректит порты 1
> 2 3 на 4 5 6, но приподключении на 1 2
> или 3 делает запрос ident, если получает ответ то редиректит и
> пишет ответ в лог, а если не получает ответ (умный пользователь
> отключил ident сервер) то рвёт соединение. Не узнал кто коннектится -
> отлупил. Нормальный программер напишет за день.Все хорошо, только какая информация о том "кого отлупил". Реальные данные только IP+MAC=L3+L2 ну и нафига козе боян?
>[оверквотинг удален]
>> Фактически ident сервера есть в Unix и должны быть для Windows (это
>> те которые сообщают на запрос кто коннектится с порта X этой
>> машины). На защищаемой машине несложный прокси который редиректит порты 1
>> 2 3 на 4 5 6, но приподключении на 1 2
>> или 3 делает запрос ident, если получает ответ то редиректит и
>> пишет ответ в лог, а если не получает ответ (умный пользователь
>> отключил ident сервер) то рвёт соединение. Не узнал кто коннектится -
>> отлупил. Нормальный программер напишет за день.
> Все хорошо, только какая информация о том "кого отлупил". Реальные данные только
> IP+MAC=L3+L2 ну и нафига козе боян?Задача была кто ходил а не кого отлупили.
>[оверквотинг удален]
>>> те которые сообщают на запрос кто коннектится с порта X этой
>>> машины). На защищаемой машине несложный прокси который редиректит порты 1
>>> 2 3 на 4 5 6, но приподключении на 1 2
>>> или 3 делает запрос ident, если получает ответ то редиректит и
>>> пишет ответ в лог, а если не получает ответ (умный пользователь
>>> отключил ident сервер) то рвёт соединение. Не узнал кто коннектится -
>>> отлупил. Нормальный программер напишет за день.
>> Все хорошо, только какая информация о том "кого отлупил". Реальные данные только
>> IP+MAC=L3+L2 ну и нафига козе боян?
> Задача была кто ходил а не кого отлупили.Он и ходил, но его отлупили (попытка доступа была - значит ходил). Потому, что он такой "умный" клиентскую часть ident отрубил. Как результат валидные данные только по L2+L3. А в таком случае уж лучше сразу на flow заморачиваться.
Все нормальные сетевые сервисы (почта, ФТП, СУБД, etc) и так свою авторизацию имеют (и в логах все подробно видно). Приплетать сюда ident с его cомнительными фишечками-рюшечками имеет смысл толко для сервисов, которые убоги по своей сути (обычно в силу устаревания протоколов или криворукости разработчиков) ИМХО.
> Он и ходил, но его отлупили (попытка доступа была - значит ходил).
> Потому, что он такой "умный" клиентскую часть ident отрубил. Как результат
> валидные данные только по L2+L3. А в таком случае уж лучше
> сразу на flow заморачиваться.Ну не всё решается техникой. Был отлуп с IP такого-то, сисоп идёт разбираться что там такое и кто позволил оключать сервисы.
>> Он и ходил, но его отлупили (попытка доступа была - значит ходил).
>> Потому, что он такой "умный" клиентскую часть ident отрубил. Как результат
>> валидные данные только по L2+L3. А в таком случае уж лучше
>> сразу на flow заморачиваться.
> Ну не всё решается техникой. Был отлуп с IP такого-то, сисоп идёт
> разбираться что там такое и кто позволил оключать сервисы.Ну в локальном корпоративе может и прокатит. А в разнесенных филиалах еще и сисопа на другой конец города по такому чиху слать - это уже перебор.
> сразу на flow заморачиваться.Ну любой молодой сисадмин любит настолько проверенные и 100% решения, что у него поначалу возникает тартар головного мозга. Это когда таром тарят тар на случай ядерной войны. Так что прочитаем православную молитву где мы просим защитить нас от тартара и сряща и беса полуденного.
> Все нормальные сетевые сервисы (почта, ФТП, СУБД, etc) и так свою авторизацию
> имеют (и в логах все подробно видно). Приплетать сюда ident с
> его cомнительными фишечками-рюшечками имеет смысл толко для сервисов, которые убоги по
> своей сути (обычно в силу устаревания протоколов или криворукости разработчиков) ИМХО.Ну так оно и есть. Исключая только случай когда очень молодой и очень крутой по его мнению новоявленный кулхацкер лезет в чужую почту со спёртым паролем не подозревая что в его крутой Убунту идент включен по умолчанию.
>> сразу на flow заморачиваться.
> Ну любой молодой сисадмин любит настолько проверенные и 100% решения, что у
> него поначалу возникает тартар головного мозга. Это когда таром тарят тар
> на случай ядерной войны. Так что прочитаем православную молитву где мы
> просим защитить нас от тартара и сряща и беса полуденного.мдаа.... не знаю, что и сказать... Воистину BSD? :D
Если с тартаром (др. грецией и архивацией) у Вас все правильно, то дальше (с христианством) лапша. Цитирую:
"Бес полуденный" - тот, что искушает нас среди бела дня. А слово "срящ" происходит от слова "сретение", что означает "встреча". В данном случае это встреча с чем-то таким, с чем лучше бы не встречаться. С уважением, свящ. Михаил Немнонов.
ИМХО после "сряща" И не надо :D.
Все равно прикольно.
>> Все нормальные сетевые сервисы (почта, ФТП, СУБД, etc) и так свою авторизацию
>> имеют (и в логах все подробно видно). Приплетать сюда ident с
>> его cомнительными фишечками-рюшечками имеет смысл толко для сервисов, которые убоги по
>> своей сути (обычно в силу устаревания протоколов или криворукости разработчиков) ИМХО.
> Ну так оно и есть. Исключая только случай когда очень молодой и
> очень крутой по его мнению новоявленный кулхацкер лезет в чужую почту
> со спёртым паролем не подозревая что в его крутой Убунту идент
> включен по умолчанию.В данном случае Ваша защита - это защита от лоха, которая проблему полностью решить не может.
Опять же возьмем жизненную ситуацию, когда каждый сотрудник конторы должен иметь доступ к своей почте с любой машины конторы (это гораздо ближе к реальноси, чем мифическое жесткое закрепление за сотрудником конкретного рабочего места). Какую защиту ident в этом случае может обеспечить? Никакой (он должен разрешать всем отовсюду).
В описанной ситуации административные меры гораздо лучший результат дают. Абсолютно ясно, кто свой пароль просрал. И эффект воздействия на на коллектив более правилен - отвественность сотрудника за сохранение довереных ему данных ДОЛЖНА БЫТЬ - это хорошая политика (без нее никакие аппаратно-софтовые меры защиты вообще не работают в реальной жизни).
> Если с тартаром (др. грецией и архивацией) у Вас все правильно, то
> дальше (с христианством) лапша. Цитирую:Да, тартар это умственное иступление в которое впадает компьютерщик, стараясь учесть всё и вся, и его надо избегать всеми силами, иначе рефлексия, бессонные ночи, импотенция, и ради чего?
> В данном случае Ваша защита - это защита от лоха, которая проблему
> полностью решить не может.Люди не лохи, они просто гордецы без любви.
>> Если с тартаром (др. грецией и архивацией) у Вас все правильно, то
>> дальше (с христианством) лапша. Цитирую:
> Да, тартар это умственное иступление в которое впадает компьютерщик, стараясь учесть всё
> и вся, и его надо избегать всеми силами, иначе рефлексия, бессонные
> ночи, импотенция, и ради чего?Это просто шутка была. Я Вас прекрасно понял.
>> В данном случае Ваша защита - это защита от лоха, которая проблему
>> полностью решить не может.
> Люди не лохи, они просто гордецы без любви.Про "люди" - это философский вопрос (хотя каюсь - сам пословоблудил и повод дал).
Бредовый вариант:
локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)
> Бредовый вариант:
> локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)опуская Ваш бред про ОДИН свич спрошу просто: статистику будете с tables снимать?
> опуская Ваш бред про ОДИН свич спрошу просто: статистику будете с tables
> снимать?Я новичок, могу ошибаться. Идея так или иначе использовать для анализа трафика возможности ПК: "софтовый" маршрутизатор, а не "аппаратный".
>> опуская Ваш бред про ОДИН свич спрошу просто: статистику будете с tables
>> снимать?
> Я новичок, могу ошибаться. Идея так или иначе использовать для анализа трафика
> возможности ПК: "софтовый" маршрутизатор, а не "аппаратный".Суть в том, что для решения этой задачи протоколы уже давно разработаны. И они как апппаратно, так и софтово реализованы. Изучайте их (протоколы) - пригодится.
PS
Прошу прощение за резкое высказывание с моей стороны в предыдущем посте.
>> опуская Ваш бред про ОДИН свич спрошу просто: статистику будете с tables
>> снимать?
> Я новичок, могу ошибаться. Идея так или иначе использовать для анализа трафика
> возможности ПК: "софтовый" маршрутизатор, а не "аппаратный".У Вас давление?
> У Вас давление?Возможности маршрутизатора-коробочки ограничены ПО и производителем
Возможности маршрутизатора-ПК - ПО и фантазией админа.
Так?
>> У Вас давление?
> Возможности маршрутизатора-коробочки ограничены ПО и производителем
> Возможности маршрутизатора-ПК - ПО и фантазией админа.
> Так?Я про ник.
>>> У Вас давление?
>> Возможности маршрутизатора-коробочки ограничены ПО и производителем
>> Возможности маршрутизатора-ПК - ПО и фантазией админа.
>> Так?Хорошо, у вас весь трафик идёт через софт рутер. Как узнать что с хоста a.b.c.d с порта xxx кто законектился. Для этого существует только ident протокол, который запрашивает у хоста a.b.c.d какой username открыл исходящий tcp порт xxx. Голый iptables тут не поможет.
Хорошо, используем iptables, но тогда нам нужен модуль --mod-exec ident1413_script.sh, который запустит ident запрос и отлогирует его, но модуля exec в iptables НЕТУ!!! А очень нужно, и его надо писать самому.
>>>> У Вас давление?
>>> Возможности маршрутизатора-коробочки ограничены ПО и производителем
>>> Возможности маршрутизатора-ПК - ПО и фантазией админа.
>>> Так?
> Хорошо, у вас весь трафик идёт через софт рутер. Как узнать что
> с хоста a.b.c.d с порта xxx кто законектился. Для этого существует
> только ident протокол, который запрашивает у хоста a.b.c.d какой username открыл
> исходящий tcp порт xxx. Голый iptables тут не поможет.Для этого сушествует протоколы изоляции пользователей на уровне L2 и протоколы сбора ДЕТАЛЬНОЙ информации по трафику на уровне L3. ident = никакое решение, если применяется вне корпоратива (ибо требует установку софта на клиенте).
> Хорошо, используем iptables, но тогда нам нужен модуль --mod-exec ident1413_script.sh,
> который запустит ident запрос и отлогирует его, но модуля exec в
> iptables НЕТУ!!! А очень нужно, и его надо писать самому.а вот обращение из ядерного уровня к скриптам - это уже точно бред.
>[оверквотинг удален]
>> только ident протокол, который запрашивает у хоста a.b.c.d какой username открыл
>> исходящий tcp порт xxx. Голый iptables тут не поможет.
> Для этого сушествует протоколы изоляции пользователей на уровне L2 и протоколы сбора
> ДЕТАЛЬНОЙ информации по трафику на уровне L3. ident = никакое решение,
> если применяется вне корпоратива (ибо требует установку софта на клиенте).
>> Хорошо, используем iptables, но тогда нам нужен модуль --mod-exec ident1413_script.sh,
>> который запустит ident запрос и отлогирует его, но модуля exec в
>> iptables НЕТУ!!! А очень нужно, и его надо писать самому.
> а вот обращение из ядерного уровня к скриптам - это уже точно
> бред.Почему? Для чего тогда usermode helper API?
> Почему? Для чего тогда usermode helper API?считаете, что для того, чтобы из firewall скрипты запускать?
>> Почему? Для чего тогда usermode helper API?
> считаете, что для того, чтобы из firewall скрипты запускать?Считаю что наплевать на производительность, но возможность такую можно было бы иметь. Если мне нужно проверить syn запрос, то пользователь подождёт 3-4 секунды ради security.
> Для этого сушествует протоколы изоляции пользователей на уровне L2 и протоколы сбора
> ДЕТАЛЬНОЙ информации по трафику на уровне L3. ident = никакое решение,
> если применяется вне корпоратива (ибо требует установку софта на клиенте).Расскажите пожалуйста про это. Что есть на L2 и что на L3? Что такое изоляция пользователей на L2, это каждый пользователь ходит в инет через свой интерфейс? Что можно собрать на уровне IP о именах пользователей? Что это за протоколы сбора детальной информации? Честно, я не прикалываюсь, просто Вы видимо знаете очень интересное для меня, если это не разговор просто, так вобщем....
>> Для этого сушествует протоколы изоляции пользователей на уровне L2 и протоколы сбора
>> ДЕТАЛЬНОЙ информации по трафику на уровне L3. ident = никакое решение,
>> если применяется вне корпоратива (ибо требует установку софта на клиенте).
> Расскажите пожалуйста про это. Что есть на L2 и что на L3?
> Что такое изоляция пользователей на L2, это каждый пользователь ходит в
> инет через свой интерфейс? Что можно собрать на уровне IP о
> именах пользователей? Что это за протоколы сбора детальной информации? Честно, я
> не прикалываюсь, просто Вы видимо знаете очень интересное для меня, если
> это не разговор просто, так вобщем....1)
каждый пользователь ч/з свой интерфейс? в идеале - да. но это увы (как правило) не возможно.2)
на уровне IP об именах пользователей конечно 0 инфы, однако для того админам (в том числе) и платят за то, чтобы построеная система могла связать одно с другим.3)
неужели Вы про стековую модель OSI не знаете? сомневаюсь.Однако из нее очевидно, что самый детальный (и не зависимый от приложений) сбор информации может происходить только на уровне протоколов нижнего уровня.
Явно сбор инфы по L2 - не решение проблемы в данном случае - много избыточных_и_не_нужных данных = проблемы сохранения_обработки информации.
L3 - самое-то место для снятия детальной информации (который может интерисовать руководство в плане безопасности и затрат). Межсетевой трафик (которым ВЫ имеете возможность упралять=запрещать уже на L2)
L4 - просто обеспечивает надежность доставки данных по L3
L5 и выше - вот тут начинаются всякие авторизации ОТ приложений. То , что требует от клиента установки определенно софта, и наличие соотвествующего сервера, который данные от этого клиента обработает.
Аксиома:
если нет запрещения общения по нижним Lx-уровням, то любой протокол уровня Lx+1 обходится.на каком уровне модели OSI ident-протокол стоит? можете и по ident, но считаете, что это Вас избавит от необходимости изоляции общения пользователей по нижним уровням протоколов? К чему тогда про L2 и L3 загон?
> на каком уровне модели OSI ident-протокол стоит? можете и по ident, но
> считаете, что это Вас избавит от необходимости изоляции общения пользователей по
> нижним уровням протоколов? Нет конечно, ident это дополнительная проверка, а блокирование на L3.
>> на каком уровне модели OSI ident-протокол стоит? можете и по ident, но
>> считаете, что это Вас избавит от необходимости изоляции общения пользователей по
>> нижним уровням протоколов? Нет конечно, ident это дополнительная проверка, а блокирование на L3.В результате пришли к тому откуда начали - ident уже не панацея, как было раньше заявлено.
Вопрос в том, нужен ли после блокирования L3 и ниже этот ident со всем его гемороем (в частности - наличие клиента на машине пользователя)?
>> У Вас давление?
> Возможности маршрутизатора-коробочки ограничены ПО и производителем
> Возможности маршрутизатора-ПК - ПО и фантазией админа.
> Так?Все ограничено возможностями железа и ПО. Просто не на "маршрутизаторе-коробочке" выбор ПО очевидно гораздо богаче. С другой стороны, крутые "коробки" весь необходимы функционал по ПО предоставляют, и в силу заточенности своего железа под определенный круг задач работают быстрее нежели их аналоги на базе простого компа. Выбор оборудования и софта всегда решается исходя из круга поставленых задач и дальнейших перспектив развития.
> Бредовый вариант:
> локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)А ничего что в такой схеме компьютеры в пределах одного влана будут идти в обход маршрутизатора? ;)
>> Бредовый вариант:
>> локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)
> А ничего что в такой схеме компьютеры в пределах одного влана будут
> идти в обход маршрутизатора? ;)А где тут про виланы вообще говорилось?
PS
Прочитайте все посты.
>>> Бредовый вариант:
>>> локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)
>> А ничего что в такой схеме компьютеры в пределах одного влана будут
>> идти в обход маршрутизатора? ;)
> А где тут про виланы вообще говорилось?
> PS
> Прочитайте все посты.а ты как собрался всех пользователей пускать через роутер? Перечитай условия задачи и не задавай/давай дурных вопросов/советов ;)
>>>> Бредовый вариант:
>>>> локалка --> управляемый свич --> ПК-маршрутизатор (ebtables,iptables,твори что хочешь)
>>> А ничего что в такой схеме компьютеры в пределах одного влана будут
>>> идти в обход маршрутизатора? ;)
>> А где тут про виланы вообще говорилось?
>> PS
>> Прочитайте все посты.
> а ты как собрался всех пользователей пускать через роутер? Перечитай условия задачи
> и не задавай/давай дурных вопросов/советов ;)Все посты перечитали - хорошо. Теперь посмотрите на какой пост Вы отвечали. И еще раз перечитайте все посты для закрепления.
PS
Не в обиду.