Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

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

Как защититься от проникновения злоумышленника в свою систему? «Очень просто» - создать непротиворечивую систему защиты. На самом деле это невозможно. Ведь каждый ее компонент, помимо общеизвестных, обладает рядом недокументированных функций, любая из которых может оказаться способной нарушить нормальную работу защиты.

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

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

Теоретически, в отсутствии эксперта, его роль должен выполнять системный администратор. Но хватит ли у него знаний и опыта? В такой ситуации эта книга может оказаться очень полезной.

Среди читателей наверняка окажутся и хакеры, желающие обогатить свой опыт или же совершить свою первую в жизни атаку. Хотелось бы отметить, что не всякое несанкционированное проникновение в защищенную систему влечет за собой нарушение закона. Все зависит от того, кому принадлежит эта система, и чьи права оказались нарушенными. Так, например, атаковать собственный сервер никто не запретит [41]

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

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

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

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

Примером протокола может случить командный язык интерпретатора “command.com”. С его помощью пользователь может управлять файлами и папками своего компьютера. Если попытаться применить ту же схему для взаимодействия с удаленным сервером возникнет необходимость добавить в протокол механизмы установки и управления связью.

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

Причем один язык ничего не знал о существовании другого, - это обеспечивало полную взаимную независимость. В самом деле, для получения файла с сервера достаточно отдать команду “«Получить Файл» («Имя Файла»)”, совершенно не интересуясь, как и чем было создано соединение между двумя компьютерами, - достаточно лишь знать, что оно есть и все.

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