XoRe

4.10 по быстродействию опережает 5.x. Как, я думаю, и по стабильности. Это по поводу 2005 года. Теперь вопрос по существу: есть примеры того, что на 5.х stg работает лучше?

выше был я

Только что обнаружил 2 глюка: stg одинаково воспринимает пароли типа 'abc' и 'abcabc'. Причем этот глюк и в авторизаторе и в конфигураторе. Потом. В авторизаторе максимальное количество символов для ввода пароля клиента = 15. Сейчас лично проверял и тот глюк и тот. Версии: - сервера: 2.09.6.4 beta (билд от 16.11.2004) - конфигуратора: 1.45.6 - авторизатора: 2.38.4 Борис, ты писал, что знал про первый глюк и исправил его. Возможно не исправил. Исправь, пожалуйста.

Ждёмс...... А ковырять самому исходникиавторизатора - не интересно. Токо собрал под себя - а тут уже новая версия. Не думаю, что новые версии авторизатора будут выходить часто. И, опять, же - это вопрос желания =)

Я не знаю iptables, но думаю, что и там есть правило, запрещающее не сессии, а ПАКЕТЫ. Может попробовать использовать его?

Я думаю, что загружать авторизатор лишними функциями не стоит. Не знаю, как у остальных, но у меня он 99,9% времени работает в свернутом состоянии. НО если так уж хочется скины/плагины/новые фичи к нему - исходники авторизатора в руки и вперед =))) А насчет проверки домена по рулесам, идея хорошая, я её вопролчу в жизнь на своем сервере. Если нужна, скажите, выложу, как сделаю.

2MityaginSpbRu: Локальный обход этй проблемы я описал в теме про предыдущий билд. 2stg-34: Насколько я могу судить по скорости обновления, в этом билде оптимизирован алгоритм шифрования. Я угадал? =)

1. Оставлять поддержку только одного последнего метода 2. С этим методом возможно только одно действие - обновление авторизатора. ИМХО чтобы хакнуть достаточно короткую сессию закачки новой версии у хакера просто не будет времени. ОЧень хорошая мысль. Получается такой алгоритм: клиент при коннекте сообщает серверу свою версию. Если у сервера есть более поздняя версия, то он без вопросов закачивает её клиенту. Клиент обновляется в автоматическом режиме. И, по желанию сервера, показывает информационное сообщение "программа обновлена". Т.е. в сервере сделать ещё одну опцию типа "уведомлять клиента о произведенном обновлении". Насчет хакания сессии закачки. Я думаю, это опасно для тех, у кого сеть на хабах. Если сеть на свичах, то тут исключен даже перехват и этой короткой сессии.

Успешный разговор - это всегда лучший способ решения проблем =))

Вошлел ли оптимизированный алгоритм шифрования в этот билд?

Та нічого це не дасть. А що як, наприклад, у когось теж є інтерес або хтось взагалі для приколу проводочок ЧИК! і вирішив подивитися на війну. У нас такі проблеми були (впринципі і зараз залишаються частково) з однією із мереж на борщагівці. Замість того щоб влаштовувати взаємне різання/викрадання кабелів/обладнання ми вирішили зробити збір адмінів усіх сусідніх мереж на якому мирно обговорили це питання. Теж малоефективна штука, але, принаймні, може хоч так якісь результати будуть. не знаю украинский =)) 2others: Да, согласен, провода срезать проще всего. И от этого никак не убережешься, если провода не под землей. А насчет неэффективности битья морд: в условиях "полулегальности", когда бессмысленно обращаться к законным средствам, остается 2 способа: разговор и битьё морд. Если у вас получится уладить дело разговором - хорошо. Если нет и морду бить вы не хотите, значит терпите =))

Надо пытаться ставить не больше, а меньше =)))

Если честно, я удивлен, как у тебя вообще инет работает =)) Советую ещё почитать доки по ipfw. Потом. Если все работает, кроме этих трех сайтов, то логично предположить, что где то что то настроено либо против этих трех сайтов, либо для этих трех сайтов, но криво. Хотя, если в винде работает... Тогда проблема и правда во FreeBSD. И может быть даже в фрагментации пакетов или в mtu или mss. Я тебе по аське скину аську человека, у которого была подобная фигня. Спроси у него, он, кажись решил её.

2stg-34: Понял. Согласен, это самый лучший метод шифрования, когда в качестве ключа используется пароль клиента. А насчет супер-пупер. Эту проблему можно решить таким способом: В сервере оставлять поддержку предыдущих способов шифрования. При коннекте сервер пытается расшифровать сначала самым последним способом, потом более старым и т.д. Опять-же возникает проблема, что если у юзера старый клиент с "взломанным" алгоритмом, то хакер сможет этот алгоритм "взломать". Потому и правда, можно сделать обновление в автоматическом режиме. А юзерам так и сказать, что программа сама будет обновляться иногда. А на вопрос юзеров поумнее "как я могу быть уверен, что вы не зашлете мне трояна?", отвечать "Никак. Я и так все могу узнать без троянов" =) 2egor2fsys: У меня работает привязка мак адреса к ip адресу. Если хакер поменяет с ип адресом ещё и мак адрес, то в логах это не будет писаться. Именно этот факт был для меня одним из главных причин перейти на stg.

В общем так: Я думаю, что единственный "цивилизованный" способ этого избежать - ставить ящики, которые х%й вскроешь. А самый "малокровный" способ - и правда, набить админам "второй" морду. Почему малокровный? Потому что тогда пострадает только несколько человек, админов. При любом раскладе, начиная от скрывания ящиков второй, заканчивая привлечением администрации, пострадает гораздо больше людей.

Как? Об этом писалось в теме про vpn. Хакер качает исходники stg, переделывает процедуру авторизации так, чтобы все попытки залогиниться на этот сервер писались бы в лог. И потом хакеру необходимо, в общем то только одно условие - чтобы перестал отвечать червак реальный. Тогда он меняет свой ip адрес на адрес сервера (если они находятся в одном сегменте сети). И ждет подключений. Вуаля. Я не знаю, рандомно(random) или не рандомно идет шифрование blowfish. Т.е. получаются после шифрации одни и теже данные или разные. Но, если одни и теже, то я думаю, что можно ещё tcpdump'ом поиграться, если сеть на хабах. Т.е. сохранить траффик диалога между клиентом юзера и сервером. Потом Сымитировать авторизацию к своему серверу. Я уже писал, что от этго спасает. Управляемые хабы или авторизация посредством одноразовых паролей/ключей. Я как-то исходил из предположения что никто не возьмется за взлом DES. И зря я так думал... Короче говоря. Всё будет совсеи по другому Скажем так, вы, Борис, можете сделать что-то касающееся биллинга stg. Это ваша ответственность. Здесь вы имеете возможность самому задавать поведение сервера, конфигуратора, авторизатора. Т.е. у вас есть возможность сделать хорошо свою часть работы. На то, что творится в локальной сети провайдера, вы не можете повлиять. Там может и должен распоряжаться админ. Это уже его зона ответственности. Админ должен следить за тем, чтобы его сервер не падал и никто не пытался в этот момент стать сервером. Вы сделали очень хорошую фещь - сделали авторизацию по ip+паролю. Этим вы ОЧЕНЬ облигчили жизнь админам. Я говорю вам спасибо за это. И не только я =)) Полностью вы не можете делать всю работу за админов. Я думаю, что вы можете ещё раз здорово помочь админам - сделать такую авторизацию, при которой сервер, не зная пароля клиента, не сможет с ним общаться. Как дилетант в области криптографии, могу предлодить например, передавать логин открытым текстом, а весь остальной траффик шифровать паролем клиента. Т.е. пароль будет нужен и при шифровке и при дешифровке. Не знание пароля сервером будет равнозначно незнанию пароля клиентом. Т.е. в боих случаях авторизация не произойдет. Кстати таким способом можно сделать авторизацию. Сервер шлет клиенту какие то фонарные данные. Клиент шифрует эти данные и передает получившееся значение серверу вместе со своими фонарными данными. Сервер получает значение, сравнивает с своим значением, получившимся после шифрации данных. Если значения равны, то сервер шифрует полученные вторые данные от клиента. И отправляет полученное значение обратно клиенту. Клиент сравнивает результаты шифрования своих данных собой и сервером. И если они равны, продолжает коннект с сервером. Иначе прекращает коннект с сообщением "неверный пароль". Ключем шифрования можно сделать сам пароль.

Если честно, я думаю, что если хакер поставит свой сервак stg с подделаным адресом, ему что обновление, что не обновление, не имеет значения. Он и так будет в состоянии получать логины с паролями от клиентов. Автообновление тут ни при чем. Как я уже писал, это можно преодлолеть или умными свичами или авторизацией на основе одноразовых генерируемых ключей. Или ещё чего-то подобного. Кажется ms-chap 1,2 реализует что-то подобное. Хотя не помню точно. Поэтому давайте изходить из предположения, что сервер никто не подделывает. Иначе см. выше =)) Так вот, я думаю, можно сделать так: разрешить скачивать обновления всем желающим, зарегестрированным или незарегестрированным. (Т.е., чтобы можно было сделать программу "Инсталлятор Интернета" =)) Т.е. висит демон на порту и раздает всем желающим программу. А с такими вещами, как злобные хакеры, спуффящие ip адрес, ограничения на доступ к этому порту, и т.д. и т.п., должны разбираться админы.

Можно так. Дело в том, что пользователи могут потом задавать вопросы "а чего это за обновление", "а нафиг оно мне нужно", "а это не вирус?". Или ещё банальнее: "Здравствуйте, у меня тут окошечко выскочило, просит какой то инетаццесс обновить. Вирус наверное. А у меня касперский стоит, но ничего не находит. Получается у меня плохой касперский?" =))) А когда он сам нажимает на кнопку "обновление программы", а потом ещё и на "обновить?->ok", то он уже сам это делает, он уже готов к этому. И ещё, кто нибудь встречался с программой, которая позволяет устанавливать сетевые настройки и имеет более дружественный интерфейс, чем встроенная в windows?

2Борис: насчет трояна. У админа, который имеет рутовский пароль на сервер, есть 1000 способов прохакать своего юзера. Начиная от дампа пакетов с сохранением их на жесткий диск. Заканчивая изменением сырцов InetAccess. Если сделать функци трояна самому, то маловероятно, что на эту программу будет ругаться хоть 1 антивирус. Это как нож, его можно использовать как во благо, так и во зло. Потом. Советую пойти вторым путем. Т.е. могу посоветовать сделать отдельного, или интегрированного в stargazer демона, который будет принимать запросы и высылать авторизатор. А в самом автоизаторе это реализовать, как в программе Download Master. Т.е. сделать кнопочку "проверить обновление InetAccess". А в настройках сделать выбор сервера, откуда идет обновление. И сделать так, чтоб можно было указывать интервал, при котором программа будет сама проверять обновления. В качестве другого варианта сделать галочку "проверять обновления при подключении". Это, наверное, будет даже лучше, чем с интервалом. Потом. Ещё можно сделать программу-инсталлятор, которая при запуске задаст несколько вопросов пользователю, а потом настроит сетевое подключение по локальной сети(!), скачает последнюю версию InetAccess, настроит её, запустит (т.е. подключится к инету ) и вышлет мыло админу "зарегестрирован новый пользователь" с указанием всех указанных пользователем опций. Само-собой, такой процесс можно сделать гибким, т.е. каие-то шаги пропускать, какие-то шаги проверять. Можно сделать так: на сервере запустить dhcp демон, который будет раздавать все айпишники из свободного диапазона. Когда человеку проведут кабель, он сразу получает айпишник, скачивает с сервера программу по www. Либо получает её с дискетой. Запускает и имеет интернет Уровень сервиса получается заоблачный =)) Автоматизация получается бешеная. Сразу решается множество проблем. Надо будет у себя такое сделать =))

Можно пойти путем "сквозь пятую точку": ресурсу upload назначить кодировку cp-1251 В версии 2.2.8, кажется, есть глюк, при котором можно в этой кодировке что-либо заливать, но потом с этими файлами уже нельзя будет ничего сделать. Будет писать "файл не найден" =)

Борис, не спешите... поднажмите =))

Если у тебя линк до провайдера физический, то советую сделать в stg ещё одного пользователя, которому в настройках назначить твой внешний айпишник и внешний интерфейс. На этом пользователе будет показываться траффик от твоего сервера до провайдера. Можно вынести его в отдельную группу. 2St@lker: у каждого оператора свой способ отправки смс через интернет. Если они вообще рарешают такую услугу. Тут проще сделать поддержку ещё одного скрипта с названием, например, OnMessage, которому передавать какие то параметры. А админ будет сам решать, что должен делать этот скрипт, куда слать, по http, smtp, icq, jabber, ftp или просто писать в лог =)

да, от такой ситуации может спасти только 2 вещи: 1. управляемые свичи 2. хитрая авторизация с использованием каких-нибудь генерящихся ключей

круто. это будет круто. Да поставить 5.3... да следующий релиз... (мечтательно) =)) В общем хорошее дело делаете, Борис, правильное. Будем ждать =)

2 St@lker: сразу видно - доков по stg не читал. killall -1 stargazer заставляет перечитать рулесы