XoRe

2Doozer: сканирование портов - это атака? =)) Не разу не слышал, чтобы сканирование портов (только сканирование портов взломало сервер =)

2nn: самому ручками надо будет забивать или скриптом =)) 2Guest_knowhow: Это логично. Для того, чтобы до машины от клиента дошло более одного пакета, надо не только сниффить, но и эмулировать tcp соединение. Хотя это, не так сложно. А насчет пароль+ip+mac я уже написал в п.3, что в stargazer даже авторизация идет ШИФРОВАННАЯ. Шифрование идет по алгоритму blowfish. Так что отсниффить получится не пароль, а его зашифрованное значение. P.S. "привязка ip+mac" бережет от кражи траффика только пока в сети все - добропорядочные люди.

Можно собрать stargazer с подсчетом пакетов через divert и поиграться с ipfw.

Детский сад. Почитали статью "как я, супа-пупа-мега-кул-хацкер, чиста паимел саседа" и кричат, что все, ethernet-провайдингу пришел ахтунг. Подобный разговор уже был в теме http://local.com.ua/forum/index.php?showtopic=1207 Ликбез: 1. Можно поменять mac-адрес средставами windows. 2. Можно поменять ip-адрес средставами windows. 3. Можно даже оба их поменять одновременно =)) 4. Можно заняться арп-спуфингом. Рассмотрим все четыре варианта, при условии что на шлюзе стоит жесткая привязка мака к ip-адресу: 1. Ты, как клиент, у себя поменял mac-адрес. Первое, что может случиться - вылетит окно с текстом "такой ip уже используется". Насрем на неё, т.е. закроем =)) И так, что мы имеем? До шлюза, а следовательно, до инета не достучаться в любом случае - шлюз шлет пакеты вам на ваш старый mac-адрес. До остальных компов достучаться - это как повезет. Шлюз может рассылать ваш старый mac на запросы других компов. Следовательно, вы не сможете пообщаться с некоторыми машинами в сети. Т.е. смена mac-адреса вам ничего не даст. 2. Меняем ip-ишник. Тут уже лучше. Если меняем на занятый, то все будет как в п.1. Если на свободный, то можно будет поюзать местный веб/фтп сервер и пообщаться с другими машинами в сети. Т.е. можно работать в сети без выхода в инет. 3. Меняем ip и mac. Рассмотрим 2 варианта: а) Меняем на ip и mac клиента. Зашибись! Мы другой клиент! =)) Главное - чтобы клиент, под кого мы косим, в это время был отключен. Если зарубить у себя netbios, то однозначно определить, что это другой пользователь, нельзя. Если в сети авторизация по ip+mac, можете спокойно выходить в инет. Если клиент, которым вы претворяетесь, включит комп, то у вас начнет глючить сеть. Значит пора менять все это дело обратно. Если в сети авторизация по vpn или стоит что-то типа stargazer, смена ip и mac-адреса доступа в интернет вам не даст. б) Меняем на ip и mac-адрес шлюза. Поменяли? Молодцы! Орлы, так сказать! =)) Если не хотите, чтобы вас отрубили от сети и ещё наваляли люлей в добавок, советую поменять обратно. Потому что сейчас (точнее когда поменяете), вся локалка (кроме шлюза) лишилась инета. Или имеет инет, но очень глючный и медленный. Имхо, в таком случае, даже если у вас будет уже настроен на машине переделанный нужным образом vpn-сервер или stg-сервер, своровать логины и пароли пользователей у вас не получится. Авторизация шифруется по паролю. Если у вас, как у сервера, не будет пароля, вы не сможете расшифровать запрос клиента. Такая подмена засекается сразу, админы встают на уши и ищут того, кто это делает. Как найдут, навсекают и отрубят от инета. Так что даже такая мега-подмена вам ничего полезного не даст. 4. Арп-спуфинг. Что это такое: - какая-то машина говорит клиенту, чтобы он обращался к серверу по mac-адресу этой машины. - эта-же машина говорит серверу, чтобы он обращался к клиенту по mac-адресу это машины. Т.е. становится посредником между клиентом и сервером. Это вполне рабочая схема, если на сервере(шлюзе то есть) нету железного забития ip-адресов по mac-адресам. Если забитие есть, то сервер, со своей стороны, скажет "Хрен тебе. Я буду обращаться к клиенту по тому mac-адресу, который написан у меня". И будет слать пакеты клиенту на тот mac-адрес, который в ней забит. Для клиента будет такая ситуация: отправляет он пакеты на один mac-адрес, а ответы приходят с другого. Как винда будет себя вести в такой ситуации, я не знаю. Могу предположить, что поменяет запись об mac-адресе на правильную. Значит первый-же пакет от сервера поломает весь arp-спуфинг. А в первых пакетах нету паролей. там только запрос на соединение. Вот и весь arp-спуфинг. Вывод: делайте железную привязку ip-адресов к mac-адресам и ставьте какую-нибудь авторизацию для выхода в инет. P.S. Во всех четырех случаях "хакера" можно поймать, если запустить на шлюзе программу arpwatch. Что это за программа - ищите в инете, инфы там навалом.

Если система работает чисто как шлюз/маршрутизатор, то да. А если система используется, как сервер, значит на ней запущены сервисы и открыты порты. Любая система, даже винодовс, рабочая. Дело в том, что в системе или в её сервисах могут быть ошибки или недоработки, которые позволят эту рабочую систему сломать. Или система с такими ошибками сама может рано или поздно "упасть". Пример: жила-была в языке C функция sprintf. Этой функции, быть может, уже лет 30ть. И, как я понял, относительно недавно народ понял, что эта функция в программе создает риск взлома программы. А эта функция есть, чуть ли не в любой программе. С другой стороны, если на сервер не предпринимаются попытки взлома, то он и на винде может работать годами, наверное. А ребутить надо, чтобы пропатченное ядро загрузить.

Тогда советую или запастись доками и вникать в шейпинг канала под линуксом, либо звать к себе гуру. Как я понял, это дело надо настраивать под твою ситуацию.

Такой способ ограничения доступа взламывается стандартными средствами винды. Причем, это даже как хак/взлом/и.т.д. расценить нельзя, так как mac соседа можно узнать, опять-же, стандартными средствами винды.

Аптайм 1 год означает, что машина работает на системе, которая уже год не обновлялась. Идея не моя, а из книги по FreeBSD.

А чем винт не устраивает?

2Константин: не только затухание может зарубить обмен информацией. У меня в одном месте <100 метров витой пары, 4 жилы, без экрана. Если кабель вснунуть в тестер с динамиком, то можно слушать радио. Думаю, в таких случаях вычитание помех поможет. Хотя в том случае мы решили решить проблему заменой кабеля. 185 метров по стандарту 5е? Откуда такое мнение?

Можете рассказать, как будет работать arp-спуфинг, если на роутере работает жесткая привязка маков к ипишникам? Я могу рассказать - он работать не будет.

Ограничивать скорость ftp умеет большинство ftp-серверов. Даже виндовые ftp-сервера это умеют. По крайней мере те, которыми я пользовался. Тут шейпер не нужен.

Кстати да, насколько я помню, MS-CHAP, CHAP как раз и задуман против подмены серверной стороны.

какое-никакое звучит как "какое? да никакое!"=) 100 мегабит на 300 метров - неплохо. Вот что энтузиазм в работе делает! =))

1. Учет есть. В логах регестрируется время подключения/отключения. Скрипт, который эти логи будет парсить, пишется за пол часа. 2. Мой интерфейс по приему платежей зовут Людмила Петровна. Имеет защиту от копирования на генном уровне =)) Имхо, у каждого админа свои задачи. Тот "велосипед", который сделал один админ для своей работы, необязательно подойдет к твоей работе. Поэтому могу советовать реализовывать это по своему. Могу ещё посоветовать почитать форум, посмотреть кто что по этому поводу пишет просто для ознакомления.

Если каждому пользоателю вдюндить в инфу эти галочки, то получится больше конфигов/жрания оперативки/жратия процессора. Grep решает проблему в полном соотетствии философии unix. Незачем изобретать уже изобретенный велосипед. За счет скриптов UserAdd я могу добавить пользователя в старгейзере, в самой *nix, прописать его в DHCP, DNS и ещё бог знает где ещё. Скрипты для этого и существуют. Если кто-то считает писать их геммороем - то это уже другой вопрос.

Имхо, это доказывает, что мнение Константина по поводу нужности канала не соответствует действительности.

Для фрях могу предложить такой вариант: Заносишь в ipfw кучу правил типа allow ip from внут. сетка to тыдынь recv внут. интерфейс Где, тыдынь - это сетки украины. И так по одному правилу на каждую сеть. А в конце правило deny ip from внут. сетка to any recv внут. интерфейс Потом, в старгейзере разделяешь юзеров на 2 группы. Потом в OnConnect добавляешь конструкцию типа group=`grep Group= /var/stargazer/users/$LOGIN/conf` И если юзер принадлежит группу глобалистов, то скрипт перед deny пусть добавляет правило skipto № ip from any to any Где, № ставишь больше того, котрый у правила deny ip from внут. сетка to any recv внут. интерфейс Получается так: если пользователь чисто на украине, то ему доступны только украинские сети. А все остальное рубится правилом deny ip from внут. сетка to any recv внут. интерфейс Если пользователь имеет глобал, то за счет skipto, он перепрыгивает deny и имеет глобал.

Так, народ, советую ВСЕМ добавить в начало файла rules следующие записи, если ещё не добавили: ALL 192.168.0.0/16 NULL ALL 127.0.0.0/8 NULL ALL 10.0.0.0/8 NULL ALL 172.16.0.0/12 NULL ALL 169.254.0.0/16 NULL ALL 192.0.2.0/24 NULL ALL 224.0.0.0/4 NULL ALL 240.0.0.0/4 NULL Чтобы пользователю не считался локальный траффик, как глобальный.

Слушай, а ты случайно stargazer не собрал с новым типом подсчета пакетов?

хех. Придется поднимать мирку =) Хотя скорее не мирку, а миранду новую ставить. Чтобы подключить плагин ирковый.

Ты пользователя создал? Ты тариф какой-нибудь сделал? Какая у тебя ОС? На каком интерфейсе ведется подсчет? Какая версия старгейзера? И наконец главный вопрос: у тебя старгейзер вообще запущен? Те данные, которые ты дал, не дают ответа ни на один из вышеуказанных вопросов.

гы Пожалуйста

2 сквида - это интересно =))

Кстати, а зачем тебе считать траффик на внешнем интерфейсе?