Задача — на минимальных ресурсах VPS развернуть хостинг нескольких не нагруженных сайтов. Сделать это быстро и удобно с минимальными проблемами в будущем и не падать на пиковых нагрузках.

Основные принципы:

1. ОС — Centos-6 86_x64 потому что стабильно, удобно и легко обновляемо.
2. Никакого самосборного софта. А то как говорится «командой make && make install любой дистрибутив превращается в Slackware.»

Будучи тестировщиками сетевого оборудования и любителями техники Apple мы никак не могли остаться равнодушными к появлению консольного кабеля для устройств iPhone/iPad/iPod Touch. Вот ссылка для тех, кто пропустил новость.

Введение

Вкратце, что это за кабель и для чего он необходим. Данный кабель позволяет использовать устройства Apple для получения доступа к консоли различных сетевых устройств, например, таких как, маршрутизаторы, коммутаторы, мультиплексоры и модемы. Тут стоит оговорить, что речь идёт не о “домашних” устройствах, а о профессиональном сетевом оборудовании, которое используется в операторах связи, корпоративных сетях, дата-центрах. Производителями таких устройств являются как международные вендоры (Juniper, Cisco, Zyxel), так и отечественные (Натекс).

Для чего необходим доступ к устройству через консоль? Основное — это первоначальная настройка устройства (настройка IP-параметров, логинов и паролей) и восстановление доступа к устройству в случае какой-либо аварии (утерян/забыт пароль, устройство не доступно по IP, восстановление ПО).

Многие слышали и пользовались замечательной утилитой nmap. Ее любят и системные администраторы, и взломщики. Даже Голливуд знает про нее — в фильме «Матрица» при взломе используется nmap.

Предисловие

Частью моей работы является ежедневное монтирование контейнеров TrueCrypt на удаленном сервере.
Утренний порядок действий меня напрягал: включить ноутбук, подключиться к серверу, ввести многозначный пароль в TrueCrypt, отключиться от сервера, выключить ноутбук, собраться и ехать на работу.
Пришла мысль об использовании Asterisk, необходимо было это реализовать.

Лет пять-шесть назад, когда я ещё программировал преимущественно на PHP, я начал использовать библиотеку curl для парсинга сайтов. Мне нужен был инструмент, который позволял эмулировать сессию пользователя на сайте, отсылать заголовки обычного браузера, давать удобный способ отсылки POST-запросов. Сначала я пытался использовать напрямую curl-расширение, но его интерфейс оказался очень неудобным и я написал обёртку с более простым интерфейсом. Время шло, я пересел на python и столкнулся с таким же дубовым API curl-расширения. Пришлось переписать обёртку на python.

В данной статье я бы хотел поделиться опытом написания небольшого твиттер-бота на Python.

Вступление

На написание бота меня натолкнул известный многим «пичалька-бот» в Twitter, который автоматически шлет реплаи всем, кто упомянит слово «пичалька» в своем твите. Поскольку в тот момент я занимался активным изучением Python, было решено писать на нем.

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

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

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

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

Введение

ACL (Access Control List) — это набор текстовых выражений, которые что-то разрешают, либо что-то запрещают. Обычно ACL разрешает или запрещает IP-пакеты, но помимо всего прочего он может заглядывать внутрь IP-пакета, просматривать тип пакета, TCP и UDP порты. Также ACL существует для различных сетевых протоколов (IP, IPX, AppleTalk и так далее). В основном применение списков доступа рассматривают с точки зрения пакетной фильтрации, то есть пакетная фильтрация необходима в тех ситуациях, когда у вас стоит оборудование на границе Интернет и вашей частной сети и нужно отфильтровать ненужный трафик.

Как вы уже слышали Брайан Кребс недавно проводил аудит паролей, полученных после взлома antichat.ru (сама база была получена где-то год назад и уже не актуальна!). Честно говоря, не очень понимаю чем занимались его видеокарты 18 дней, победив только 44% паролей. Мне на довольно скромном железе удалось подобрать 77% паролей за 8 часов. Исходя из таких несколько пугающих цифр, особенно для сайта тематически связанного с информационной безопасностью, у меня есть несколько рекомендаций о том какие пароли никогда не следует использовать, дабы они не были подобраны за пару минут.

1. Комментировать изменения в конфигах — не нужно. На память вы не жалуетесь, amiright?
2. QoS — не нужен. Всегда проще купить канал, заведомо превышающий потребности компании.
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.
4. Устная договоренность с сетевиками ISP является полноценной разновидностью SLA.
5. Сертификация — незначима. Экзамены всегда можно сдать с помощью дампов.
6. Прямой доступ через serial к оборудованию — анахронизм. IP-интерфейс — удобнее.
7. С системой мониторинга должен работать соответствующий отдел. Сотрудники там опытные, разберутся, что к чему.
8. Во внутренних маршрутах никогда не будет более 15 хопов.
9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
10. Одного гигабитного линка будет достаточно для всех.
11. Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?
12. Какой смысл ставить 2 маршрутизатора в ядре, если загрузка одного менее 50%?

После покупки своего первого смартфона люди обычно замечают, что расходы на мобильную связь немного увеличиваются. Обычно это происходит за-за того, что «умный» телефон «ходит в Сеть» без ведома хозяина. Конечно, решить эту проблему просто — установить специальные утилиты для блокирования подключений к точкам доступа GPRS/HSDPA либо купить безлимитный тариф на доступ в Интернет и забыть. Столкнувшись с описанной ситуацией, я в первую очередь заинтересовался и тем, что телефон ищет в Сети и, самое главное, что передает в Сеть. Последнее особенно актуально в связи с недавними новостями.

В комментариях к статье «Тестирование антенн Wi-Fi для приема WiMax» мы с bepcyc и drunken обсуждали возможность добавления Wi-Fi и WiMax антенн к мобильному роутеру Yota Egg.
В этой статье я реализовал эту идею и получил от нее хороший профит.

Ab ovo usque ad mala

Те из нас, кто работает с кучей Linux-серверов, а сидеть приходится под Windows вынуждены пользоваться Putty — он всем хорош: бесплатен, поддерживает все что нужно, но есть одна проблема: когда настроенных соединений становиться слишком много — массовое изменение параметров высосет из вас все соки (также как например и установка ваших любимых параметров для новых соединений). На хабре 2.5 года назад была заметка на эту тему, но там по прежнему требуется много ручной работы.

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

Скрипт берем тут — лицензия MIT = делаем что хотим (для запуска нужен питон). По умолчанию скрипт меняет цвета чтобы (мне) лучше читалось (тёмно-синий делает чуть светлее, светло синий — также), увеличивает буфер прокрутки до 20к (чтобы уехавший текст не пропадал), устанавливает размер окна по-больше, включает разворачивание по Alt+Enter на весь экран, убирает предупреждение при закрытии и включает сжатие SSH трафика.

Само собой сюда втыкать можно любые параметры. При добавлении нового соединения я просто прокатываю этот скрипт и готово. Под катом — исходник текстом, можно не кликать ;-)

Толчок. За ним ещё один, сильнее. Вот и всё. Перед глазами проносились альпийские луга, и девушка в бежевом сарафане, игриво крутя в точёных ручках кружевной зонтик проносилась мимо тоже. Проносилась, не сбавляя скорости, несмотря на то, что я тянул к ней свои менее точенные, но крепкие ручонки, а также жестами и мимикой изображал, в меру сил своих, какой всесторонний кундюшок её может ожидать, раскинь она мне руки навстречу (ну или ещё что раскинь).
Но случилось что случилось, и лишь ловко выхваченный зонтик из её, кстати, не только точённых но и цепких рук, немного оттенял розовыми тонами последние секунды моего пробуждения и согревал разбитое сердце (без зонтика, закрывающего её шевелюру, девушка оказалась на поверку немного, мягко говоря, плешиватой). Открыв глаза я, как то не странно, увидел себя не посреди развалин Ниигаты, и сразу отринул сейсмическую природу толчков. Немного отлегло. Перестал кричать – «Покинуть корабль!». С укором взглянул на начальника отдела трясущего меня за плечо. Который, вместо извинений принёс мне весть, что нас с ним ожидают у директора, для постановки одного маленького, но очень ответственного задания. Не приняв его слова близко к сердцу, я несколько раз пытался вернуться к своей плешивой искусительнице, но начальник продолжал проявлять чудеса настойчивости. Пришлось идти.

Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.

Описание проблемы

Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.

Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.

Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.

В очередной раз запустив в Windows свой скрипт-информер для СамИздат-а и увидев в консоли «загадочные символы» я сказал себе: «Да уже сделай, наконец, себе нормальный кросс-платформенный логгинг!»

Об этом, и о том, как раскрасить вывод лога наподобие Django-вского в Win32 я попробую рассказать под хабра-катом _{(Всё ниженаписанное применимо к Python 2.x ветке)}

Добрый день.
Я решил написать этот пост по нескольким причинам:
1) Иногда легче дать ссылку на статью, чем в сто первый раз рассказывать человеку, что ему необходимо сделать, и где про все это можно почитать.
2) Появилась необходимость привести знания в систему. А лучше всего это делать, если рассказываешь это другому человеку.
3) Чисто корыстный интерес — хочу инвайт.

Итак. Постановка задачи.
Есть рабочее место (W), закрытое роутером. Есть домашний компьютер (H), с которого периодически необходимо получать доступ к рабочему столу W, и который не имеет «белого» IP.

Менять что-то в настройках роутера — нельзя. Использовать TeamViewer & Co. — не наш путь.

У начинающих cisco-водов много вопросов вызывают различные варианты линеек IOS их отличия и функционал. Дополнительную сумятицу внесло появление новых маршрутизаторов ISR G2 и новой линейки IOS версии 15. Попробуем разобраться на пальцах.

Будем обсуждать IOS для самых распространенных маршрутизаторов – Integrated Services Router (ISR) первой и второй «волны» (G1 и G2). Я не буду вдаваться совсем уж в историю и начну с IOS 12 версии. Более ранние, конечно, бывают, но встречаются сейчас крайне редко. Мало того, даже для самого древнего железа уже как правило хотя бы 12.0 версия есть.

Начиная с этой линейки у cisco появилось понятие «стабильный» или «основной» образ (main deployment, MD), «ранние версии» (early deployment, ED), всякие экспериментальные версии (обычно содержат несколько новых фич) и целая «продвинутая» технологическая линейка (обозначается буквой Т в названии IOS). Общая идеология такая: все, что обкатали в экспериментальных и технологических линейках предыдущих версий, появляется как основная фича в следующей версии основной линейки. Например, то, что было в 12.3Т и прошло успешные испытания, зафиксировано в 12.4 MD. Понятно, что возможностей у Т-линейки больше, функционал менее оттестирован и статистически менее надежен.

Disclaimer
Этот пост появился здесь по нескольким причинам:
1) Меня попросил сам Boomburum
2) Есть предположение, что на хабре всё-таки есть люди, имеющие прямое отношение к IT, но при этом имеющие весьма отдалённое представление о пользе SSH и её извлечении из обычного домашнего роутера, и которым, надеюсь, будет весьма интересно и полезно об этом узнать.

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:
А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.
Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.
Специально для GrammarNazi:
Пишите пожалуйста об ошибках в личку — обещаю исправиться.

Бла-бла-бла, а топик-то о чём?
Итак, я обещал рассказать «как поднять ssh-туннель домой без необходимости оставлять включённым домашний ПК» и, как правильно догадался peter23 речь пойдёт про ssh-сервер на роутере.