Одминский блог

Автозагрузка в CentOS

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

Собственно в CentOS процесс загрузки работает по принципу System V и расписан в файле  /etc/inittab, точнее расписано то как процесс INIT отрабатывает уровни загрузки. В системе фалы загрузки находятся в каталоге /etc/rc.d и носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, и rc6.d. Пользователи могут размещать файлы в этих каталогах которые будут контролировать запуск сервисов в системе.В свою очередь эти фалы линкуются на каталог /etc/rc.d/init.d и содержащиеся в них скрипты запуска процессов. В этой связи для запуска сервиса необходимо создать полноценный файл запуска сервиса в /etc/init.d, после чего задать символический линк на него из папки соответствующей тому уровню запуска, на котором необходимо стартовать данный сервис. Файлик запуска сервиса будет выглядеть следующим образом, хотя можно расписать все  пару строк просто строкой запуска сервиса:

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Foo server
#

exit 0

Если нет желания заморачиваться с написанием скрипта, то можно добавить строку инициализации запуска сервиса в файл /etc/rc.local. Это файл будет отработан в самом конце загрузки системы, но перед выдачей меню логина.

Для добавления сервисов находящихся в попдапках rc0.d – rc6.d в автозагрузку в системе есть специальная утилита chkconfig, с помощью которой можно добавлять или исключать сервисы.

# chkconfig -l service_name # просмотреть уровни автозагрузки сервиса
# chkconfig  –level 34 service_name on|off|reset # вкключить или выключить сервис на 3 и 4 уровнях
# chkconfig  –del service_ name # удалить службу
# chkconfig  service_name on|off # включить или выключить службу на всех уровнях
ну и есессно главная команда:
# man chkconfig

Помимо этого можно воспользоваться утилитой ntsysv , для редактирования всех уровней или задач редактирования для определенного уровня:
# ntsysv –level 34

Рубрика: Linux | Отзывов: 2 »

Сравнение оборудования Cisco и Check Point

Если рассуждать о соответствии оборудования Cisco и Check Point то надо четко понимать некоторые аспекты направленности бизнеса этих двух компаний, ибо эти два вендора принадлежат к разным нишам информационных технологий, поскольку Cisco в первую очередь это телеком и сетевое оборудование, а Check Point это исключительно решения информационной безопасности. По этой самой причине у этих компаний совершенно разный технологический подход к их решениям. Cisco предлагает в своих решениях межсетевых экранов ASA прежде всего межсетевой экран и возможность построения VPN, при этом модульная архитектура позволяющая расширять функционал устройства зачастую предполагает использование только одного решения, например только IPS или только антивирус. Если клиенту необходим больший функционал, то ему, как следствие, либо необходимо менять оборудование на более дорогостоящую модель, либо ставить второе, дополнительное устройство. При этом оборудование Check Point четко ориентировано на защиту информации и поэтому их блейдовая архитектура позволяет увеличивать функционал устройства (ибо сейчас я говорю исключительно об аппаратных платформах UTM и Power) без каких либо ограничений, позволяя включать тот или иной функционал, не задевая работу других сервисов, поэтому можно получить полностью “заряженное” устройство, которое помимо выполнения сервиса брандмауэра и построения VPN, будет служить IPS, антивирус и антиспам шлюзом, обладать богатым функционалом (которого попросту нет в арсенале Cisco) Web Security, обеспечивать URL фильтрацию и работу сетевого DLP на границе периметра. С другой стороны, такие стандартные вещи для Cisco как работа QoS, VoIP, кластеризация, advanced routing (хотя cisco asa, в отличии от решений Check Point не поддерживает BGP) в случае решение Check Point являются отдельными лезвиями и требуют отдельных денег.

Большим преимуществом Check Point является возможность централизованного менеджмента, и управления всем парком шлюзов и иных устройств из единой консоли управления. К тому же, в случае Check Point, администрирование правил фильтрации трафика гораздо проще и понятнее чем управление устройством cisco, где текстовое представление правил может занимать не одну сотню строк. Но в решениях Check Point, менеджмент- это отдельное решение, чья цена также не учитывается при сравнении оборудования этих производителей, тем более что управлять asa можно и из командной строки, в то время как со шлюзами Check Point такое действие не пройдет- для управления ими необходим менеджмент сервер в обязательном порядке, чаще всего он входит в бангл аппаратной платформы (везде кроме Power), но в случае большого количества узлов сервер управления также необходимо лицензировать по количеству управляемых шлюзов, а с новых версий и по числу нод входящих в кластер. Но как говорят цискари GUI менеджмент у cisco оставляет желать лучшего ибо java-решения всегда отличались своей особой и неповторимой неторопливостью в работе.

Далее возьмем характеристики по которым сравнивается оборудование Check Point и Cisco. Чаще всего отправными параметрами являются скорость фильтрации трафика, скорость VPN, число конкурирующих сессий, количество защищаемых пользователей, а для решений высшего эшелона и форм-фактор, ибо разница между 2U и 4U, даже в решении 4нодового кластера, уже весьма ощутима в пределах одной стойки. Секрет в том, что Cisco указывает в своих спецификациях параметры работы при рабочей нагрузке, в то время как Check Point указывает параметры работоспособности при так называемых дефолтных правилах, то есть все разрешено. Как только добавляется 20-30 правил, эта заявленная производительность падает на 20-30%. Тоже самое касается и работы IPS, малейшее усложнение дефолтной конфигурации приводит к потерям до трети заявленной скорости.

Теперь поговорим о стоимости обслуживания оборудования. Знатные цисководы, имеющие большой опыт работы говорят о том, что стать сертифицированным специалистом Cisco в разы сложнее чем специалистом по Check Point, как по количеству экзаменов (в cisco их 6 штук, в то время как в CP максимум 2), так и в смысле качественности экзаменов- на сертификации CP есть только теоретические вопросы, даже если и ситуационные, и не никаких лабораторных работ.

Согласуясь со всем вышесказанным я бы отметил следующие аспекты: не надо безусловно верить всем маркетинговым таблицам, ибо приводимые данные разнятся у различных компаний; следует четко понимать что именно вы хотите от решения- какой функционал и какие задачи оно должно обслуживать; естественно важна стоимость обслуживания. Сложно давать какие либо советы при выборе, но в случае единичного решения от которого требуется исключительно фильтрация трафика, я бы скорее всего остановил свой выбор на Cisco (а то и на бесплатных брандмауэрах под Unix системами , особенно если имеются инженеры этого вендора, которых по статистике гораздо больше чем сертифицированных специалистов Check Point. В случае же если необходимо сложное функциональное решение, или целый парк устройств, то выбор скорее всего тяготел бы в сторону Check Point именно благодаря облегченности менеджмента и более глубоким возможностям как управления, так и мониторинга и анализа проходящего сетевого трафика и происходящих инцидентов.

Рубрика: Check Point | Отзывов: 2 »

Рабочие моменты

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

Тут мне сваливается очередной запрос от нашего нового “недопродакт” менеджера по продуктам checkpoint- подобрать аналог решению cisco asa. Надо отметить, что такие запросы последние полгода сваливаются довольно часто, в связи с тем, что cisco решив работать вбелую, поимела огромные проблемы с доставкой оборудования в области инфобезопасности на 1/6 часть  суши, ибо наши доблестные фсбшники попросту не выдают им соответствующих сертификатов на оборудование. В этой связи кстати, также пропали все рутеры от LinkSyS, пару лет назад купленной Cisco- ведь wi-fi это же тоже адское шифрование и требует обязательной сертификации.

Вообщем приходит запрос на ASA 5505 8 портов, DES/AES и 10 пользователей. Ну я решив поднять себе настроение отписываюсь о том, что это в принципе SofaWare, но если исходить из того что нужен VPN, то вполне вероятно UTM 130, поскольку у него скорость VPN аналогична заявленной скорости ASA 5505- 100Мб/c. У Edge и Safe@Office этот параметр равен 35 Мб/c,и только у версии N заявлен под 200, но они отгружаются из Check Point в течении месяца-полутора. И тут я делаю стратегическую ошибку, решив пошутить в людьми не очень секущими в теме, и пишу что дескать есть конечно очень надо 8 портов, то следует остановить выбор на 2070, а это уже порядка 25к+ грина, против 600 долларов за ASA 5505, ну и сопровождаю это дело смайликом. С человеком который до этого был на этом месте, у нас это был стандартный способ общения, и я как то не предполагал что продавцам придет в голову отправлять клиенту предложение замены 600 долларового оборудования, оборудованием стоимостью в 25к зелени

Так что поимев двухдневную войну с нач.отдела по поводу того кто из нас троих в этой ситуации идиот, причем инженер из cp принял нейтралитет, заявив что 130 решение не подходит только по цене, а по функционалу полностью соответствует; видимо буду составлять матрицу аналогов между Checkpoint и Cisco, которую и выложу несколько позднее.

Рубрика: Check Point | Ваш отзыв »

Объединяем интерфейсы в CentOS

Разбираясь, накануне, с настройкой IP адреса в CentOS обнаружил интересную фичу по объединению нескольких интерфейсов в один виртуальный, тем самым повышая скорость передачи данных и создавая функционал отказоустойчивости, с помощью модуля ядра bonding.

Для этого необходимо создать bonding интерфейс, путем создания файла /etc/sysconfig/network-scripts/ifcfg-bond<N> , где N номер объединяемого интерфейса. Содержимое файла аналогично содержимому файла описания настроек обычно интерфейса, с той разницей что директива DEVICE= должна содержать поле bond<N>, где N номер интерфейса.

Пример файла выглядит следующим образом:
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

После того как файлы будут созданы, можно объединять интерфейсы путем добавления директив MASTER= и SLAVE=  , так что за исключением этих полей оба файла должны выглядеть идентично. Например для интерфейсов eth0 и eth1файлы конфигурации будут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Для того чтобы  слияние интерфейсов работало, необходимо чтобы модуль bonding был загружен в ядро, для чего необходимо проверить, чтобы в файле /etc/modules.conf присутствовала строка:
alias bond<N> bonding
где N номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

Рубрика: Linux | Ваш отзыв »

Ошибка VMware vSphere Client

Столкнулся с интересной темой в Windows Server 2003, при попытке подключиться к ESX серверу с помощью VMware vSphere Client. При вводе логина клиент выдает ошибку “Error parsing the server “SERVER IP” “clients.xml” file. Login will continue, contact your system administrator” и после нажатия на ОК вываливается во вторую ошибку “The type initializer for “VirtualInfrastructure.Utils.HttpWebRequestProxy” threw an exception”. То есть подключение к серверу недоступно.

Сначала было решили что это проблема с доступом, но просмотрев логи, убедились что мой клиент даже не стучится к серверу, так что стал копать в другую сторону и обнаружит что эту ошибку выдает Windows 7, при использовании стандартного клиента. В этой связи я всял совместимого с Windows 7 клиента VMware-viclient-all-4.0.0-208111 и обновил с его помощью имеющегося.

Ошибка исчезла, так что по видимому была вызвана каким то из последних обновлений для Windows систем.

Рубрика: Подсказки | Ваш отзыв »

Настройка IP в CentOS

Настраивал себе систему в VmWare Player, после чего перенесли её на ESX Server, ну и по пути возникла необходимость, из дома, сменить на системе IP адрес и повесить дополнительный алиас на интерфейс. Поскольку настраивал центосину до этого исключительно из окошек Х, пришлось немного поморщить голову, но после прочтения официального мануала, все оказалось проще некуда.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

Собственно как понятно из файла- IP адрес он цепляет от DHCP сервера, хотя мне казалось что я его задавал лапками, поэтому отрубаем DHCP и меняем настройки на:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

После перезагрузки машины или рестарта сетевых служб, с помощью команды service network restart , система переподхватит новый IP адрес.

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

Рубрика: Linux | Отзывов: 2 »