Автоматизированные системы обработки информации и управления

Автор: Пользователь скрыл имя, 11 Января 2012 в 15:12, курсовая работа

Краткое описание

Производственная практика является важным этапом подготовки квалифицированных специалистов. Она является видом учебно-вспомогательного процесса, в ходе которого закрепляется теоретические знания на производстве. Практика является завершающим этапом в процессе подготовки инженера к самостоятельной производственной деятельности. Она являлась подготовкой к работе с аппаратными и программными компонентами локальных вычислительных сетей. Я, Габлая Коба Зазаевич прошел производственную практику с 15.06.2011 по 12.07.2011 в ООО ”Айти сервис” в качестве веб разработчика.В своем отчете я описываю структуру, работу, сферу области деятельности ООО ”Айти сервис”.

Файлы: 1 файл

Чернышев Д.Е.doc

— 214.50 Кб (Скачать)

Из случайного числа  обе стороны создают ключевые данные для шифрования и расшифровывания.

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

 

Протокол изменения  параметров шифрования (The Change Cipher Spec Protocol)

Он существует для  сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато  при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1.

struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec;

Сообщение изменения  шифра посылается и клиентом и  сервером для извещения принимающей  стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение ‘finished’.

 

Протокол тревоги (Alert Protocol)

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

 

Ошибки в протоколе SSL

 

В протоколе SSL обработка  ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера  и клиента разрыва соединения. Протокол SSL определяет следующие ошибки:

Unsupported_Certificate_Type_Error: такая ошибка возникает, когда  клиент/сервер получает тип сертификата,  который не поддерживается. Ошибка  устранима (только для аутентификации  клиента).

No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.

Bad_Certificate_Error: такая  ошибка возникает, когда сертификат  считается принимающей стороной  плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).

No_Certificate_Error: если  послано сообщение Request_Certificate, то  эта ошибка может быть прислана  по причине того, что клиент  не имеет сертификата. Ошибка устранима.

 

Атаки

 

Опишем ряд атак, которые могут быть предприняты  против протокола SSL. Однако SSL устойчив к этим атакам.

 

Раскрытие шифров

Как известно, SSL зависит  от различных криптографических  параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. SSL же делает такую атаку невыгодной, так как тратится большое количество времени и денег.

 

Злоумышленник посередине

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие  трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать  все сообщения, которые следуют  в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.

Атака будет успешной, если:

Сервер не имеет  подписанного сертификата.

Клиент не проверяет  сертификат сервера.

Пользователь игнорирует сообщение об отсутствии подписи  сертификата центром сертификации или о несовпадении сертификата  с кэшированным.

Данный вид атаки  можно встретить в крупных  организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

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

 

Атака отклика

Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 264 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 264 достаточно большое число, чтобы сделать эти атаки бессмысленными.

 

Атака против протокола  рукопожатия

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

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

 
    1. Ознакомление  с Cronjob техналогией

crontab

Каждый пользователь системы имеет свой файл заданий crontab, в котором описано, в какое время и какие программы запускать от имени этого пользователя. Для редактирования файла crontab используется специальная одноименная программа crontab, позволяющая не прерывать процесс cron на время редактирования.

Для редактирования файла crontab вашего пользователя используется команда[2]:

crontab -e

Таблица crontab состоит из 6 колонок, разделяемых пробелами или табуляторами. Первые пять колонок задают время выполнения (МинутаЧасДеньМесяцДень недели), в них может находиться число, список чисел, разделённых запятыми, диапазон чисел, разделённых тире или символ '*'. Все остальные символы в строке интерпретируются как выполняемая команда с её параметрами. Если команда отправляет какой-нибудь текст в стандартный вывод, этот текст отправляется по e-mail пользователю.

* * * * * выполняемая  команда

- - - - -

| | | | |

| | | | ----- День недели (0 - 7) (Воскресенье =0 или =7)

| | | ------- Месяц (1 - 12)

| | --------- День (1 - 31)

| ----------- Час (0 - 23)

------------- Минута (0 - 59)

Пример файла crontab:

# как обычно, с  символа '#' начинаются комментарии

# в качестве командного интерпретатора использовать /bin/sh

SHELL=/bin/sh

# результаты работы  отправлять по этому адресу

MAILTO=paul@example.org

# добавить в PATH

PATH=$PATH:$HOME/bin

 

#### Здесь начинаются  задания

# выполнять каждый  день в 0 часов 5 минут, результат  складывать в log/daily

5 0 * * * $HOME/bin/daily.job >> $HOME/log/daily 2>&1

# выполнять 1 числа  каждого месяца в 14 часов 15 минут

15 14 1 * * $HOME/bin/monthly

# каждый рабочий  день в 22:00

0 22 * * 1-5 echo "Пора  домой" | mail -s "Уже 22:00" john

 

23 */2 * * * echo "Выполняется  в 0:23, 2:23, 4:23 и т. д."

5 4 * * sun echo "Выполняется  в 4:05 в воскресенье"

0 0 1 1 * echo "С новым  годом!"

15 10,13 * * 1,4 echo "Эта  надпись выводится в понедельник  и четверг в 10:15 и 13:15"

0-59 * * * * echo "Выполняется  ежеминутно"

1-59/2 * * * * echo "Выполняется  по нечетным минутам"

# каждые 5 минут

*/5 * * * * echo "Прошло пять минут"

 
Пример Сrontab в Ubuntu 9.10

Редактируем от пользователя user

sudo crontab -e -u user

где user -пользователь от имени которого будет производиться  запуск.

# m h  dom mon dow   command

# Запускаю eMule ночью   в 1 час ночи 10 минут

10 1  * * *  export DISPLAY=:0 && amule

# Останавливаю Emule утром в 10 часов 10 минут

10 10 * * *  export DISPLAY=:0 && killall amule

'#' — является комментарием.

export DISPLAY=:0 && -Выводим на дисплей (если есть что выводить)

часто этого не достаточно для запуска графических  приложений, для возможности локально подключаться к X серверу необходимо добавить

 xhost +local:

в файл .profile находящийся  в домашнем каталоге пользователя.

 
 

 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Заключение  студента по итогам практики

(выводы  и предложения)

 

Заключение  о прохождении  производственно-технологической        практики

Студентом

                                            Габлая Коба Зазаевич

(Ф.И.О.)

Факультета ____________Экономики  и управления______________________

Специальности___ «Автоматизированные системы обработки  информации и урпавления»_______________________________________________________

Курса _____5_______ Формы обучения ___ОФО_______ Группы _05-АСУ__

 

в должности ________ системный администратор________________________

Информация о работе Автоматизированные системы обработки информации и управления