Один из клиентов жадно захотел 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 данный блейд не работает.
Пока эти размышления поставили мне мозги набекрень, так что ближайшие пару дней буду думать, куда мне копать дальше. Ну и да- главный аспект сколько за эти работы можно снять бабла- вот это для меня пока остается загадкой, так как сам не пойму во сколько можно оценить общий фимоз мозга, который я заработал за сегодняшний день, пока грыз всю эту инфу.
Собственно о системе Splunk я писал буквально в предыдущем посте, так что добавить ничего не могу, кроме того что это система управления инцидентами и событиями информационной безопасности. Ставить систему будем на FreeBSD 6.4, ибо она вся такая для меня приятная.
Итак поехали, ибо создатели пакета обещают что ставится она на раз-два-три:
# wget ‘http://www.splunk.com/index.php/download_track?file=4.1.4/freebsd/splunk-4.1.4-82143-FreeBSD-i386.tgz&ac=&wget=true&name=wget&typed=releases’
# tar -xzvf splunk-4.1.4-82143-FreeBSD-i386.tgz
Поскольку, как оказалось, пакет пришел нам в уже собранном виде, то оправляем его по месту постоянного жительства:
# cp -R splunk /usr/local/
Перед запуском системы необходимо внести изменения в конфигурационные файлы:
После этого перегружаем сервер для того чтобы изменения вступили в силу. При желании можем создать ручками пользователя от которого будет работать splunk, а также и его группу, но мне что то сегодня в ломы. Поэтому запускаем сервис: перед первым запуском сервера необходимо согласиться с лицензионным соглашением, для этого стартуем: # $SPLUNK_HOME/bin/splunk start –accept-license
После некоторого диалога, сервер сообщит, что он теперь запущен на http://our_server_hostname:8000 хотя зайти можно и по адресу http://our_server_IP:8000. В данном случае 8000 это дефолтный порт нашего веб сервера.
Теперь переходим к настройке сервера.
Логин и пароль по умолчанию для входа в web-консоль: username: admin
password: changeme
В верхнем правом углу белеет на темном фоне кнопочка Manager, нажав на которую мы попадаем в общирное меню, позволяющее нам настроить наш сервер в разделе System configurations, а также добавить необходимые модули Apps, собития, поиски и прочая в разделе Apps and knowledge.
В System settings задается хостнейм и настраиваются веб-морда сервера, а также параметры индексирования. Также настраивается отправка алертов по почте и всевозможные уровни логирования, которых доступно шесть вариантов: DEBUG, INFO, WARN, ERROR, CRIT, FATAL.
На сегодня хватит, на днях распишу больше- но по сути настройка системы заканчивается именно на этом разделе- дальше идет уже тюнинг, причем интерфейс интуитивно понятен и прост.
При использовании того или иного сервиса очень большую роль играет система на которой будет работать наш сервер. И наибольшее значение предварительная настройка этой системы, чтобы минимизировать риски от её использования. Для этого существуют процедуры повышения безопасности системы
В этом разборе полетов я буду осуществлять предварительную настройку системы FreeBSD 7.2. Сама система FreeBSD является одной из наиболее защищенных операционных систем, причем её код, не смотря на открытую идеологию open sourse многократно проверяется и тестируется. Не смотря на то, что с комплекте поставки FreeBSD уже идет с сильной безопасностью, существуют меры по её повышению почти до параноидального режима работы.
Утилита su2 является более защищенным аналогом команды su, служащей для перехвата прав другого пользователя, только в отличии от su, эта утилита дает возможность получать права суперпользователя пользователям не входящим в группу wheel, т.е. не имеющим права на возможность перехвата root с помощью su. Поэтому заводим пользователя с униками выше тысячи, так чтобы он выглядел не привилегированный пользователем. После этого устанавливаем утилиту: (more…)
Есть у меня отличный почтарь, да не один, а несколько. Все они крутятся в связке Exim + DBmail + MySQL, конечно там есть много чего еще, но это основная связка, и нас из неё интересует последняя составляющая mySQL. Дело в том, что база пользователей и всего имеющегося мусора крутится по мускулем и хостится в базе типо InnoDB, которую необходимо постоянно сжимать и сканировать. Желательно каждую ночь, чтобы мусор скопившийся за день, не забивал место в табличном пространстве.
К большому сожалению база InnoDB работает по принципу ниппеля, т.е. туда дуй, оттуда х… Объясняя это доступным языком- табличное пространство может как расширяться так и уменьшаться, но физический размер базы при этом изменяется только в сторону увеличения. Проще говоря если у вас база была на максимуме 20гигов, и после этого вы её почистив освободили 90% пространства, внутри база у вас будет свободна на 90% (посмотреть свободное пространство можно командой в консоли управления сервером: mysql> show table status; ), но снаружи она так и будет занимать на диске 20 Гиг физического пространства диска. Так вот у меня, на одном из серверов, она успела разрастись, пока я прочухал тот факт, что забыл установить чистящий скриптик, до 250 Гигов, которые конечно работают как часы, но самой цифрой действуют мне на нервы. В этой связи надо что то делать. Но делать можно только одним способом, а именно перегнать базу в дамп sql и затянуть его обратно, предварительно дропнув имеющегося монстра. В этой связи, ровно как и для дефрагментации табличного пространства, нашим лучшим другом является системная утилита mysqldump, входящая в стандартный комплект поставки сервера mySQL.
*** Для дефрагментации InnoDB также можно использовать способ двойной перегонки базы, с помощью команды ALTER преобразовать её в тип MyISAM, а затем обратно в тип InnoDB. (more…)
Что то скриптики cron по очистке баз данных почтовика перестали слать свои милые радостные отчетики о проделанной работе, пришлось озадачиться ковыряканием крона по новой.
Наиболее простой способ выяснился после разглядывания подробностей файла /etc/crontab
простая установка директивы MAILTO= в описании основных параметров отправит всю почту на указанный мейл, но в моем случа нужно давать эпизодического пендаля хозяину сервера, чтобы он следил за своей вотчиной, а я за своей, в этой связи обнаружилось два способа:
корявенький, с указанием директивы mailto в поле команды: 3 1 * * * root MAILTO=xxx@odminblog.ru /root/scripts/mailcleaner.sh
и на мой взгляд более корректный с перенаправлением вывода исполнения скрипта: 3 1 * * * root /root/scripts/mailcleaner.sh 2>&1 | mail -s “Mail base cleaning” xxx@odminblog.ru
, также можно перенаправить вывод выполнения скрипта в лог файл: 3 1 * * * root /root/scripts/mailcleaner.sh >> /var/log/cron.log 2>&1
Tcpdump чрезвычайно удобный сетевой анализатор, очень помогающий в работе как сетевым администраторам, так и безопасникам. Естественно что для получения максимальной информации при работе с tcpdump, просто необходимо иметь представления о стеке протоколов TCP/IP. Для удобства можно использовать более удобные и интеллектуальные программы, например , но часто возникают ситуации когда на тестируемую машину не представляется возможным установить дополнительные сервисы, и тогда tcpdump просто незаменим, не будит же админ, ради анализа пакетов, ставить на unix’овый сервак X-Windows тем более что в большинстве unix’овых систем, утилита tcpdump идет по умолчанию.
Понимание протокола TCP/IP дает широкое пространство для использование анализатора и устранения неисправностей и неполадок в работе сети, за счет разбора пакетов. Поскольку оптимальное использование данной утилиты требует хорошего понимания сетевых протоколов и их работы, то получается забавная ситуация, в которой инженеру в любом случае необходимо знать и понимать механизмы передачи данных в сети. т.ч. tcpdump полезна во все отношениях: как устранения неисправностей, так и самообразования. (more…)
базы, с помощью команды ALTER преобразовать её в тип MyISAM, а затем обратно в тип InnoDB.
тем более что в большинстве unix’овых систем, утилита tcpdump идет по умолчанию.
