Архив категории ‘Без категории’

Когда мы все работали в Японской компании, то  каждый год отмечали ее день рождения летом в июле. Компания уже как 3 года уехала на Филиппины, а мы все еще верны традиции, устраивать летом выезд на природу, отмечать день рождения Вэльюкоммерс. На самом деле, был бы повод!

И в это лето мы решили не изменять традиций!

Изначально отдых  планировался  культурный, с бассейнами, футбольными площадками, сауной… Но  в результате поехали  мы на берег Москвы реки под Звенигород!

Что мы там делали? Да все делали! Купались, кормили комаров, ели шашлыки(ударение на втором слоге), варили плов(ну мы его потребляли в основном), играли в бадминтон. Вечером снимали стресс, глядя на огонь.. это сейчас так называется.  Играли мы в Контакт. В нашей компании из этого получается очень  высокоинтеллектуальная игра! Я в очередной раз почувствовала себя блондинкой и порадовалась, с какими умными людьми я работаю.

Ну а на следующий день – пошли по Святым местам! Савву Сторожевского посетили. Кстати, говорят,  что он в бизнесе помогает. Говорят, у кого какие проблемы – сразу к нему! Чтобы мы выгледели прилично, нам выдали юбки…даже мальчикам выдали. Не могу сказать, что выглядеть мы стали приличнее….но решили не лезть со своим уставом в чужой монастырь. Наверное Богу тоже иногда хочется посмеяться.

В общем, отдохнули хорошо, потом от отдыха еще долго отдыхали!

В Москве на Ходынке рабочие повредили кабель спецсвязи, из-за того, что он не был указан в документации в связи с высокой секретностью (http://lenta.ru/news/2010/08/16/liason/). Этот случай – очень хорошая иллюстрация опасности подхода «Security through obscurity» (безопасность путем сокрытия). Система, построенная на этом принципе может содержать уязвимости, но, разработчики или владельцы системы считают, что о них никто не узнает. Но на самом деле, об уязвимостях узнают, и в первую очередь отнюдь не разработчики этой системы.

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

Если хозяин квартиры хранит ключ от входной двери под дверным ковриком, он полагается на принцип Security through obscurity. Достаточно увидеть, как он достает ключ из под коврика, чтобы дверь оказалась полностью скомпрометированой. Не говоря уже о том, что потенциальный злоумышленник первым делом посмотрит под ковриком. Данный пример весьма очевиден, но более сложные случаи с точки зрения безопасности отличаются мало.

Алгоритм шифрования A5/1 (http://en.wikipedia.org/wiki/A5/1), применяемый в GSM сетях, изначально держался в секрете, однако в 1994 году некоторые детали реализации алгоритма утекли в широкие массы, а в 1999 году он был полностью раскрыт реверс-инженирингом телефонного аппарата. Алгоритм оказался настолько некриптоустойчив, что на данный момент GSM передачи можно перехватывать при помощи оборудования за $1500 (http://www.securitylab.ru/news/396052.php).

Компания Cisco Systems скрывала детали реализации своих протоколов маршрутизации, пока в мае 2004 года не были украдены исходные коды операционной системы, которая работает на их маршрутизаторах. В результате анализа кода было выявлено множество уязвимостей в протоколе EIGRP, что подвергло риску множество владельцов оборудования Cisco. (http://www.securitylab.ru/vulnerability/source/243482.php)

Случается люди кладут свою секретную информацию на веб-сервер, не защищая ее паролем и беспечно полагая, что об этом сервере никто не узнает, если они о нем никому не скажут (не будут создавать DNS имя, создатут секретную папку с секретным именем, поднимут веб-сервер на нестандартном порте и проч.). Сетевые сканеры (cheops-ng, firewalk, nmap) довольно быстро находят такие заначки, и их секретная информация быстро становится достоянием общественности. Аналогично, «секретные» URL оседают в истории броузеров, оказываются в HTTP referer, и, довольно быстро, Google и другие поисковые машины их индексируют.

Открытость системы, как правило увеличивает уровень ее безопасности. Согласно Эрик Реймонд сформулировал «закон Линуса», который гласит «при достаточном количестве глаз баги выплывают на поверхность» (given enough eyeballs, all bugs are shallow). Если система открыта, довольно много экспертов захотят на нее посмотреть и если в ней есть уязвимости, об этом будет известно довольно быстро, как правило до того, как ей будут пользоваться миллионы клиентов.

Добавляем jQuery в Grails

Собственно никаких проблем с AJAX в Grails не наблюдается: контроллеры могут спокойно возвращать JSON-данные, GSP-страницы могут использовать соответствующие вспомогательные тэги.

По умолчанию Grails дружит с Prototype JS. Однако можно легким движением руки установить плагин поддержки jQuery. (далее…)

Написание удобной и культурной программной обёртки для работы с транзакциями является любимым занятием многих. Транзакции надо уметь корректно начинать, заканчивать, откатывать, причем они ещё могут быть и вложенными. Python — язык многогранный (или, как говорят слабые духом, «мультипарадигмальный»), поэтому способов сделать такую обёртку на нём — несть числа. (далее…)

Недавно меня попросили сравнить провести тесты шаблонизатора для используемого нами фреймворка Grails. Зачем такие тесты нужны и что они, собственно, скажут о производительности приложения — не знаю. Однако это весело и народ такие тесты очень любит.

Собственно, у Grails никакого шаблонизатора нет, а есть язык Groovy, который можно использовать внутри серверных страничек (GSP — Groovy Server Pages). Итак, хотим измерить производительность языка Groovy. В качестве базовой точки отсчета используется язык PHP.

(далее…)

В процессе борьбы со спамом порой страдают невиновные. Системному администратору, который поставил свой SMTP сервер полезно помнить о вещах, которые помогут убедить других администраторов в том, что он рассылает не спам, а вполне легитимные письма.
(далее…)

Продолжая неустанно трудиться на благо безопасности и удобства администрирования, мы дошли до мысли о том, что sudo — вещь удобная, но небезопасная. Или наоборот, безопасная, но неудобная. Смотря, что написано в sudoers.
(далее…)

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

На одном из наших проектов мы отдаем большое количество видео контента. Наши сервера отдают около 8 ГБит/сек, среди этого html/css/js контент занимает около 300-400 Мбит.

(далее…)

Продолжение первой части.

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

(далее…)

На одном из наших проектов нам перестало хватать производительности дисковой подсистемы на сервере БД. Одним из решений было начать использовать дисковый массив с большим количеством шпинделей, но звучали аргументы против. Во-первых, дисковый массив + HBA (external SATA у сервера нет) стоит как 2 новых сервера. Во-вторых, дисковый массив занимает как минимум 2U. В-третьих, дисковый массив предоставит терабайты, которые, строго говоря, не нужны (размер БД + временные таблицы укладываются в 40 гигабайт максимум).

Поэтому мы подумали, почему бы не попробовать SSD. И взяли 4 Intel X25-E по 32Gb каждый. Объеденили их в 2 массива RAID0 (из-за специфики проекта мы готовы мириться с потерей данных при выходе из строя одного из устройств) и посмотрели что получилось.

Получилось следующее:

(далее…)