Linux глазами хакера - Михаил Флёнов

Далее идет описание скорости и прав доступа для второго пула:

delay_parameters 2 256000/256000 4000/8000

delay_access 2 allow all

delay_access 2 deny admins

Так как второй пул относится ко 2 классу, то здесь нужно указать общую скорость (256 000 байт в секунду) и скорость доступа каждого компьютера в отдельности — 4000 байт в секунду. На такой скорости будут работать все пользователи в сети, кроме администраторов.

Если вы установите такие правила в какой-либо организации, то могут возникнуть проблемы с руководством, потому что директор тоже попадет в список all и будет работать на скорости 4000 байт в секунду. Я думаю, что его это не устроит, и для него мы сделаем отдельную запись:

delay_parameters 3 64000/64000

delay_access 3 deny all

delay_access 3 allow bigboss

С помощью ограничения пропускной способности канала можно запретить загрузку мультимедийных файлов в рабочее время. В следующем примере мы разрешаем быстро читать Web-странички, но уменьшаем скорость загрузки других медиафайлов (листинг 9.4).

# ACL-список, описывающий сеть

acl fullspeed url_regex -i 192.168.1

# ACL-список, описывающий медиафайлы, для которых необходимо

# понизить скорость

acl mediaspeed url_regex -i ftp .exe .mp3 .avi .mpeg .iso .wav

# Время, которое будет действовать ограничение на скорость

# загрузки медиафайлов

acl day time 08:00-18:59

# Нам нужно два пула второго класса

delay_pools 2

delay_class 1 2

delay_class 2 2

# Первый пул не имеет ограничений для всех

delay_parameters 1 -1/-1 -1/-1

delay_access 1 allow fullspeed

# Второй пул ограничивает доступ в дневное время

delay_parameters 2 4000/100000 4000/100000

delay_access 2 allow day

delay_access 2 deny !day

delay_access 2 allow mediaspeed

Я постарался снабдить листинг подробными комментариями, чтобы вы могли с ним разобраться без дополнительных пояснений. Хочу только заметить, что скорость понижается для всех. Если вы хотите разрешить определенным пользователям работать на полной скорости, можно внести их в список (например, allowfull) и добавить в конец листинга следующую строку:

delay_access 2 deny !allowfull

9.6. Кэширование браузером

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

Помимо централизованного кэширования с помощью прокси-сервера может использоваться локальный кэш сетевых программ. Например, в браузере Mozilla прочитанные страницы могут сохраняться в кэше на локальном диске. При следующем их вызове не происходит обращения даже к прокси- серверу, а страничка загружается из локального кэша.

На рис. 9.3 показано окно настройки кэша в браузере Mozilla. Как видите, Memory Cache по умолчанию составляет 4096 Кбайт — это максимальный размер оперативной памяти для хранения последних загруженных страниц. Использование кэша памяти увеличивает скорость, когда вы путешествуете по одному и тому нее сайту, а при переходе от страницы к странице большинство графических образов сохраняется. Чтобы не делать даже лишних обращений к диску, последние загруженные файлы берутся прямо из оперативной памяти.

Рис. 9.3. Настройка кэширования в браузере Mozilla

Еще один параметр отвечает за размер кэша на жестком диске (Disk Cache). Это максимальный размер директории, которая хранит загруженные из Интернета файлы. В моей системе значение по умолчанию равно 50 000 Кбайт (около 50 Мбайт). Это очень мало, и при регулярной работе с Web вы не заметите, как израсходуется это пространство. Если позволяет свободное место на жестком диске, то я рекомендую увеличить это значение. Еще ниже есть поле Disk Cache Folder, в котором указывается расположение папки для хранения кэша.

И последнее, что можно настроить — условие, когда информация должна быть загружена с сервера, а не из кэша. Здесь можно выбрать одно из значений:

□ Every time I view the page — обновление будет происходить каждый раз, когда вы обращаетесь к странице, а значит локальный кэш использоваться не будет;

□ When the page is out of date — когда страница устарела;

□ Once per session — единожды за сессию, т.е. только при первом заходе;

□ Never — никогда. Страница всегда будет загружаться из кэша, а для обновления нужно нажать кнопку Reload (Перезагрузить) на панели инструментов браузера.

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

Глава 10

Передача файлов

Вспоминаю времена, когда построение сети было делом дорогим, а Интернет — еще дороже, и для обмена файлами приходилось бегать с дискетами 3,5 или 5,25 дюймов. Если кто-либо застал те времена, то, вероятно, вспоминает их с ужасом. Дискеты постоянно портились, и данные периодически переставали читаться. Благо, если расстояние небольшое, и можно было повторить пробежку, но когда дистанция стайерская, — потеря очень сильно отражалась на эмоциональном состоянии.

До сих пор в некоторые компьютеры вставляют дисководы для 3,5 дюймовых дискет, потому что дешевой альтернативы нет. Но уже трудно представить себе офис без полноценной сети, и в фирмах, где мне приходилось настраивать серверы, все компьютеры обязательно подключены к локальной сети. В таких случаях уже нет надобности в дисководах, и администраторы их просто вынимают. Если у вас возник вопрос, зачем вытаскивать то, что может пригодиться, значит, вы забыли, что ничего лишнего не должно быть. Это касается не только программ, но и компьютерного железа.

Через дискеты хакеры легко могут унести секретную информацию, получив физический доступ к компьютеру. Мне известна фирма, которая содержала локальную сеть, оторванную от внешнего мира, и считала себя неприступной. Но когда секретная информация утекла с помощью простых дискет через все охранные системы, потому что металлоискатели не срабатывают на 3,5 дюймовые дискеты, и были потеряны рынки сбыта, только после этого все компьютеры лишились опасного устройства.

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

В настоящее время самым популярным протоколом обмена файлами является FTP (File Transfer Protocol, протокол передачи файлов). Он был разработан достаточно давно, но до сих пор не потерял своей актуальности, хотя некоторые возможности оставляют желать лучшего.

10.1. Работа FTP-протокола

Как мы уже говорили в гл. 6, для использования FTP-протокола требуется две составляющие: клиент и сервер. Для работы с FTP-сервером можно использовать любой Telnet-клиент, и подключившись к 21 порту сервера, вручную передавать команды. Но во времена графического интерфейса нужно что-то более удобное. В ОС Windows мой любимый FTP-клиент — CyD FTP Client XP (www.cydsoft.com), главное окно программы можно увидеть на рис. 10.1.

Рис. 10.1. Главное окно программы CyD FTP Client XP

Если у вас нет FTP-клиента, то для тестирования протокола можно использовать даже браузер, например, Internet Explorer или Netscape. Для этого в строке URL нужно набрать адрес: в формате ftp://имя:пароль@адрес.

Например:

ftp://flenov:[email protected]_server.com

или

ftp://flenov:[email protected]

Протокол FTP работает сразу на двух портах: один используется для управления (пересылка команд), а другой — для передачи данных (файлов). Программа-клиент соединяется с 21 портом и начинает передавать команды. К этому порту подключаются все пользователи, и сервис, который прослушивает этот канал, работает одновременно с несколькими соединениями.

Когда клиент запрашивает данные, открывается еще одно соединение с конкретным пользователем, по которому передается файл. Это удобно с точки зрения программирования, но несподручно с точки зрения администрирования, точнее сказать, конфигурирования сетевого экрана.

Большинство команд, используемых в протоколе FTP, схожи с теми директивами, которые вы используете в Linux для управления файлами. Это связано с тем, что во время разработки протокола основной сетевой ОС являлась Unix-система. Это в наше время везде стоит Windows, а 20 лет назад все было иначе.