С практической точки зрения было бы удобно управлять Wi-Fi сетями, выдавая пароль каждому пользователю. Это облегчает задачу с доступом к вашей беспроводной сети. Используя так называемую WPA2 PSK авторизацию, чтобы предотвратить доступ случайному пользователю, нужно менять ключ, а также заново проходить процесс авторизации на каждом отдельном Wi-Fi устройстве. Кроме того, если вы имеете несколько точек доступа, ключ нужно менять на всех из них. А если Вам надо скрыть пароль от кого-нибудь, придется раздать всем сотрудникам новый.

Представим ситуацию — к вам в офис зашел кто-то посторонний (клиент, контрагент?), и нужно дать ему доступ в интернет. Вместо того, чтобы давать ему WPA2 — ключ, можно сделать для него отдельный аккаунт, который потом, после его ухода, можно удалить заблокировать. Это даст вам гибкость в управлении учетками, а пользователи будут очень довольны.

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

Приветствую вас, Хабражители!

Сегодня хочу поделиться с вами одним из своих наработанных мануалов, который отточен многоразовым применением, про который с уверенностью могу сказать, что «точно работает!» без лишних танцев с бубном.
Ориентирована статья скорее на начинающих системных администраторов, чем на гуру (для них тут ничего нового нет :) ), и в ней я постараюсь раскрыть рабочий и довольно быстрый вариант развертывания сервера виртуальных машин, стараясь при этом охватись как можно больше нюансов и подводных камней.

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



Помните 7 шагов?

В настоящей статье я попробовал в максимально доступном и сжатом виде описать что такое IKEv2, FlexVPN и как это реализовано в IOS маршрутизаторов Cisco. Для наилучшего понимания содержания, нужно чтобы читателя, на момент ознакомленимя с нижеприведенным текстом, не пугали такие слова как VPN, IPSec, ISAKMP, ISAKMP Profile и т.д. Кроме того, желательно иметь хорошее представление о том, как настраиваются различные типы VPN с использованием VTI интерфейсов (или GRE over IPSec) на оборудовании Cisco, поскольку статья в значителной степени опирается на знание этих вопросов.

Предисловие

Сразу нужно акцентировать внимание, что не надо думать, что IKEv2 является чем-то совсем новым, сложным для понимания и полностью меняет всю концепцию построения VPN-сетей. IKE(как 1 так и 2) призваны лишь для того чтобы обеспечить ESP (ну или AH, если кому-то нужно) необходимой ключевой информацией, нужной указанным протоколам для непосредственной защиты данных. Сам же ESP, его режимы работы (tunnel/transport) и все связанные понятия не меняются.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

На днях с командой столкнулись с тем, что Bitbucket стал мал для нас, а нацеленность на подобие корпоративной безопасности, в любом случае, рано или поздно потребует переезд с приватных репозиториев, находящихся вне компании, на собственную инфраструктуру. После сёрфинга по интернету было решено остановиться на готовом решении SCM — manager по ряду причин

• Простота установки
• Простота администрирования через веб-интерфейс
• Поддержка GIT и SVN (немаловажно, поскольку используются оба)

ОС для установки: Debian7
Стоит заметить, до этого с подобным никто у нас не сталкивался и статья — это результат нескольких часов метаний по интернету и мануалам.
SCM ставился на Tomcat, поскольку на нём же крутится Redmine
Сама установка и настройка под катом:

Приветствую Хабр!

В данном небольшом how-to хотел бы поделиться с вами своим опытом использования утилиты lvmsync.

Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
Передавать мы будем весь раздел LVM, на который установлена виртуальная машина. Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.

Вот как выглядит перенос виртуальной машины в кратком виде:

1. Делаем снимок LVM раздела.
2. Передаем основной LVM раздел по сети, не останавливая нашу VM.
3. Когда закончится передача основного раздела, останавливаем VM.
4. Запускаем lvmsync для передачи снимка по сети. Передается не весь снимок, а только измененные блоки.
5. Подготавливаем и запускаем VM на новом сервере.

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

Подробнее о работе lvmsync, и дополнительных плюшках вы можете почитать на страничке проекта.

В прошлой части нашего исследования мы обещали опубликовать продолжение анализа инцидента заражений серверов под управлением Linux с участием бэкдора Linux/Cdorked.A. Мы уже писали, что специалистами нашей лаборатории была установлена его главная задача, которая заключается в перенаправлении пользователей веб-сервера на вредоносные веб-сайты. Расследуя более детально этот инцидент мы пришли к следующим выводам:

• Всего было выявлено более 400 веб-серверов, зараженных Linux/Cdorked.A. Кроме того, 50 из них осуществляют хостинг для веб-сайтов, которые входят в Alexa ТОП 100,000 самых популярных веб-сайтов.
• Бэкдор осуществлял компрометацию веб-серверов не только под управлением Apache, но и Lighttpd, а также nginx.
• По данным наших систем телеметрии, эта угроза была активна уже с декабря 2012 г.
• Бэкдор использует дополнительные механизмы для обеспечения своей скрытности. В частности, нами было установлено, что вредоносный код не будет осуществлять перенаправление пользователей, если IP-адрес клиента находится в диапазоне адресов, указанных в черном списке. Этот черный список является довольно большим и включает в себя адреса, принадлежащие таким странам как Япония, Финляндия, Россия, Украина, Казахстан и Белоруссия. Кроме этого, проверка страны также выполняется по анализу HTTP-заголовка и параметру Accept-Language.
• Наша облачная технология показывает почти 100,000 пользователей AV-продуктов ESET, которые перенаправлялись на ссылки, сгенерированные скомпрометированными веб-серверами. При этом такое перенаправление на вредоносное содержимое было заблокировано антивирусом.
• В некоторых случаях мы наблюдали специальные перенаправления для платформ Apple iPad и iPhone.

Предположим что у нас есть postgresql в режиме потоковой репликации. master-сервер и hot-standby готовый заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. Однако, возможны ситуации когда вполне законные изменения были сделаны криво написанной миграцией и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных все нормально, а с точки зрения бизнеса — катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная…
Для предостережения такой ситуации есть, как минимум, два варианта…

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

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

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

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

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

Введение

Добрый день!

В этой статье я хотел бы рассказать о типах областей OSPF. Статьи по настройке OSPF с использованием областей как-то здесь мне уже попадались. Я же хочу рассмотреть, чем эти типы областей отличаются друг от друга: normal, stub, totally stubby, NSSA, totally NSSA. Итак, начнем.

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

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

В общем виде схема выглядит так:
клиент ----> балансировщик ---> бэкенд (сервис)


Готовых балансировщиков под конкретные нужды множество. Например, nginx — отличный балансировщик для веб-приложений, haproxy для tcp-соединений.

К сожалению, ошибки бывают у всех. И «Антивирус Касперского» не миновал этой участи. У нас случаются «баги» в обновлениях, некоторые из которых доставляют пользователям неприятные хлопоты. Все подобные случаи мы тщательно расследуем, делаем выводы, и «подкручиваем» технологии тестирования.

А как вообще тестируются антивирусные обновления?

По вполне понятной причине в антивирусной индустрии технологические подробности тестирования обычно держатся за семью печатями. Попробуйте поискать в Интернете — сколько-нибудь полезной информации по этому поводу нет.
С другой стороны, тестирование обновлений — очень интересная тема, достойная внимания читателя. И нам здесь есть чем поделиться.
В конце 90-х «Лаборатория Касперского» была одной из первых в индустрии, кто автоматизировал процесс и уже около 15 лет постоянно развивает его.

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

Решила написать небольшой пост о автоматическом сохранение конфигурационных файлов cisco.

Зачем сохранять конфигурацию? Примеров много — может сгореть железка — ее вы можете поменять без проблем, а бэкапа конфигурационного файла нету — придется настраивать с нуля. Хорошо, если у вас хорошая память (и вы помните все настройки) или у вас все полностью описано система. Но что, если конфигурационный файл занимает тысячи строк?
Или к примеру один из сотрудников случайно почистит файл конфигурации или удалит. Возможно преднамеренно…
Можно хранить конфигурацию не во flash — а на внешнем носителе или удаленном сервере — но потерять конфигурацию можно и в этом случае. Бэкап конфигурации делать нужно обязательно — и на постоянной основе.

Я опишу, как можно автоматизировать данный процесс.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

Проблема в том, что измерить «скорость» виртуального жесткого диска изнутри виртуальной машины – непросто, т.к. неясно, что мерить в первую очередь, чем и зачем. А сделать это нужно, чтобы убедить администраторов виртуальной конфигурации, что дело не в приложении и настройках MySQL. И нужно было, как говориться, просто «помыть руки» перед чтением мануала к хранилищу.

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).