книги хакеры / журнал хакер / 115_Optimized

>>

ХАКЕР

Счетчики производительности — популярный, но крайне ненадежный способ измерений

SoftICE, будучи отладчиком уровня ядра, позволяет остановить систему в любой момент и посмотреть, какими интересными делами она сейчас занимается. С ним поиск «бутылочного горлышка» занимает буквально считанные минуты, причем результат абсолютно надежен. Не скрыться ни

«кривым» драйверам, ни некорректно работающему аппаратному обеспечению. Кстати, знания ассемблера не потребуется — невероятно, но факт! Достаточно освоить несколько несложных команд, а все остальное SoftIce сделает сам!

Сеанстермоядернойотладки

Как узнать, на что уходит львиная доля системного времени? Очень просто

— установить SoftIce, вызвать его комбинацией <CTRL-D>, посмотреть, чем занимается сервер. Выйти из SoftICE по <CTRL-D> или команде «x;<ENTER>», затем тут же вызывать его вновь (чем занимается система на этот раз?). Повторяя данную операцию в цикле, можно быстро собрать богатый статистический материал. Совершенно очевидно: истинное процессорное время, потребляемое каждым компонентом, прямо пропорционально частоте его появления при вызове отладчика.

Когда сервер вообще ничем не нагружен, свыше 90% «всплытий» приходится на псевдопроцесс «Idle». Он означает, что текущие операции выполняются столь быстро, что мы их просто не засекаем (так как они занимают ничтожные доли процессорного времени). При этом сервер может обслуживать достаточно большое количество пользователей, дефрагментировать жесткий диск в фоновом режиме и заниматься прочими делами. Вот так парадокс! Сервер работает, а процессор — отдыхает. Это означает, что конфигурация сервера имеет определенный избыток по мощности и узких мест в ней нет.

При дальнейшем росте загрузки мы получаем более или менее «гладкое» распределение, попадая то в интерпретатор PHP, то в процесс, обслуживающий SQL, то в другой сервис. Вполне нормальное явление, однако доминирование одного процесса над другим — плохой признак, указывающий на дефекты проектирования программы. В нормальной ситуации свыше 90% машинного времени уходит на ввод/вывод, в течение которого процессы, инициировавшие запрос ввода/вывода, спят, как младенцы, независимо от того, справляется дисковая подсистема/сетевая карта со своей работой или нет.

Повышение активности процессов свидетельствует о «тяжелых» операциях типа криптографии, упаковке/распаковке потока данных и прочих «наукоемких» задачах, большинство из которых, кстати говоря, сугубо опциональны. В частности, шифрование можно либо вообще отключить, либо выбрать более «легкие» алгоритмы. Аналогично обстоит дело и с упаковкой. Естественно, ситуацию с вещанием цифрового аудио/видео мы в расчет не берем. Тут, понятно, требуется мощный процессор с емкой кэшпамятью. А как узнать, что кэш-памяти достаточно для решения поставленной задачи? Очень просто! Если SoftICE останавливается на произвольных машинных инструкциях — все ОК. А вот если доминируют инструкции

Просмотр стека позволяет определить, какой именно драйвер вызывает функции ядра

чтения/записи в память (MOVплюс что-то в квадратных скобках, а также MOVSx, CMPSxи STOSx), то установка процессора с более емкой кэш-памя- тью существенно поднимет производительность!

Но это теория, переходим к практике и вещам, далеко не очевидным даже для тех, кто давно использует SoftICE. Имя процесса, исполняемого в данный момент, отображается в правом нижнем углу, а текущий исполняемый код — в окне CODE, расположенном посередине экрана. В правильно сконструированной программе процесс останавливается каждый раз в случайном месте. То есть колонка адресов будет отличаться. Это означает, что в исследуемом процессе нет горячих точек (или они выражены крайне слабо). Напротив, если какие-то диапазоны адресов встречаются чаще остальных — мы поймали горячую точку, которую разработчики программы должны были устранить еще на стадии проектирования, ну или, в крайнем случае, в процессе оптимизации продукта перед выбросом его на рынок.

Почемусчетчики производительнос тиненадежны

Почемужеошибаютсясчетчикипроизводительностии,вчастности,индикаторзагрузкипроцессора?Деловтом,чтопод«загрузкой процессора»создателиNTпонимаютотнюдьнезагрузкупроцессора, кактаковую,аготовностьпотокаподелитьсяостаткамиквантаотпущенногоемупроцессорноговремени.Нахакерскихконференциях былопродемонстрированобольшоеколичествоexploit’ов,отдаю- щих~3%-5%отполногоквантавремениизаставляющихсчетчик производительностиотображатьзагрузкублизкуюкнулевой,чем суспехомпользуютсямногиезловредныепрограммы(например, использующиераспределенныесетидлявзломапаролей).

Другойисточникошибок—асинхронныеоперацииввода/выво- да,поддерживаемыеядром.Причтенииданныхсдискаилифайла подкачкипоток«замораживается»системой,передающейуправлениепотокамэтогожеилидругогопроцесса,врезультатечегопоток, инициирующийпроцессчтения,показываетнамногоболеенизкое потреблениепроцессорноговремени,чемпроисходитвдействительности.Строгоговоря,индикаторзагрузкинелжет.Потокдействительно«спит»вовремячтениясдиска,новедьнасинтересуетне формальнаясторонапроблемы,аполноевремя,включающеевсебя длительностьвсехоперацийввода/вывода,посколькуинтенсивный ввод/вывод—отличноесредствоторможения!

Наконец,счетчикзагрузкиЦПнеучитываетвремя,потребляемое драйверами.«Загрузкаядра»болееилименеекорректновычисляется толькодлянекоторыхсистемныхвызовов,даитоскучейоговороки ограничений.

>>

ХАКЕР

знакомство с портами ввода/вывода

драйвер, в чьих границах находится обозначенный адрес, и есть «виновник». в нашем случае — это ndis, низкоуровневый сетевой драйвер. При интенсивной работе сетевой карты его появление в softice вполне объяснимо, приемлемо и понятно. однако это должна быть действительно очень высокая нагрузка, иначе — имеем дело с кривым драйвером или неправильной сетевой картой, смена которой (вместе с драйвером) ощутимо повысит общую производительность сервера. Причем (внимание!), факт подобной «кривизны» не определяют ни системный монитор, ни легион программ, предназначенных для тюнинга сервера, поскольку все они работают на более высоком уровне.

другая распространенная ситуация — softice начинает часто всплывать на команде чтения (реже — записи) в/из порт ввода-вывода. это плохой признак! нормальное железо, управляемое правильными драйверами, работает по прерыванию, обмениваясь данными через dMA. обращения

кпортам лишь инициируют ту или иную операцию, а потому занимают ничтожное время.

Интенсивная работа с портами ввода/вывода нагружает системную шину, снижая производительность всех подсистем компьютера в целом, а потому такой ситуации необходимо избегать любой ценой. легко сказать — избегать! для этого, как минимум, необходимо определить, к какому именно оборудованию обращается система. no problem!

смотрим на значение, содержащееся в регистре dX (младшие 16-бит регистра edX или, выражаясь человеческим языком, крайние четыре цифры справа). выходим из отладчика, запускаем «диспетчер устройств». в меню «вид» выбираем сортировку устройств по ресурсам и в портах ввода/вывода тут же находим наш порт, равный в данном случае 379h и принадлежащий lPt1 — порту принтера, который вообще не установлен на обозначенной системе. хм, странно, принтера нет, а обращения к порту происходят с высокой степенью интенсивности, причем не по прерыванию, а по опросу (готовности устройства).

лезем в очередь печати и видим, что в ней каким-то чудом оказался некий документ, и какой-то левый принтер (в смысле, его драйвер) «мистически» повешен на lPt1, хотя физического принтера нет. очищаем очередь печати

— не очищается! сносим драйвер — обращение к порту исчезает, а машина летит вперед с такой производительностью, что буквально отрывается от асфальта. другим путем обнаружить «бутылочное горлышко» не удавалось

— системный монитор упорно твердил, что все нормально, никаких косяков. наконец, softice может останавливаться не только внутри драйверов, но

и ядерных функций, лежащих в области адресов 8xxxxxxxh, где находится ntoskrnl.exe. само ядро тут, понятное дело, не причем. это просто какой-то противный драйвер напрягает его вызовом тех или иных функций. что же это за драйвер такой?

даем команду «stAck» и смотрим на левую колонку адресов, по которой и определяем драйвер описанным выше способом. в данном случае им оказался драйвер dvd-привода, автоматически установленный системой. тщательное расследование выяснило, что к драйверу никаких претензий нет, а дефект проектирования dvd-привода привел

ктому, что драйвер начинал обмениваться с ним какими-то командами (они так и не были найдены в стандарте на AtAPi-команды), даже если в лотке отсутствовал диск. смена dvd-привода «утихомирила» драйвер, «волшебный» обмен прекратился, а общая производительность системы опять-таки возросла.

определение оборудования, к которому происходит обращение через «диспетчер устройств»

заключение

мы убедились, что поиск «узких» мест сервера при помощи softice — это простой, но надежный способ, охватывающий абсолютно все уровни: аппаратный, ядерный и программный. конечно, не стоит ждать от softice точных «телеметрических» показаний, выраженных в численном виде. в общемто, этого и не нужно. если в системе имеется «бутылочное горлышко», то softice обнаружит его практически сразу после пяти-шести вызовов.

к недостаткам способа следует отнести, что на Win2k3 в 32-разрядном режиме он еще работает (и то, не со всеми видеокартами и чипсетами), но более новые системы ему не по зубам. к тому же, softice способен обрушивать систему, вызывая голубые экраны смерти, зависания (от которых порой не спасает и reset, а только «передерживание» питания) и перезагрузки. Последние два случая очень опасны — сброса дисковых буферов не происходит, и раздел, с которым ведется активная работа на чтение/ запись, рискует отправиться к праотцам. но даже если «полет нормальный», в момент вызова softice сервер останавливает системные часы (которые потом нам придется корректировать) и прекращает весь сетевой обмен, что при продолжительном пребывании в отладчике ведет к обрыву tcP/iP-соединений, вызывая естественное недовольство пользователей. z

Производительность

Производительностьсерверазависитнетолькоотмощностиаппаратнойчасти,ноиотпрограммнойоснастки.Один«кривой»драйвер (приложение)способенсожратьвсересурсы,затормозивсистему доуровняасфальтовогокатка,исистемныймониторнепокажет ровнымсчетомничего!Какнайтивиновника?Измножествапрограммсамымдоступным,точныминадежныминструментом,какни странно,оказываетсяотладчикSoftICE.

КривоеПО

Сплошьирядомприходитсясталкиватьсясситуацией,когдапри нулевой(поиндикатору)загрузкепроцессорработаетвовсюмощь

—илиже,наоборот,загрузкавплотнуюприближаетсяк100%,но процессорневыполняетникакойполезнойработы,например,мотая холостойциклилиожидаясигналаотвнешнихустройств.Втакой ситуациинеобходимоменятьнепроцессор,акривонаписанноеПО.

ульяНа сМелая

VPnнаБазеssH

впоследнеевремятехнологияvPnполучилазавидноераспространение.обычно,упоминаяее,подразумеваютлибостандартныепротоколы туннелированияPPtPиl2tP/iPsec,либоспециализированныерешения, вродеOpenvPn,илишьнемногиезнаютоболеепростойальтернативе

—ssh-туннелинг.ПоднятыенавторомилитретьемуровнеOsiзашифрован- ныетуннелиобеспечатприложениямполноценныйипрозрачныйдоступ

клюбымресурсамудаленнойсети.Аучитывая,чтоssh-сессиинетолько шифруются(поумолчаниюзадействованалгоритмAes),ноисжимаются, мы,кромеприватности,получимнебольшойприроствскоростииэкономию драгоценныхмегабайтов.немаловажно,чтотакойподходнетребуетзнания протоколовзащитысетевоготрафика,вмешательствавядрооперационной системы,заморочексфильтрациейпакетовилиналичияособыхпрограмм. дляпримеравозьмемдвасервера:srv1сiP-адресами212.34.XX.yyи192.168.2.1 подключенксегментувнутреннейсети192.168.2.0/24,аsrv2с213.167.XX.yyи 192.168.1.1шефствуетнадподопечнымииз192.168.1.0/24.настроимvPn-тун- нельсредствамиOpenssh,вкоторомбудутиспользоватьсяадреса10.0.0.1и 10.0.0.2.длянаглядностисценарийможнопредставитьследующимобразом:

стоитотметить,спомощьюOpenSSHвозможнопостроениенетолькоsite- to-sitevPn(межсайтовоеподключение,вкоторомдвамаршрутизатора создаюттуннельвинтернете),ноиclient-to-site(vPn-подключениеудален- ногодоступадляпроводныхибеспроводныхклиентов).

ключевыеэлементысетевойконфигурациирассмотрены,теперьприступаемкнастройкам.логинимсянаsrv1иправимглавныйконфигурационный файлsshd:

srv1% sudo vim /etc/ssh/sshd_config

#Разрешаем туннелирование layer-3 PermitTunnel point-to-point

#VPN на базе OpenSSH требует привилегий суперпользова-

>>

ХАКЕР

Управляющие последовательности в действии

теля, поэтому аутентификацию под учетной записью root разрешаем только с доверенных хостов

PermitRootLogin no

Match Host 213.167.XX.YY,192.168.2.*,127.0.0.1 PermitRootLogin yes

ПоокончаниинастроекнезабываемотправитьдемонусигналSIGHUP, чтобыонсмогперечитатьсвойконфиг:

srv1% sudo sh -c "kill -HUP 'sed q /var/run/sshd.pid'"

Далееразрешаемпрохождениепакетовнаиспользуемыхтуннельных псевдоустройствах(наtun0уменявиситOpenVPN,tun1—дляOpenSSH;tun представляетсобойнечтовродедрайвераIP-туннелей):

srv1% sudo vim /etc/pf.conf

pass quick on { tun0, tun1 } inet all

Загружаемправилаизконфига:

srv1% sudo pfctl -f /etc/pf.conf

Создаеминтерфейсtun1иназначаемемуIP-адрес:

srv1% sudo ifconfig tun1 create

srv1% sudo ifconfig tun1 10.0.0.1 10.0.0.2 netmask 0xfffffffc

Припомощикомандыifconfigпроверяемегосостояние:

srv1% ifconfig tun1

tun1: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500 groups: tun

inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc

Незабываемдобавитьвтаблицумаршрутизацииудаленнуюподсеть:

srv1% sudo route add 192.168.1.0/24 10.0.0.2

ВторойсервервыступаетвролиSSH-клиента,поэтомупроцедураконфигу- рированияздесьчутьпроще:

srv2% sudo sh -c "echo 'Tunnel point-to-point' \ >> /etc/ssh/ssh_config"

Остальныенастройкиидействияпрактическиидентичныописаннымвыше: правимиактивируемрулесетыфайрвола,поднимаемtun1,присваиваем емусетевойадрес(обративнимание,порядокследованияIP-адресовизме- нен)идобавляемстатическиймаршрут:

srv2% sudo vim /etc/pf.conf

pass quick on { tun0, tun1 } inet all

srv2% sudo pfctl -f /etc/pf.conf srv2% sudo ifconfig tun1 create

srv2% sudo ifconfig tun1 10.0.0.2 10.0.0.1 netmask 0xfffffffc

srv2% sudo route add 192.168.2.0/24 10.0.0.1

И,наконец,самыйответственныймомент—устанавливаемзащищенное соединениемеждудвумясетями:

srv2% sudo ssh -f -w 1:1 212.34.XX.YY true

Чтобыснизитьнакладныерасходы,кспискуаргументовимеетсмыслдоба- вить:-o Compression=yes -x -a -n(сжиматьпередаваемыеданные, отключитьпересылкупакетовX11,запретитьаутентификациюспомощью агентаинаправить /dev/nullнастандартныйвходнойпотокSTDIN). Теперьпроверимдоступностьудаленногоузла,находящегося«запервым сервером»:

srv2% ping 192.168.2.101

PING 192.168.2.101 (192.168.2.101): 56 data bytes 64 bytes from 192.168.2.101: icmp_seq=0 ttl=127 time=2.508 ms

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

srv2% sudo sh -c "echo '10.0.0.2 10.0.0.1 netmask 0xfffffffc' \ > /etc/hostname.tun1"

Илизанестинеобходимыестатическиемаршрутыизапуск«ssh -f -w»водин изсценариевначальнойзагрузки(/etc/rc.local).Либовотдельныйскрипт, чтобывсевыполнялосьоднойкомандой,бездополнительныхтелодвижений.

ЧтобыиспользоватьOpenSSHнауровнеOSI2,нужновкачествезначения директивPermitTunnelиTunnelиспользоватьethernet,азатемобъединить вмоствнешнийсетевойинтерфейсипсевдоустройствоtunX(см.bridge(4)).

УправляющиепоследовательностиSSH

Продолжимфокусничать.Таинствомагииуправляющихпоследователь- ностейоткроется,есливSSH-сессиисначаланажать<Enter>,затем

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

Перенаправление X11-подключений

ДляперенаправленияX11 подключенийследуетиспользоватьключ

–Y:

$ ssh -Y user@domain.com

Причемвконфиге/etc/ssh/sshd_config параметр X11Forwardingдолженбытьустановленв«yes».ЕслиX-серверзапу- щенналокальнойсистеме,тоактивируемиX11UseLocalhost.

Админдолженбытьленив!

Чтобывконсолиневводитьполноедоменноеимя,порти учетнуюзаписьдляподключениякудаленнойсистеме,стоит заручитьсяподдержкойдирективыHost:

%vim~/.ssh/config

Host mx2

Hostname mx2.domain.ru

Port 2022

User admin

Такимобразом,намдостаточноввести«ssh mx2»,—имы попадемназаветныйсервер.Уженеплохо,однакокаждыйраз приходитсянабиратьчетыре«лишних»символа(sshипробел). Леньсподвигаетнанаписаниедвухстрочногосценария,«съедающего»ssh,носохраняющеговсепереданныевкомандной строкеаргументы,пробелыикавычки:

%cd ~/bin

%vimmyssh

#!/bin/sh

exec /usr/bin/ssh '/usr/bin/basename $0' $@

Наделяемскриптатрибутомисполненияисоздаемсимволическуюссылкунапсевдонимудаленногосервера:

%chmod +x myssh

%ln -s myssh mx2

Вводитьsshбольшенетребуется(P.S.Подкаталогbinдолжен бытьпрописанвпеременнойокруженияPATH):

% mx2 uptime

5:16PM up 45 days, 8:40, 0 users, load averages: 0.55, 0.40, 0.35

Еслиузловнесколько,тодлякаждогосоздаеманалогичнуюсимволическуюссылку,выбраввкачествеимениего hostname.

Небольшойоптимизацииможнодостигнуть,отказавшись отвызоваутилитыbasename(1)ипримениввстроенные возможностикоманднойоболочки:

%vimmyssh

#!/bin/sh

exec /usr/bin/ssh ${0##*/} $@

Обходимфайрволы

Многиеадминистраторывцеляхбезопасностискрываютсвои серверавдемилитаризованнойзонелибозаNAT’омиразре- шаютвходящиесоединениятолькосдоверенныхIP-адресови поопределеннымпортам.Поэтомудоступкомногимполезным ресурсамполучитьнапрямуюнельзя.Этокакразтотслучай, когдаиспользованиеSSH-форвардингаможетисправитьси- туацию.Некоторыепримерыбылирассмотренывпредыдущем номережурнала,встатье«Калейдоскоптайныхзнаний».Вот ещеодинвариант:

%vim~/.ssh/config

#Шлюз на базе OpenBSD Host gate

Hostname gate.domain.ru

#Для ускорения соединений включаем мультиплексирование SSH-сессий

>>

ХАКЕР

ControlMaster auto

ControlPath ~/.ssh/ctl-%r-%h-%p

#Перенаправляем локальный порт на файловый сервер

(Win2k3 с поднятым VShell)

LocalForward 8022 192.168.1.101:22

#Подключаясь к localhost:8022, мы будем попадать в файлопомойку

Host fileserver Hostname localhost Port 8022 ControlMaster auto

ControlPath ~/.ssh/ctl-%r-%h-%p HostKeyAlias fileserver

Соединяемсясузломgateипроверяемвозможностьподключенияклокальномупорту8022:

%ssh -N -f gate

%telnet localhost 8022

SSH-2.0 VShell_3_0_4_656 VShell

Теперьможнологинитьсянафайловыйсервер,которыйнаходитсяза NAT’ом,вобходрулесетов,установленныхнашлюзе:

% ssh fileserver

Microsoft Windows [Version 5.2.3790] C:\Documents and Settings\Smelaya\My Documents>

Каквидишь,SSH-туннель—этосамыйпростойспособ,позволяющий обойтифайрволиполучитьдоступкзакрытомуадминомсервису.Естьи специализированныеприложения,предназначенныедляболееудобной организацииSSH-туннелей.Например,RSTunnel(ReliableSSHTunnel, rstunnel.sf.net),Corkscrew(www.agroman.net/corkscrew)идругие.

БезопасныйSFTP

Многиехостинговыекомпаниипредоставляютсвоимпользователямдоступ поFTP.Назначениекаталоговможетбытьразное,нонасинтересует,как сделатьдоступбезопаснее.ЗдесьнапомощьтакжеможетприйтиSSH:

%sudovim/etc/ssh/sshd_config

Subsystem sftp internal-sftp

#Секция с хостинговыми клиентами

Match Group wwwusers

#Отключаем форвардинг

X11Forwarding no AllowTcpForwarding no

# Работаем по защищенному протоколу SFTP в chroot окружении

ForceCommand internal-sftp ChrootDirectory /var/www/hosting/%u

Теперьзарегистрированныепользователибудутдопущенытолькок«своему»каталогу,приподключениимодификатор«%u»будетзамененименем пользователя.Принеобходимостиможноиспользовать«%h»,который соответствуетдомашнемукаталогуюзера.

ОграничениеподключенийкSSH

СервисSSH—любимаямишеньзлоумышленников,поэтомуследуетпринять некоторыепредосторожности.Однаизних—ограничениеколичества подключений,чтобыизбежатьDoS-атакиибрутфорсапаролей.Есливлогах тынаходишьбольшоеколичествозаписейвроде:«Failed password for root from» или «Invalid user admin from»,можешьбытьуверен

—ктвоемусерверуподбираютпаролиприпомощипрограмм-брутфорсеров. Паниковатьнестоит,этупроблемуможнорешитьоченьпросто.Приведу правиладляiptables:

#iptables -A INPUT -p tcp — dport 8022 -i eth1 -m state \ –state NEW -m recent — set

#iptables -A INPUT -p tcp — dport 8022 -i eth1 -m state \ –state NEW -m recent — update — seconds 300 \ –hitcount 3 -j DROP

Такмыразрешилитриподключенияк8022портувтечениепятиминут.ВPF несложнее:

%sudovim/etc/pf.conf

table <sshbf> persist

block in log quick on $ext_if inet from <sshbf>

pass in log on $ext_if inet proto tcp to $ext_if port ssh keep state \

(max-src-conn-rate 5/60, overload <sshbf> flush global)

Здесьфильтрпакетовнедопуститболеепятиодновременныхсоединенийк 22портуза60секунд.Прижеланииправиламожноужесточить.

Заключение

СпомощьюсемействакомандSSHможнонетолькообеспечитьаутентификациюишифрованиеданныхмеждухостами,существеннозатрудняя перехватсостороныдругихузлов,ноисоздатьвиртуальнуючастнуюсеть, объединяющуюнесколькокомпьютеровилисетей,обойтиэшелонированныезаслоны,заботливовыставленныеадмином,инаделитьразличные приложенияновымфункционалом.НаборсетевыхинструментовOpenSSH обладаетчрезвычайнобогатымивозможностями,иснимистоитпознакомитьсяпоближе.z

Крис КасперсКи