Создание и конфигурирование рабочей станции сети предприятия

Автор работы: Пользователь скрыл имя, 22 Декабря 2013 в 18:43, курсовая работа

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

OpenSUSE — дистрибутив Linux. Изначально разрабатывался в Германии, но сейчас его владельцем является американская корпорация Novell, Inc.. Был основан на дистрибутиве Slackware, однако был значительно переделан и представляет собой обособленный дистрибутив, отличается от последнего форматом пакетов, а также системой настройки и администрирования YaST. Со временем SUSE включила в себя много аспектов Red Hat Linux (использование системы RPM и /etc/sysconfig). Лёгкие для пользователей система настройки YaST и система управления пакетами Zypper. Имеется набор драйверов «из коробки». Большой выбор пакетов, за счёт использования RPM и подключаемых репозиториев. Система сборки OBS.

Содержание

Введение 4
1. Создание платформы 5
1.1 Анализ ТЗ 5
1.2 Установка ОС и ее первоначальная настройка 6
2. Администрирование сервисов рабочей станции 9
2.1 Администрирование пользователей и групп 9
2.2 Настройка DNS и LDAP серверов 13
2.2.1 Установка и настройка DNS сервера bind9 14
2.2.2 Установка и настройка LDAP сервера 19
2.3 Установка Samba 25
2.4 Установка apache2+phpldapadmin 30
2.5 DHCP сервер 32
2.6 IPtables 35
3. Аудит созданной системы 39
3.1. Автоматизация 39
3.2. Документация 39
3.3. Поддерживать общение с пользователями 41
3.4 Контролировать ресурсы 42
3.5 Знать потребности пользователей 42
3.6 Знать деятельность предприятия ………………………………………………………….43
3.7 Безопасность ………………………………………………………………………………..44
Заключение 45
Список используемых источников 46

Прикрепленные файлы: 1 файл

ПЗ_tomilov.doc

— 1.14 Мб (Скачать документ)

Пример блокировки пакетов по порту и протоколу:

iptables -I INPUT -p tcp --dport 8180 -j REJECT

Аналогичная ситуация будет если написать DROP .

Открытие порта  для машины с адресом 192.168.1.2 например:

iptables -I INPUT -p tcp --dport 8180 --source 192.168.1.2 -j ACCEPT

Открытие порта  для подсети с адресами 192.168.1.0/24 (255.255.255.0):

iptables -I INPUT -p tcp --dport 8180 --source 192.168.1.0/24 -j ACCEPT

Это правило  приведет к тому , что http - страница апача  например , будет открывается на устройствах данной подсети.

Закрытие порта 80 , результат представлен на рисунке 2.6 :

iptables -I OUTPUT -p tcp --dport 80 -j REJECT

Рисунок 2.6

Пропускание пакетов, по установленным соединениям:

iptables -I INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Такое правило  целесообразно, если есть фильтрация на пакеты, которые устанавливают соединение.

Очистка таблицы  правил filter:

iptables -F

3. Аудит созданной  системы

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

3.1 Автоматизация

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

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

    • Проверка свободного дискового пространства и отчётность по нём
    • Резервное копирование
    • Сбор информации о производительности системы
    • Поддержка учётных записей (создание, удаление и т.п.)
    • Функции, связанные с деятельностью компании (загрузка новых данных на веб-сервер, выполнение ежемесячных, квартальных, кодовых отчётов и пр.)

Автоматизация также повышает предсказуемость  и устойчивость обслуживания пользователей. 

3.2 Документация

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

Правила пишутся для стандартизации и формализации ваших отношений с пользователями. Они проясняют пользователям как обрабатываются их просьбы о помощи и запросы ресурсов. Характер, стиль и способ доведения правил до сведения пользователей варьируются от организации к организации.

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

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

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

    • Имя или инициалы человека, внёсшего изменения
    • Дата внесения изменений
    • Причина по которой были внесены изменений

В результате получаются короткие и полезные записи:

ECB, 12-June-2002 —  Обновил запись для принтера  в бухгалтерии (для поддержки  дуплексной печати у принтера, установленного взамен старого)

3.3 Поддерживать общение  с пользователями

Что касается общения  с пользователями, то его надо всегда поддерживать. Иногда даже маленькие изменения в системе, которые  кажутся практически незаметными, могут совершенно сбить с толку работника из отдела кадров.

Методы общения  с пользователями могут разниться  в зависимости от организации. В  некоторых используют электронную почту; в других — внутренний веб-сайт. Могут также применяться группы новостей или IRC. Где-то будет достаточно листка, прикреплённого к доске объявлений в комнате отдыха.

Как минимум  должно быть описано:

    • Суть изменений
    • Когда они произойдут
    • Почему это происходит
    • Приблизительно сколько этой займёт времени
    • Изменения (если есть), с которыми столкнутся пользователи
    • Контактная информация для вопросов и предложений

3.4 Контролировать ресурсы

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

Ниже приведен список некоторых из них:

    • Системные ресурсы, такие как вычислительная мощность, память и дисковое пространство
    • Пропускная способность сети
    • Имеющиеся в вашем бюджете средства
    • Задачи технического персонала, других системных администраторов и даже других офисных работников
    • Время (часто критической важности, когда оно включает в себя такие параметры, как время резервного копирования системы)
    • Знания (не зависимо от того, хранятся ли они в книгах, системной документации или голове человека, проработавшего в компании последние двадцать лет)

3.5 Знать потребности пользователей

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

Например, возьмем  банковского служащего. Он использует чётко определённый набор приложений и требует относительно небольшого количества системных ресурсов. Теперь возьмем программиста: он использует множество разнообразных приложений и всегда рад дополнительным ресурсам (для ускорения компиляции). Два совершенно разных пользователя с совершенно разными потребностями.

3.6. Знать деятельность  предприятия 

Работает ли администратор в большой, транснациональной  корпорации, или в маленьком училище, он должен понимать чем занимается его организация. Это можно свести к одному вопросу:

Каково назначение систем, которую он администрирует?

Здесь важно  понимать назначение системы в более  глобальном смысле:

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

3.7 Безопасность

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

    • Характер возможных уязвимостей каждой из ваших систем
    • Расположение, тип и значение данных на этих системах
    • Тип и частота авторизованного доступа к системам

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

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

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

Может помочь обучение пользователей; помогайте пользователям  быть в курсе вопросов безопасности и социальной инженерии. Проводите базовый инструктаж по безопасности. Публикуйте ссылки на статьи по вопросам безопасности в вашей внутренней почтовой рассылке.  Реагируйте однозначно и без промедления на вопросы пользователей о вещах, которые кажутся вам опасными [6].

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

Результатом выполнения курсового проекта является прототип  рабочей станции для тестовых конфигураций узлов сети предприятия . Она способна выполнять все функции, определенные в требованиях к курсовому проекту.

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

В перспективе возможна доработка рабочей станции: добавление пользователей и групп в соответствии требованиям организации, установка  почтового сервера, прокси-сервера, настройка систем безопасности сети.

В ходе работы над проектом были получены навыки работы с ОС Linux Ubuntu 10.04 , так же настройки основных сетевых сервисов, в чем и заключается работа администратора.

 

 

 

 

 

 

 

Список использованных источников

    1. Адельштайн Т., Любанович Б. Системное администрирование в Linux. – СПб.: Питер, 2010. – 288 с.: ил.
    2. Далхаймер К., Уэлш М. Запускаем Linux, 5-е издание. – Пер. с англ. – СПб.: Символ-Плюс, 2008. – 992 с.:ил.
    3. Колисниченко Д.Н. Linux-сервер своими руками. – СПб: Наука и Техника, 2002. – 576 с.:ил.
    4. Стахнов А.А. Linux: 3-е изд., перераб. и доп. – СПб.:БХВ-Петербург, 2009. – 1056 с.:ил.

Интернет

    1. ru.wikipedia.org
    2. Философия системного администрирования. И. Песин. : http://ipesin.linux.kiev.ua/translations/rh-phy/ch-philosophy.html
    3. Documentation for Ubuntu 10.04 LTS : https://help.ubuntu.com/10.04/
    4. Многочисленные форумы посвященные системе Ubuntu : http://forum.ubuntu.ru/

 


Информация о работе Создание и конфигурирование рабочей станции сети предприятия