Сначала мне показалось, что прокси-сервер ESPSRV отличается от своих собратьев того же производителя более продуманной реализацией. Помимо основных функций HTTP-прокси он позволяет осуществлять роутинг портов, вести квотирование каналов по потокам и пропускной способности, кэшировать данные адаптивным алгоритмом, применять разрешительные и запретительные правила для доступа к ресурсам Сети — и все это при беспрецедентно низких требованиях к аппаратуре сервера. В большинстве случаев перечисленных возможностей для подсоединения к Интернету в небольшом учреждении бывает достаточно, что и определяет выбор данного продукта.
Первоначальный опыт эксплуатации ESPSRV оставил самые приятные впечатления. Приложение отлично справлялось со своей задачей до тех пор, пока не понадобилось организовать группу пользователей с доступом к определенному количеству разрешенных сайтов (белому списку). Здесь надо отметить, что правила доступа задаются совершенно простым способом: в виде маски для URL, в которой допускается использовать лишь один подстановочный символ — звездочку. С черным списком все работает прекрасно: правила вида *odnoklassniki*, *reklama* и т.п. справляются со своей задачей.
Попытка же открыть доступ к отдельным сайтам по образцу "www.osp.ru*" успехом не увенчалась. Поиск решения на форумах также не дал приемлемого ответа. Рекомендацию применять шаблон "*www.osp.ru*" нельзя считать серьезной, потому что начитанный пионер может легко обойти такое ограничение: "www.odnoklassniki.ru?blablabla=www.osp.ru".
Пришлось заняться анализом проблемы самостоятельно. В первую очередь нужно было выяснить, как программа выполняет сравнение с образцом, что использует в качестве проверяемого URL: "osp.ru", "www.osp.ru" или "http://www.osp.ru"? Для этого был применен отладчик Olly Debugger.
Прокси-сервер запускался с простым тестовым конфигурационным файлом:
GROUP : Admin :
WEIGHT : 3 :
USER : 192.168.0.2 : 255.255.255.255 :
USER : 127.0.0.1 : 255.255.255.255 :
Enable URL : aaa.server.my* :
Enable URL : bbb.server.my* :
Enable URL : ccc.server.my* :
Disable URL : *.* :
Обратите внимание, что в качестве разделителя элементов строки конфигурационного файла разработчики выбрали двоеточие. Забегая вперед, нужно заметить, что такой выбор и стал роковым...
Запускаем Olly Debugger и подключаемся (File • Attach) к процессу espsrv (рис. 1).
Ищем в памяти буфер с шаблонами URL. Открываем окно просмотра оперативной памяти ( + M) и выполняем поиск строки aaa.server.my ( + B). Сначала мы попадем на буфер, в котором сервер сохранил содержимое конфигурационного файла, он нас не интересует. Закроем окно и повторим поиск (+L). Теперь мы оказываемся в области памяти, где сервер хранит шаблоны URL. Поставим точку останова по адресу 00F2-0000 на событие доступа к памяти (рис. 2).
Запускаем продолжение выполнения процесса espsrv .
Приступаем к эксперименту. Для этого необходим как минимум доступ к сервисам DNS. Если на экспериментальной машине с ним проблема, можно прописать тестовый URL в файле hosts. Настраиваем браузер на работу через прокси (рис. 3) и вводим в адресную строку наш тестовый URL, например www.server.my.
Если все было проделано правильно, отладчик остановит выполнение процесса espsrv на команде, обращающейся к шаблону. А зачем нужен шаблон? Конечно же, для сравнения с запрашиваемым URL, о чем красноречиво свидетельствует содержимое регистров ESI и EDI (рис. 4).
Теперь мы убедились, что в качестве операнда для сравнения наш прокси-сервер использует URL в виде http://www.server.my. Значит, для построения белого списка нужно написать так:
Enable URL : aaa.server.my* :
Enable URL : http://www.server.my* :
Enable URL : ccc.server.my*:
Написали? Перезапускаем процесс прокси-сервера, вводим URL в браузер — и убеждаемся, что ничего не работает. Но почему? Снова беремся за отладчик и отыскиваем буфер шаблонов. Достаточно одного взгляда, чтобы понять причину неудач (рис. 5).
Да-да, поскольку двоеточие служит разделителем элементов строки конфигурационного файла, все URL-шаблоны, начинающиеся на http://www...., превращаются просто в http и лишаются своего смысла.
Теперь, когда проблема локализована, стоит рассмотреть варианты ее решения, т. е. способы доработки ESPSRV. Например, можно изменить модуль сравнения URL с шаблонами так, чтобы исключить из этого процесса «протокольную» часть с разделителем http:. Кроме того, можно исправить обработчик параметров Enable URL. А лучше всего поступить концептуально: выбрать другой разделитель для конфигурационных файлов, например, заменить двоеточие вертикальной чертой «|».
Выполнить данную замену в текстовом файле — не проблема. Сложнее сделать так, чтобы программа смогла правильно обрабатывать файлы нового формата. Что мы имеем? Исходников у нас нет. Поскольку компания Extra Systems, если судить по информации на ее сайте, «работает по заказам очень узкого круга весьма требовательных и состоятельных клиентов, перечень которых (в обозримом будущем) не намерена расширять», нам вряд ли удастся обратить ее внимание на нашу проблему. Остается надеяться на свои силы.
Так как метод обработки конфигурационных файлов удобнее анализировать непосредственно в процессе выполнения соответствующих модулей программы, стоит воспользоваться возможностью работы ESPSRV в режиме приложения. Для этого остановим службу espsrv и снова запустим Olly Debugger. Откроем нажатием клавиши исполняемый файл espsrv.exe, указав в аргументах командной строки параметр -APPLICATION (рис. 6).
Нам нужно отыскать в бинарном коде программы команды, выделяющие из строк конфигурационного файла необходимые элементы, выполняя, очевидно, сравнение отдельных символов строки с символом-разделителем, которым пока что служит двоеточие. Этот этап нашей исследовательской деятельности сложно формализовать.
Сначала попробуем отыскать участки кода, с большой долей вероятности связанные с разбором строк. Для этого посредством пункта All referenced text strings контекстного меню выполним поиск всех строк, на которые имеются ссылки в программе (рис. 7).
Просмотрев получившийся список, обратим внимание на те команды, где участвует строка Enableurl. Поскольку эта строка размещена рядом с другими, в значительной степени напоминающими наименования конфигурационных параметров, имеются все основания полагать, что команды относятся к модулю разбора файла конфигурации. С помощью клавиши поставим на них точки останова (рис. 8).
Возвращаемся в основное окно отладчика (нажатием +C) и запускаем программу на выполнение. Дожидаемся первого останова.
Бегло взглянув на окно регистров (рис. 9), приходим к приятному выводу о том, что мы действительно попали на участок кода, имеющий отношение к анализу конфигурационного файла.
Об этом красноречиво свидетельствует регистр EDI, указывающий на строку WEIGHT : 3 :. Значит, нужно продолжать «раскопки» в данном районе с учетом того, что нужный нам код может оказаться как ниже найденного участка (и для его поиска стоит использовать выполнение с погружением на следующие уровни вложенности процедур), так и выше оного. В последнем случае имеет смысл провести анализ содержимого стека вызова процедур, отображающегося в отладчике при нажатии комбинации клавиш +K.
А теперь определим с помощью стека адрес начала той процедуры, в которую мы попали (рис. 10).
Посмотрим, какие еще подпрограммы вызывались до останова. Воспользуемся возможностью Olly Debugger, позволяющей при нажатии на быстро переходить к тому адресу, на который указывает аргумент команды CALL, а с помощью <-> — возвращаться к точке вызова. Вызовы стандартных функций VirtualFree игнорируем, там для нас нет ничего интересного.
Следующие две команды CALL также не имеют отношения к разбору строки. А вот ту подпрограмму, к которой обращается третья по счету команда CALL, нужно рассмотреть повнимательнее. Присутствующие в коде команды сравнения содержимого регистра BL с шестнадцатеричными константами 3A, 20, 9 (которым соответствуют символы ASCII-таблицы двоеточие, пробел и табуляция соответственно) должны навести нас на определенные мысли.
Удалим созданные ранее точки останова из окна Breakpoints (+B) и поставим новые на команды CMP BL, 3A по адресам 0040-6961 и 0040-6981. Запустим продолжение выполнения программы (рис. 11). Так и есть, именно здесь двоеточию придается смысл разделителя!
Теперь остается только заменить коды команд 80FB3A на 80FB7C, и в качестве разделителя программа станет воспринимать символ вертикальной черты. Модификацию EXE-файла можно выполнить в любом шестнадцатеричном редакторе. Если осуществить по файлу поиск участка кода 80FB3A, то можно обнаружить его не в двух местах, а в четырех. Дело в том, что обработку файла с параметрами дискового кэша осуществляет другая подпрограмма, по своей структуре очень похожая на найденную нами.
Более того, если задаться целью, то удастся отыскать и подпрограмму обработки конфигурационных файлов роутинга портов. В ней константы сравниваются с содержимым регистра DL, а не BL, и потому нужно искать код 80FA3A. Только надо учесть, что последняя (третья) из найденных команд — CMP DL, 3A отношения к разбору файла конфигурации не имеет.
Если внести в файл espsrv.exe описанные в предыдущем абзаце изменения, а в конфигурационных файлах заменить «:» на «|», то прокси-сервер с успехом можно использовать для организации доступа по разрешенным URL, записанным в виде: http://www.osp.ru*.
О прокси-серверах
Когда мы встречаем в компьютерной литературе термин «прокси-сервер», то он может относиться к схожим с точки зрения функциональности, но различным по назначению службам. Прокси-серверы играют роль посредников между клиентской программой (как правило, браузером) и каким-либо сервисом (например, веб-сайтом). Так, серверы-анонимайзеры, работающие в Интернете, призваны скрыть источник запросов к сайтам, переотправляя запросы от своего имени.
Локальные прокси-серверы (например, программа Handy-Cache, которую можно найти на сайте http://handycache.ru) предназначены для оптимизации использования интернет-трафика. Установленная на локальном компьютере, такая программа пропускает через себя весь поток данных, вырезая ненужную информацию (например, рекламу), и кэширует (сохраняет) отдельные фрагменты на жестком диске. При повторном обращении к сайту локальный прокси-сервер предлагает браузеру данные из своего кэша, что экономит трафик.
Впрочем, обычно, когда говорят о прокси-сервере, имеют в виду компьютер в локальной сети, на котором работает программа, обеспечивающая совместный доступ в Интернет. Помимо своей основной функции — перенаправления во всемирную Сеть запросов от компьютеров локальной сети — она способна решать задачи, присущие локальному прокси-серверу.
Рост популярности Интернета привел к тому, что было разработано множество прокси-программ. И как это почти всегда бывает, у коммерческих продуктов, к которым относится, например, UserGate (http://www.usergate.ru), появились бесплатные конкуренты. Они уступают комбайну UserGate по удобству настройки, у них нет гарантированной технической поддержки, но знакомство с ними помогает лучше понять возможности программ этой категории, и в большинстве случаев их функционала оказывается достаточно, чтобы решить поставленную задачу.
Наряду с обсуждаемым в данной статье прокси-сервером ESPSRV заслуживают упоминания такие разработки, как 3proxy (http://3proxy.ru), SQUID (http://www.squid-cache.org), FreeProxy (http://www.handcraftedsoftware.org)
Модификация программ
Если в программе обнаруживается ошибка или ее функционал не устраивает пользователя, то лучшее, что можно предпринять, — это сообщить о проблеме автору и попросить внести исправления. Если же автору недосуг заняться пользовательской проблемой, но программа выложена в свободный доступ с исходными текстами, стоит попытаться разобраться в них самому. Кстати, для сборки программы может потребоваться компилятор, которого не окажется под рукой, или язык программирования, на котором написана программа, будет незнаком пользователю.
Когда описанные выше пути разрешения проблемы нельзя реализовать, остается последний, самый универсальный способ — попробовать разобраться с машинным кодом программы и, если удастся, выполнить его модификацию. С одной стороны, этот процесс можно рассматривать как высший пилотаж, с другой — машинный код программ, функционирующий в среде Windows, после некоторой практики кажется ненамного более запутанным, чем чужая программа на языке высокого уровня. Главное, подобрать для работы подходящий инструмент.
Упоминаемый в данной статье отладчик Olly Debugger является, пожалуй, лучшим (если не единственным) продуктом в своем классе. Профессионалы могут указать на его недостаточную функциональность по сравнению с знаменитым SoftICE, однако это все же продукты разного класса. В конечном счете Olly Debugger бесплатен, а также он обладает основными качествами инструмента для исследования программ: умеет работать с программными и аппаратными точками останова (и на исполняемом коде, и на области данных), визуализировать основные алгоритмические конструкции, связывать ссылки, осуществлять пошаговое выполнение анализируемого кода и многое другое.
Автор использовал последнюю стабильную версию отладчика Olly Debugger 1.10, ее можно загрузить с сайта разработчика http://www.ollydbg.de.