Доброго времени суток!

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

Перекопав полчища статей и опробовав множество вариантов, так и не нашел, что помогло бы с защитой. Взяв за основу статьи Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.

Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Доброго времени суток уважаемые читатели. Хочу представить вашему взору свой маленький плагин реализованный на jQuery. Плагин призван универсализировать создание всплывающих подсказок (tooltips).
Ранее я находил множество кодов для решения проблем с подсказками и ошибками при валидации, но все они были тяжеловесными и не очень универсальными. Это привело к тому, что я занялся разработкой своего плагина в обход существующим.
Главной задачей, было сделать так, чтобы выводом подсказок можно было управлять, но при этом не лезть в сам JS код.
Второй задачей было впихнуть в код столько функционала, чтобы подсказки могли выводится как слева/справа/снизу/сверху, так и была прилеплена к курсору мыши.
Третей задачей (зачем вообще было реализовывать на JS) было центрирования подсказки, относительно наведенного объекта.

Хочу поделиться небольшой наработкой, которая упрощает администрирование веб-севера, работающего под управлением Debian-подобной операционной системы. Сразу оговорюсь, я далеко не гуру в этой области, просто в какой-то момент мне понадобилось поднять vsftpd, nginx, PHP-FPM и PostgreSQL. Ни для кого не секрет, что при добавлении виртуальных хостов, настройке пулов PHP-FPM и создании баз данных, приходится выполнять одни и те же действия. Удаление виртуальных хостов со всем, что с ними связано, а также создание резервных копий тоже весьма однообразны. Поэтому было бы неплохо обзавестись скриптами, которые автоматизируют все эти вещи.

Эксплойты представляют из себя особый вид вредоносного ПО, которое используется злоумышленниками для установки различных троянских программ или бэкдоров на компьютер пользователя. Такая операция установки с использованием эксплойтов осуществляется незаметно для пользователя, что дает злоумышленникам неоспоримые преимущества. Эксплойт пытается использовать уязвимость в том или ином компоненте ОС для проведения подобной операции.

Для пользователя наиболее опасным сценарием является использование злоумышленниками эксплойта, который позволяет удаленно установить код в ОС. В таком случае человеку достаточно посетить скомпрометированный веб-ресурс для заражения вредоносным кодом (drive-by). Если на вашем компьютере установлена уязвимая версия ПО: браузера или плагинов к нему, то вероятность того, что вы сможете заразиться вредоносным кодом очень высока.

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

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Как всё начиналось

Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.

Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.

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

Здесь сразу обозначилась новая проблема: как защитить исходные коды нашей Python-библиотеки? Может быть, в ином случае никто бы не стал этим заниматься, я бы уж точно, но в библиотеке были реализованы некоторые ноу-хау, и руководители проекта не хотели, чтобы данные наработки попали к конкурентам. Так как я был одним из исполнителей, мне пришлось озаботиться данной проблемой. Далее я постараюсь рассказать об основной идее, что из этого вышло, и как нам удалось скрыть Python-исходники от лишних глаз.

Продолжение перевода статьи «Проблемы CSS. Часть 1».

Когда использовать width / height равный 100%?

Height: 100%

Пожалуй, начнем с того, что попроще. Когда использовать height: 100%? На самом же деле, вопрос часто звучит немного по-другому: «Как мне сделать так, чтобы моя страница заняла всю высоту экрана?». Ведь правда?

Для ответа на него нужно понять, что height: 100% равен высоте родительского элемента. Это не магическое «высота всего окна». Так что, если вы захотите, чтобы ваш элемент занял все 100% от высоты окна, то установить height: 100% будет недостаточно.

Почему? А потому, что родителем вашего контейнера является элемент body, а у него свойство height установлено в auto по умолчанию; а значит — его высота равна высоте контента. Конечно, вы можете попробовать добавить height: 100% к body, но этого тоже будет недостаточно.

Почему? А все потому же, родителем элемента body является элемент html, у которого также свойство height равно auto и он также растягивается под размер контента. А вот теперь, если добавить height: 100% и к элементу html, то все заработает.

Стало понятнее? Корневой элемент html на самом деле не самый верхней уровень на странице — им является «viewport». Для простоты, будем считать, что это окно браузера. Так вот, если установить height: 100% элементу html, то это то же самое, что сказать — стань такой же высоты, как окно браузера.

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

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

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

Сайт моего друга недавно был взломан, на нем была запущена старая версия IP.Board, в которой есть уязвимость локального внедрения кода (local file inclusion). Этот пост не будет посвящен IP.Board или другому php коду, он покажет, как найти потенциально вредоносный php код на ваших серверах. Наконец, покажу пример того, что злоумышленники могут загрузить на взломанный сайт.

Проверьте логи доступа

Что бы с чего-то начать, я бы хотел поделиться некоторыми записями из журнала доступа (access log) взломанного сайта моего друга.

IpreMOVED - - [01/Mar/2013:06:16:48 -0600] "POST /uploads/monthly_10_2012/view.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"
IpreMOVED - - [01/Mar/2013:06:12:58 -0600] "POST /public/style_images/master/profile/blog.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"

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

Два файла выше это загруженные взломщиком скрипты, как они туда попали, большой роли не играет, так как код на любых двух серверах, вероятно, будет различным. Тем не менее, в данном конкретном примере, уязвимость в устаревшей версии IP.Board была использована, и атакующие смогли добавить свои собственные скрипты в директории доступные для записи, такие как пользовательский каталог загрузки и каталог, в котором IP.Board хранит кэшированные изображения темы оформления. Это общий вектор атаки, много людей изменяют права на эти каталоги на 777 или дают им доступ на запись, подробнее об этом чуть позже.

Рассмотрим подробнее приведенные выше строки журнала, ничего не цепляет вас?

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

Здравствуй Хабр!

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

Каково же было мое разочарование, когда я приобрел телефон из поднебесной, где заводскими настройками было запрещено использование Google, Skype, Facebook и других приложений. В принципе, на некоторые вещи можно было закрыть глаза, но когда мой телефон не подразумевал использование учетной записи Google — я взял с себя обещания обязательно разобраться во что бы мне это не стало.

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

В данной серии статей пойдет речь о том, как делать reverse программирование для Android, реализовывать патчи, твики и моды.

В данном материале описывается процесс миграции свежеустановленного гипервизора Proxmox 3.0 в программный RAID1. Разработчики Proxmox в своей wiki пишут о том, что данное решение официально не поддерживается и не рекомендуется к использованию. Взамен этого предлагается использовать решения на протестированных аппаратных raid-контроллерах. Тем не менее в сети можно найти несколько мануалов по этой теме и практики успешной эксплуатации softraid'а совместно с Proxmox'ом. К сожалению, большинство этих мануалов нельзя назвать пошаговыми руководствами к действию: все они содержат те или иные ошибки, которые мешают достигнуть требуемого результата. Взяв за основу один из таких мануалов, я попытался исправить эту ситуацию. Приведённое ниже решение несколько раз было по шагам протестировано сначала в виртуалке, а затем использовано для миграции данных на реальном железе. В результате этого получился рабочий how-to, который предлагается вашему вниманию.

Настраивал кеширование на связке nginx+apache на сервере под управлением Ubuntu. Хотел бы поделиться с некоторыми нюансами с которорими я столкнулся в процесе работы. А имеено с проблемой отображения ssi интсрукций для nginx и разделением кеша с учетом языковой куки.

Проблемы с отображением SSI при использовании прокси на nginx

Для отображения динамических блоков решил использовать ssi. На локальной машине все работало отлично, но после выкладки на сервер ssi блоки не обрабатывались.
В качастве проксирующего веб-сервера используеться апач. После ряда экспериментов установил, что при использовании fastcgi блоки ssi обрабатывались отлично. То есть проблема в прокси-серевере apache.

В этой небольшой заметки хочу коснуться некоторых интересных моментов и особенностей управления трафиком (или попыток управления трафиком) в случае использования протокола BGP. Статья не даст ответ на вопрос о том, как сделать счастье в сети!

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

Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования

Вводные данные

При наличии двух собственных подсетей /24, столкнулся с необходимостью стандартной работы BGP, и погуглив, обнаружил минимальное количество информации по этой теме. На просторах рунета, в основном рассматриваются случаи, когда имеется одна сетка /24, и 2 провайдера, один из которых используется, как резервный. Да даже и этот случай рассмотрен некорректно, либо разрознено, нормально встретил описания только на англоязычных ресурсах.

Сразу же оговорюсь — рассматриваемые фичи CiscoOS: EXIST-MAP и NON-EXIST-MAP не поддерживаются UNIX-аналогами (типа Quagga).

В данной статье я рассмотрю два примера конфигов, исходя из следующих данных.

1. У нас есть два канала: основной рабочий и резервный. Оба провайдера анонсируют нам дефолт. Использование обоих каналов для нас нежелательно. Мы, в свою очередь, будем анонсировать им свои подсети, но если жив основной канал — анонс наших префиксов в резервный канал мы принудительно запретим, и будем анонсировать, только в случае падения рабочего канала
2. У нас есть два рабочих канала. И нам необходимо, чтобы через первый канал всегда работала (анонсировалась) наша первая подсеть, а через второй канал — наша вторая подсеть. Оба провайдера при этом анонсируют нам дефолты. В случае, если падает один из каналов — мы переносим анонс с этого канала, на оставшийся в живых. При возобновлении работы упавшего канала — возвращаем анонсы в начальный вид — по одной подсети через каждого провайдера

Теория:

Есть у меня своя домашняя сеть, с linux сервером, и подключена она к интернет с помощью беспроводного соединения — на крыше антена и роутер, к серверу подключено витой парой. Все вобщем то неплохо, канал с гарантированой полосой в обоих направлениях, постоянный IP адрес, довольно надежный — падает редко. Но вот есть у него один минус — цена кусается.
Ценовая политика провайдера построена так, что для того, чтоб увеличить скорость в два раза — платить тоже надо в два раза больше. А скорости хочется больше! И надежности тоже — как то во время сильных заморозков роутеру стало «холодно» и интернета вечером и ночью небыло.
Поэтому задумал я провести домой второй интернет-канал, выбар пал на одного известного на Украине провайдера, предоставляющего доступ по ADSL. У него и тарифы недорогие и модем ADSL стоит недорого. Так я и сделал, подключился, воткнул ADLS модем в свич — все работает. Но от старого доброго беспроводного канала отказываться мне нехотелось, поэтому задумал я сделать так, чтоб интернет трафик шел сразу по обеим каналам, так, чтоб я мог воспользоваться суммарной пропускной способностью. Да еще и чтоб при падении одного канала всю нагрузку на себя брал другой.

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

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

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

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

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

Лирическое вступление

Не люблю гонку версий, своей бессмысленностью отдаленно напоминающую гонку вооружений. Не успели как следует довести до ума текущую версию — выпускают новую, с новыми багами, уязвимостями и «особенностями». Для таких как я — любителей стабильных и проверенных решений для корпоративной среды, да и для себя тоже — у команды Мозилы есть сборка типа ESR: в течение длительного времени для нее выходят обновления, устраняющие ошибки и уязвимости, сама же major версия браузера не обновляется! Вот ссылка на страницу оф.сайта, откуда можно скачать эту замечательную ESR-версию (достигается путем не слишком очевидных ходов), также, ESR можно скачать с официального FTP ftp.mozilla.org/pub/firefox/releases/latest-esr/
Только что вышла давно мной ожидавшаяся 17-я ESR версия (предыдущая была только 10-я). В связи с этим событием решил написать подробное руководство по оптимизации нашего (не)любимого браузера — с разбором всех параметров, что каждый из них делает и откуда он получен.