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

Ограничение доступа ssh по IP в CentOS

Как говорится век живи – век учиcь. Оказалось, что CentOS’вский ssh не в курсе того, что на нормальных операционках ограничение подключений по IP осуществляется путем директивы  AllowHosts  в конфиге sshd_config. И посему эти ограничения следует прописывать в двух файлах:
/etc/hosts.allow
/etc/hosts.deny

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

(more…)

Рубрика: IT безопасность, Linux | Ваш отзыв »

Переменные окружения в CentOS

Стал добавлять юзверя в CentOS, ну и что то не могу понять отчего не работает useradd. Не видит его система. А не работает оно потому, что ifconfig я почему то на автомате пишу как /sbin/ifconfig , а вот добавлялку пользователей нет. Иначе бы заметил еще на стадии настройки сети, что не добавлены переменные окружения  /sbin  /user/sbin и /usr/local/sbin

Для чего открываем файло в корне юзверя ~/.bash_profile и допрописываем в переменные PATH указанные, а также все нужные нам окружения.

Теоретически указанные файлы (.bash_profile) отвечают за конкретного пользователя, то есть если мы пропишем их только Васе и руту, то видеть эти пути будут вася и рут, а все остальные пойдут лесом. Тогда как для всех остальных пользователей системы, если мы по доброте душевной хотим позаботиться и о них, нам следует прописать переменные окружения в файле  /etc/profile, где собственно и пропсаны в том числе вышеуказанные пути

pathmunge /sbin
pathmunge /usr/sbin
pathmunge /usr/local/sbin

НО, учитывая что в 99% случаев работать мы будем через ssh, данный вариант нам не подходит, ибо при старте ssh запускается интерактивный шелл, который игнорит переменные описанные в файле /etc/profile и поэтому отрабатываются только переменные домашней директории пользователя ~/.bash_profile

Рубрика: Дела Одминские | Ваш отзыв »

Установка сервера баз данных mySQL на CentOS

Собрат по цеху озадачил вопросом относительно того, что прикупил у Hostgatora минимальный и самый дешевый VPS по цене всего в 16$ за 384Mb памяти на борту и естественно unmanаged, причем из управления там стоит только Parallels Virtuozzo позволяющая доставлять сервисы и управлять ими, а также лазить по ssh через бродилку и рулить фаерволом. Но вот поставить мускуль у него получилось не очень здорово, так что был вынужден расписывать в аську последовательность действий, как и что делать что установить сервер mysql под CentOS.

Собственно там ничего сложного, особенно если стоит линуксовый установщик yum. Если его естественно нет, то делаем все по старинке:
$ mkdir /usr/local/yum
$ cd /usr/local/yum
$ wget http://linux.duke.edu/projects/yum/download/2.0/yum-2.0.7.tar.gz
$ tar xvzf yum-2.0.7.tar.gz
$ cd yum-2.0.7
$ ./configure
$ make && make install
после чего продолжаем будто yum у нас уже стоял:
$ yum install mysql
$ yum install mysql-server
$ yum install mysql-devel
$ chgrp -R mysql /var/lib/mysql
$ chmod -R 770 /var/lib/mysql
$ service mysqld start
После этого загоняем мускуль в автозагрузку:
$ chkconfig mysqld on && service mysqld restart && chkconfig –list | grep mysqld
После этого задаем пароль для рутового пользователя сервера баз данных:
/usr/bin/mysqladmin -u root password ‘Password’
Затем переходим к созданию необходимой базы данных и пользователя:
$  mysql -u root -p
mysql> CREATE DATABASE ИмяБазы;
mysql> USE  ИмяБазы;
mysql> GRANT ALL PRIVILEGES ON *.* TO Юзер@localhost  IDENTIFIED BY ‘ПАРОЛЬ’ WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> \q

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

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

Проброс X-соединения через SSH

Как я описывал в предыдущих терзаниях по поводу настройки X-соединения с Windows машины к CentOS серверу, Xdmcp не является безопасным, в связи с чем его использование довольно ограничено использованием в открытых сетях, в связи с чем приходится изыскивать другие пути общения со своим удаленным сервером через X-соединение.
Но  X-терминальное соединение, можно инкапсулировать в протокол ssl, путем проброса соединения к клиентской части X-терминала, через протокол сеансового уровня SSH. Для этого ранее использовалась бесплатная программа putty, позволяющая устанавливать ssh соединение с удаленными машинами, а ноне данный клиент включен в поставку Xming сервера. Для чего при установке севера Xming на нашей клиентской Windows машине, в разделе выбора компонентов, выберем пункт Normal Putty Link SSH client. После установки произведем настройку нашего Unix-сервера под управление CentOS:

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

После этого запускаем сервер Xming на стороне виндовой машины и настраиваем подключение, запустив программу XLaunch:
Multiple Window -> Start a program -> в Run Remote выбираем Using PuTTY и прописываем логин информацию к CentOS серверу через SSH  -> Additional parametrs можем оставить пустыми, либо прописать свойства терминала Х и ssh соединения ->  Готово

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

# xeyes &
или
# blackjack &

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

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

В процессе настройки в какой то момент в логах появилось неприятное сообщение о том, что пакеты дропаются стороной CentOS сервера, что вылечилось добавлением в файл X-сервера Xming виндусовой машины C:\Program Files\Xming\X0.hosts строчки, содержащей IP адрес нашего CentOS сервера. Но это скорее исключение из правил, ибо все работает и без этого.

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

VMware bridged mode vs kerio vpn client

Забавная тут ситуевина приключилась с одним сервисом, который я настраивал для клиента. Поднимал Help Desk- первоначально на своей машине в виртуальном окружении VMware Workstation, после чего установил на клиентскую машину VMware Player и перенес машину. Надо отметить что виртуальная машина крутится под Cent OS, а сервер под Win 2003, так что никаких особых проблем не ожидалось.

Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант-  поднимался внутренний IP и все начинало нормально шуршать.

В итоге обратился к админу с описанием проблемы и предположением о том, что какая то тулза препятствует нормальному прохождению пакетов, выступая видимо фаерволом. Поковырявшись, админ сказал что обнаружил что на серваке зачем то был установлен, тысячу лет назад, kerio vpn client, который он благополучно снес. После данной манипуляции все зашуршало прекрасно, так что причина крылась именно в kerio vpn client который видимо как любой ipsec клиент имеет встроенный фаервол у которого имеются свои взгляды на прохождение пакетов. У клиента от checkpoint, например, таких проблем замечено не было.

Рубрика: IT безопасность, Сети | Ваш отзыв »

Пространные рассуждения про VoIP трафик

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

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.

Погуглив, почитав и пообщавшись по форумам с людьми, выявил для себя следующие моменты:
под платформу лучше всего использовать отдельный сервер, поскольку на виртуалке могут возникнуть траблы как с трафом, так и с производительными мощностями, особенно в случае если трафик от провайдера приходит в одном кодеке, а в офисе мы используем другой;
для дедика вполне хватит сore2 или core i3, как минимум с 2Гб оперативы на борту, так что на первое время вполне сгодится какой нить десктоп, если руководство жмет деньги на приобретение полноценного сервера;
использовать лучше кодек g711, при этом под каждый активный разговор отводится порядка 64 кбит/с, так что умножаем на это число количество входящих линий и получаем необходимую под VoIP полосу пропускания;
использовать можно FreeBSD или CentOS, хотя тут мнения разделяются, как собственно и в любой холиваре- единственное что я пока осознал, что обновления для платформы Asterisc выходят на Cent OS с большим опозданием, по сравнению с фрей;
для сервака лучше использовать внешний, отдельный IP, поскольку при пробросе SIP портов (5060 udp/tcp и выделенный upd диапазон для траффа) через NAT могут возникнуть проблемы (в моем случае точно, поскольку на D-Link’e эти проблемы возникли даже при пробросе rdp);
можно использовать аналоговые телефоны, но для них придется докупать либо специальную карту в сервер, чья стоимость составляет около 2к грина, либо же VoIP шлюз, который также стоит в районе 200 грин;
цены на IP-телефоны начинают от 4к за более менее нормальные аппараты, так что имеет резон использовать бесплатные софтовые клиенты, так как в этом случае контора попадает только на гарнитуры, чья стоимость составляет от 700 рублей за штуку;
если планируется иметь факс, то его лучше вешать на аналоговую линию, поскольку для передачи факсимильных сообщений требуется идеализированный траффик, в противном случае факсы будут приходить крайне отстойного качества;
сама платформа Asterisc метит траффик, так что использовать для него приоритезацию траффика QoS не составляет проблемы;
некоторые провайдеры имеют свойство зафильтровывать SIP траффик, чтобы потенциальные клиенты не пользовались сторонними сервисами, так что придется либо брать данный вид трафа у этого провайдера, либо же каким то образом договариваться с ним;
в этом же ключе я пробивал возможность использования VoIP со шлюзом Checkpoint, который я уже успел несколько подзабыть за прошедшие полгода, в связи с чем выяснилось несколько моментов: в стандартной поставке Checkpoint FW будет корректно обрабатывать и пропускать VoIP траффик, и даже фильтровать его по политикам безопасности (при заведении объекта шлюза VoIP), а также симафорить с помощью IPS блейда, имеющего стандартными несколько сигнатур для проверки VoIP траффика. Но есть хочется чего то большего, то необходимо приобретать блейд  Voice over IP (VoIP) Software Blade, который этих сигнатур имеет большее количество и к тому же может не только проверять VoIP траффик, но и при необходимости вносить изменения в пакеты: транслировать адреса или вносить исправления в заголовки. Единственный момент здесь в том, что данный блейд встает только на версию R65, то есть весьма и весьма древнюю, так как на новых версиях SPLAT данный блейд не работает.

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

Рубрика: Check Point, FreeBSD, Linux, Дела Одминские | Ваш отзыв »

Удаленное X-подключение к серверу CentOS

Возникла некая необходимость управлять сервером шуршащим под CentOS, из винюка, причем не абы как, а через X-терминал. Поковырявшись, решили делать через Xming- бесплатный продукт, который можно скачать в инете в версии 6.9.0.31, на данный момент. За версию 7.5 дяди хочут бабла в размере 10 евриков, так что нам этот вариант не катит.

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

Схема работы простая: есть юниксовый сервер UNIX-Server под управлением CentOS на котором крутится X-клиент/сервер; есть виндовая машинка Win-XP на которой поднимается X-сервер Xming с помощью которого мы подключаемся к клиентской части UNIX-Server и по идее должны получить картинку с X-терминалом на рабочем столе виндовой машины.

Для начала скачиваем и устанавливаем на нашу Win-XP рабочую станцию X-сервер  Xming, откуда нить с инетовского зеркала, благо их предостаточно разбросано по инету. После установки пробуем настроить работу через Xdmcp.  Это специфический незашифрованный протокол, используемый для аутентификации и подключения Х-сервера к Х-клиенту.  Поскольку он не является закрытым, то его не рекомендуется использовать в открытых сетях, но это ограничение убирается при использовании сторонних средств шифрования. Ибо это наше первое знакомство, то не будем запариваться на безопасность и попробуем хотя бы запустить данный сервис.

Для этого на UNIX-Server открываем файло  /usr/share/config/kdm/kdmrc и в разделе [Xdmcp] проверяем, чтобы активность равенства Enable=true
После этого добавляем в файлы следующие поля:

/etc/gdm/custom.conf
[xdmcp]
Enable=true

/etc/X11/fs/config
# no-listen = tcp

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

Перегружаем Х-сервер
# /etc/rc.d/init.d/xfs restart
после чего переходим к настройке виндового сервера. Запускаем приложение XLaunch, в котором выбираем
One Window -> Open session via XDMCP -> в Connect to host прописываем IP адрес UNIX-Server и ставим галку Use indirect connect (народ пишет, что её надо снять но в нашем случае заработало только с ней) -> можем оставить пустыми, либо прописать свойства терминала Х, например в Remote font server наш IP UNIX-Server, а в Additional parametrs for Xming строку инициализации десктопа без кавычек “-screen 0 800×600″ ->  Готово

Если все настроили правильно, то на выходе получаем консоль с приглашением нашего X-терминала.

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