Распространённые ошибки веб-мастеров при борьбе со взломом и заражением сайтов

Revizium_1

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

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

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

Условно все ошибки веб-мастеров можно разделить на три большие группы: до начала лечения, во время лечения и после него. Что ж, начнем по порядку.

Предупреждён, но не вооружен

Сайт, над которым потрудился хакер, какое-то время может себя никак не выдавать. Часто веб-ресурсы заражаются в несколько этапов. На первом этапе хакер находит уязвимость на сайте и незаметно загружает на него шелл. Он даже может аккуратно «заштопать» после себя брешь, чтобы не отдавать кусок пирога коллегам по цеху. Если регулярно не проверять сайт сканером вредоносного кода, например AI-BOLIT, который определяет хакерские шеллы и бэкдоры, то можно упустить возможность своевременной безболезненной ликвидации незваного гостя на сайте.

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

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

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

В нашей практике были случаи, когда подобное игнорирование ситуации заканчивалось шантажом со стороны злоумышленника – хакер, получивший административный доступ к веб-ресурсу, вымогал деньги, угрожая уничтожить веб-проект полностью, и наша команда подключались уже в «пожарном» режиме для срочного решения проблемы.

Есть подозрение на вредоносную активность – не поленитесь проверить сайт на предмет взлома и заражения.

Некорректная работа со сканером вредоносного кода

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

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

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

Обман поисковых систем

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

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

Запрещение индексации – опасный шаг. Во-первых, это может привести к выпадению страниц сайта из поискового индекса, а, во-вторых, правила, которые распространяются на поисковые механизмы, не работают для роботов антивирусных сервисов.

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

Лечение сайта с помощью антивируса для компьютера

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

Для проверки сайта необходимо использовать специализированные сканеры вредонсоного кода, база данных которых регулярно пополняется новыми экземплярами вредоносных элементов.

Восстановление сайта из бэкапа вместо лечения

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

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

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

Удаление вредоносного кода без закрытия уязвимостей и установки на сайт защиты

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

Дело даже не в том, что веб-мастер нецелесообразно тратит свое время, «вычерпывая воду из дырявой лодки» (как правило, владелец сайта удаляет код вручную, тогда как хакер подсаживает вредоноса в автоматическом режиме) – сайт находится под угрозой, он марионетка в руках хакера.

Главная задача в сложившейся ситуации – не просто избавиться от вируса на сайте, но предпринять необходимые действия по ликвидации уязвимостей в плагинах и скриптах. В 80 случаях из 100 повторное заражение происходит в результате эксплуатации хакером все тех же брешей.

Практические рекомендации

Закрытие уязвимостей

Наиболее популярные типы уязвимости/атак, приводящих ко взлому сайта, можно разделить на следующие типы (полная классификация уязвимостей доступна на сайте OWASP TOP 10):

  • RCE (Remote Code Exection) – удаленное исполнение вредоносного кода;
  • AFU (Arbitrary File Upload), которые позволяют загружать файлы на хостинг, эти файлы могут быть исполняемыми скриптами;
  • SQL-инъекции, с помощью которых выполняются манипуляции с базой данных (добавление нового администратора сайта, извлечение паролей, вставка вирусов, “слив” базы и пр);
  • XSS (Cross Site Scripting) — атака, в результате которой код внедряется на страницу сайта, и злоумышленник получает несанкционированный доступ к данным: «куки», сессионным ключам, значениям полей и т. п

Как защититься:

• Удаленное исполнение кода исправляется в исходном коде скриптов (установкой патчей безопасности, исправление ошибок разработчика). Частично проблему можно исправить, используя виртуальный патчинг средствами WAF (Web Application Firewall), который будет блокировать запросы, содержащие исполняемый код или вредоносные фрагменты.

• Проблем с AFU можно избежать путем запрета выполнения PHP-скриптов в каталогах загрузки. Для этого размещается специальный конфигурационный файл .htaccess, который будет блокировать доступ к файлам, кроме доверенных, или отключает обработку PHP-сценариев.

• Вопрос с SQL-инъекциями решается с помощью виртуального или реального патчинга исходного кода (исправление ошибок разработчика, который недостаточно хорошо фильтрует входные данные скрипта). Для виртуального патчинга также подойдет WAF, который отфильтрует запросы с SQL инъекциями.

• Для защиты от XSS необходимо прописать набор правил в .htaccess файле или настроить веб-сервер, чтобы в HTTP заголовках содержались специальные параметры, блокирующие возможность проведения атаки.

Небезопасное размещение сайтов на хостинге

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

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

Оказывая услуги по лечению и защите сайтов, мы часто становимся свидетелями того, что на мультисайтовых аккаунтах некоторых веб-мастеров царит полный беспорядок: веб-мастер уже и сам не помнит, какие сайты у него рабочие, а какие давно лежат мертвым грузом, занимая место на хостинге и … служат “пристанищем” для хакерских шеллов и бэкдоров. Если забытый вами сайт все еще открывается в браузере и ранжируется в поисковой выдаче, то он может стать объектом хакерской атаки, а через него могут взломать остальные сайты.

Не используете сайт в работе, нет времени на его проверку и защиту? Заблокируйте или удалите его с хостинга. Возможно, это избавит вас от больших проблем с безопасностью в будущем.

В заключение

Ну, и последнее, не забывайте про элементарные правила безопасности при работе с сайтами. Они просты и понятны, но, к сожалению, часто игнорируются начинающими веб-мастерами:

  1. Регулярно проверяйте компьютеры, с которых выполняете администрирование сайта, коммерческими антивирусами;
  2. Не забывайте менять пароли от хостинга и административной панели сайта, используйте сложные комбинации;
  3. Не храните пароли в программах (ftp-клиентах, браузере, электронной почте);
  4. Храните резервные копии сайта не только на хостинге, но и локального на компьютере;
  5. Работайте в открытых сетях через защищенное соединение (VPN);
  6. Откажитесь от небезопасного FTP – переходите на безопасные SFTP и SCP протоколы.

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

http://www.searchengines.ru/

Создан новый сайт компании «Приморский сахар»

ООО «Приморский сахар» сегодня – это современные технологии переработки сахара-сырца, доступные потребителям цены, возможность продавать сахар круглый год и в любом количестве, способность организовать доставку в любой регион России.

blog

Акция: сайт ЖКХ 1С с рассрочкой по платежу на 3 месяца за 20000 руб.

TSJКомпания «VladWeb» предлагает ТСЖ выгодное предложение. Готовый сайт за 20000 руб. Возможна рассрочка оплаты на 3 месяца. Домен и 1 год хостинга в подарок.

Отраслевое интернет-решение реализовано в соответствии с Постановлением Правительства РФ №731 «Об утверждении стандарта раскрытия информации организациями, осуществляющими деятельность в сфере управления многоквартирными домами».

Возможности сайта для управляющей компаний ЖКХ :

— Система управления сайтом с интуитивно-понятным интерфейсом.
— Личный кабинет жильца, в котором он может:
— Получить и распечатать, не выходя из квартиры, квитанцию на оплату коммунальных услуг;
— Просмотреть баланс платежей и задолженность;
— Ввести показания счетчиков учета воды, газа, электроэнергии и др.;
— Задать вопрос или направить обращение Управлению;
— Размещение общей информации для жильцов, обслуживающихся в управляющей компании или членов ТСЖ, а именно:
— Информация о тарифах;
— Уставные документы;
— Контактная информация о поставщиках услуг;
— Смету расходов ТСЖ;
— Новости, статьи и прочие документы любого содержания.
— Дополнительные возможности для организации расчетного центра:
— Пакетная распечатка квитанций на оплату, организованную по подъездам, домам, целым ТСЖ;
— Формирование сводных отчетов по коммунальным платежам.
— Дополнительные возможности продукта:
— E-mail-напоминания для оповещения должников и неплательщиков.
— Размещение баннеров на сайте;
— 4 варианта цветового оформления.

Интеграция с 1С

Отраслевое тиражное интернет-решение реализовано совместно с компанией 1С и 1С и интегрировано под программу: «1С: Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК». С другими учетными системами интеграция возможна посредством обмена файлами в формате XML.

Почему нельзя покупать дешевые лендинги или как обманывают на рынке Landing Page

Почти каждый день в наше агентство приходят вопросы от клиентов: «Почему ваши услуги стоят так дорого?» или «Я хочу landing за 15 т.р. Что сможете предложить?»

1320858543_pole_chudes

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

На первый встрече с клиентом менеджер по продажам всегда задает 3 вопроса:

  1. Сколько денег и ресурсов вы вложили в текущие источники клиентов?
  2. За какое время они окупились и какую ежемесячную прибыль они приносят?
  3. Какие сроки вы считаете приемлемыми для создания и вывода на окупаемость новго стабильного источника привлечения клиентов и какой размер ежемесячной прибыли вы считаете приемлемым?

Как правило, ответы примерно следующие:

  1. Существующий источник клиентов создавался от 4 месяцев до 2 лет и стоил от 500 000 руб.
  2. Срок окупаемости от 6 до 12 месяцев. Приносит N денег ежемесячно.
  3. Новый источник должен быть создан за 10 дней, окупиться за 5 дней и принести 10 х N денег.

И клиент свято верит в то, что вложив в 15 000 руб в рекламу и 10 000 руб в посадочную страницу, он заработает 1 000 000 руб. Интернет — это же волшебная таблетка. Там одни дураки сидят, конкуренции нет и вокруг тонны голодных клиентов.

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

Для того, чтобы разработать хороший landing page требуются, как минимум:

  • менеджер по продажам;
  • аккаунт менеджер;
  • дизайнер;
  • верстальщик;
  • копирайтер;
  • специалист по настройке рекламы.

Ну, не может качественная работа 6 человек стоить 15 000 руб!

Кроме того, в эту сумму нужно включить прямые расходы агентства:

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

В каком случае лендинг может стоить дешево:

  1. Если всю разработку делают 1 — 2 человека без большого опыта, работая «в черную» в коворкинге или из дома.
  2. Если вам перепродают готовые шаблоны landing page с новым копирайтингом и кривой версткой.

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

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

Во втором случае ситуация еще хуже: вас просто обманывают. На рынке шаблон стоит от 10 до 25 долларов. Вам его продают за 5 000—15 000 руб, немного меняя копирайтинг и, возможно, картинки. Таких компаний гораздо больше, потому что это очень легкий и прибыльный бизнес, правда, больше похожий на барыжничество, чем на маркетинг.

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

  • Он не исполняет обязательств?
  • У него проблемы с алкоголем?
  • Он ворует?

Такие специалисты — большая редкость, их меньше 1% на рынке посадочных страниц.

Помните: скупой всегда платит дважды. Никогда не начинайте мерить лендинги «в граммах». Длинный он или короткий, яркий или темный.

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

http://convertmonster.ru/

Nginx защита от DDoS

Очередная неприятность, на этот раз, как говорят, вызванная DNS Cache Poisoning, от наших китайских друзей:

42.85.85.33 - - [16/Jan/2015:10:05:51 +0400] "GET /announce.php?info_hash=%E2%9B%D7%FAn%3B%E8%E8A%FDP%8E%DB%00%13%9A8U3%EB&peer_id=%2DSD0100%2DsS%B8%88i%A7%BA%DCj6%91%B2&ip=42.85.85.33&port=10148&uploaded=862447643&downloaded=862447643&left=642252800&numwant=200&key=28930&compact=1 HTTP/1.0" 444 0 "-" "Bittorrent"

в купе с активностью других ботнетов заставили написать эту заметку.

При атаке на сетевую инфраструктуру nginx вряд ли поможет. Однако, в случае, когда подозрительный трафик можно определить по заголовкам запросов, а атака направлена на исчерпание ресурсов backend-сервера – nginx может помочь.

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

В простых случаях достаточно фильтровать по заголовкам Host и User-Agent:

if ($host !~* ^(domain.ru|www.domain.ru)$ ) {
    return 444;
}
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
    return 444;
}

В случае с Host лучше использовать конструкцию:

server {
    listen       80;
    server_name  domain.ru www.domain.ru;
    # Здесь основные настройки сервера
}
server {
    listen  80 default_server;
    server_name "";
        access_log /var/log/nginx/ddos/access_log;
        return 444;
}

– таким образом, все запросы со значением заголовка Host, не соответствующего домену сайта будут записываться в log-файл, после чего соединение будет закрыто.

В контексте оператора if, не находящегося внутри location, нельзя использоватьaccess_log, однако, можно использовать error_page таким образом:

location / {
    error_page 403 = @fallback;
}

location @fallback {
    access_log /var/log/nginx/ddos/access_log;
    return 444;
}

Об интересном решении, которое работает по схожему с CloudFlare принципу можно прочесть на habrhabr.ru или github.

Прочие полезные ссылки:

  • http://www.acloudtree.com/how-to-deny-hosts-using-nginx/
  • https://calomel.org/web_server_abuse_detection.html
  • https://calomel.org/nginx.html

Новые тренды 2015

02(4)

Mobile-first. Каждый веб-сайт должен быть мобильным.

По данным Google, в Великобритании доля запросов со смартфонов увеличилась с 18% до 32%, в России этот показатель вырос с 17% до 29%.
В сответствии с Ovum(независимая аналитическая компания), один миллиард людей будет использовать мобильный телефон в качестве единственной формы доступа к сети Интернет в 2015 году.
Бренды шире взглянут на разнообразие форматов в медийной рекламе мобайла, а площадки позволят работать с их контентом как с рекламным.

 

03(3)

Приборы уже начали решать экономические и общественные проблемы без участия человека.

Система «умного дома» следит за температурой, автомобиль помогает припарковаться, датчики контролируют перемещения товаров. Как показало исследование Edelman Berland для GE, 44% руководителей не знают о таком понятии, как «интернет вещей». Все изменится в 2015 году, уверены эксперты eMarketer. Направление движения не вызывает сомнений, неясна только скорость перехода на новый этап.

 

04(1)

Context-Rich Systems

Ожидается, будут активно развиваться системы, по-разному функционирующие в зависимости от контекста, и имеющие возможность адекватно реагировать в различных условиях (так называемые контекстно-зависимые системы, Context-Rich Systems).

 

05(3)

Будущее просвечивает сквозь облака

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

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

 

06(2)

Валюта отправляется в виртуальность

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

И пусть популярные биржи, такие как Mt. Gox, сталкиваются с проблемами из-за отсутствия достаточного опыта и неэффективного управления, важно, что на пике активности площадка обрабатывала до 70% всех Bitcoin-транзакций. В долларах это составило бы порядка 500 миллионов ежемесячно. Впечатляет, правда?

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

Установка php5.5+php-fpm+mysql+nginx на Mac OS X Mavericks

Каждый веб-разработчик, выбравший Mac, после первичной настройки системы ищет рабочий инструментарий. И если c IDE и редакторами всё понятно, то что-либо подобное по удобству win-довым OpenServer или Denwer за бесплатно найти трудно. Есть отличное решение MAMP PRO, но оно стоит две тысячи деревянных. Да и работа через Apache некоторых может смутить.

Занимаясь решением этого вопроса, набрёл на интереснейший материал, который рассказывает о том, как при помощи консольного пакет-менеджера Homebrew настроить рабочее пространство буквально за 5-10 минут. Публикую его перевод, потому что кому-нибудь подобная инструкция по настройке веб-окружения на Mac обязательно пригодится.

mac-nginx-mysql-php

«Только что получил новый MacBook Pro и решил настроить его с чистого листа, потому что я использую тот же бэкап Time Machine примерно уже четверы года. Хороший шанс избавиться от стэка веб-сервера/LAMP (Linux Apache MySQLPHP) и заменить его Nginx и PHP-FPM как реализацию FastCGI. Ниже вы можете прочесть, как настроить Nginx, PHP-FPM, MySQL и PhpMyAdmin на OS X 10.9 / Mavericks.

Xcode

Прежде всего, установите последнюю версию Xcode через Mac App Store:

Скачать Xcode.app (через Mac App Store)

Как только закончится загрузка, откройте Xcode в папке /Applications и согласитесь с лицензией.

Откройте окно Терминала и установите Xcode через следующую команду:

xcode-select --install

Подтвердите установку при помощи кнопки Install.

Вернитесь обратно в Xcode, нажмите ⌘ + , для доступа к настройкам и перейдите на вкладку Locations. УстановитеCommand Line Tools на последнюю доступную версию, Xcode 5.0.2 (5A3005) в моём примере:

Xcode.app → Preferences → Location | Command Line Tools

Homebrew

Теперь необходимо установить Homebrew, который является менеджером пакетов для OS X. Вы возможно уже слышали про apt-get или aptitude на дистрибутивах Linux для установки пакетов и зависимостей для конкретный приложений. brew работает также, только на компьютерах под управлением Mac OS X. Он также удостоверится, что вы получите последние обновления для установленных приложений, так что вам не нужно будет беспокоиться из-за просроченных версиях или брешах в системе безопасности, эксплойтах и так далее.

Прежде всего, нам понадобиться Xquarz:

curl http://xquartz-dl.macosforge.org/SL/XQuartz-2.7.5.dmg -o /tmp/XQuartz.dmg
open /tmp/XQuartz.dmg

Теперь нам необходимо загрузить и установить Homebrew при помощи следующей команды:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

Поверим на любые конфликты и проблемы:

brew doctor

Обновим репозитории и приложения при помощи Homebrew:

brew update
brew upgrade

PHP-FPM

Потому как Homebrew не имеет репозитория по-умолчанию для PHP-FPM, нам необходимо его добавить:

brew tap homebrew/dupes
brew tap josegonzalez/homebrew-php

Установим PHP-FPM при помощи следующих аргументов:

brew install --without-apache --with-fpm --with-mysql php55

Homebrew загрузит исходный код PHP-FPM и скомпилирует его аз вас. Дайте ему немного времени, это может занять несколько минут.

Настройка PHP в командной строке

Если вы хотите использовать PHP в командной строке, вам необходимо обновить переменную окружения $PATH в файле ~/.bash_profile:

echo 'export PATH="$(brew --prefix josegonzalez/php/php55)/bin:$PATH"' >> ~/.bash_profile

Настройка автозапуска

mkdir -p ~/Library/LaunchAgents
cp /usr/local/Cellar/php55/5.5.9/homebrew-php.josegonzalez.php55.plist ~/Library/LaunchAgents/

И старт PHP-FPM:

launchctl load -w ~/Library/LaunchAgents/homebrew-php.josegonzalez.php55.plist 

Удостоверьтесь, что PHP-FPM слушает порт 9000:

lsof -Pni4 | grep LISTEN | grep php

Вывод должен выглядеть примерно следующим образом:

php-fpm   69659  frdmn    6u  IPv4 0x8d8ebe505a1ae01      0t0  TCP 127.0.0.1:9000 (LISTEN)
php-fpm   69660  frdmn    0u  IPv4 0x8d8ebe505a1ae01      0t0  TCP 127.0.0.1:9000 (LISTEN)
php-fpm   69661  frdmn    0u  IPv4 0x8d8ebe505a1ae01      0t0  TCP 127.0.0.1:9000 (LISTEN)
php-fpm   69662  frdmn    0u  IPv4 0x8d8ebe505a1ae01      0t0  TCP 127.0.0.1:9000 (LISTEN)    

MySQL

Следующий шаг для установки MySQL:

brew install mysql

Настройка автозапуска

cp /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents

И запустите сервер баз данных:

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

Обезопасьте установку

Для безопасности нашего MySQL-сервера мы вызовем идущий в компоекте бинарник secure_mysql_installation для смены root-пароля, удаления анонимного пользователя и отключения возможности дистанционного логина под root-ом:

mysql_secure_installation
> Enter current password for root (enter for none):

Пожалуйста, укажите текущий пароль, если он уже установлен.

> Change the root password? [Y/n]

Нажите enter, указав пароль для root-пользователя. По желанию сохраните его в менеджерах паролей LastPass или 1Password.

> Remove anonymous users? [Y/n]

Да, в них нет необходимости.

> Disallow root login remotely? [Y/n]

Да, нет необходимости в авторизации под root с любого другого IP кроме 127.0.0.1.

> Remove test database and access to it? [Y/n]

Да. Нам не нужны тестовые таблицы.

> Reload privilege tables now? [Y/n]

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

Проверка соединения

mysql -uroot -p

Введите указанный ранее root-пароль и увидите консоль MySQL:

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql>

Закончите сессию при помщи команды q:

mysql> q
Bye

phpMyAdmin

Установите autoconf который необходим для phpMyAdmin:

brew install autoconf

Установите переменную окружения $PHP_AUTOCONF:

echo 'PHP_AUTOCONF="'$(which autoconf)'"' >> ~/.bash_profile

Приступим к установке phpMyAdmin:

brew install phpmyadmin

Nginx

Установите Nginx при помощи команды:

brew install nginx

Настройка автозапуска

Так как мы используем 80 порт, необходимо запускать Nginx под пользователем root:

sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons/
sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

Протестриуйте веб-сервер

Запустите Nginx:

sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

Конфигурация по-умолчанию слушает порт 8080 вместо стандартного для протокола HTTP порта 80. Пока проигнорируем это:

curl -IL http://localhost:8080

Ответ должен выглядеть следующим образом:

HTTP/1.1 403 Forbidden
Server: nginx/1.4.4
Date: Sun, 08 Dec 2013 03:33:41 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive

Снова остановим Nginx:

sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

Дальнейшая настройка

nginx.conf

Создайте папки, которые понадобятся нам при последующей конфигурации Nginx:

mkdir -p /usr/local/etc/nginx/logs
mkdir -p /usr/local/etc/nginx/sites-available
mkdir -p /usr/local/etc/nginx/sites-enabled
mkdir -p /usr/local/etc/nginx/conf.d
mkdir -p /usr/local/etc/nginx/ssl
sudo mkdir -p /var/www

sudo chown :staff /var/www
sudo chmod 775 /var/www

Удалите текущий файл nginx.conf (который всегда будет доступен по адресу /usr/local/etc/nginx/nginx.conf.default, если вы захотите взглянуть на его код) и загрузите созданные мною настройки при помощи curl с GitHub:

rm /usr/local/etc/nginx/nginx.conf
curl -L https://gist.github.com/frdmn/7853158/raw/nginx.conf -o /usr/local/etc/nginx/nginx.conf

Конфиуграционный файл прост и легковесен насколько это возможно: настройки worker, пути/форматы логов и несколько includes. Ничего лишнего в отличие от nginx.conf.default.

Загрузка PHP FPM

Скачайте мои настройки PHP-FPM с GitHub:

curl -L https://gist.github.com/frdmn/7853158/raw/php-fpm -o /usr/local/etc/nginx/conf.d/php-fpm

Создание виртуальных хостов

curl -L https://gist.github.com/frdmn/7853158/raw/sites-available_default -o /usr/local/etc/nginx/sites-available/default
curl -L https://gist.github.com/frdmn/7853158/raw/sites-available_default-ssl -o /usr/local/etc/nginx/sites-available/default-ssl
curl -L https://gist.github.com/frdmn/7853158/raw/sites-available_phpmyadmin -o /usr/local/etc/nginx/sites-available/phpmyadmin

Клонируйте тестовый виртуальный хост (включая рерайты для 404, 403 и phpinfo()) используя git:

git clone http://git.frd.mn/frdmn/nginx-virtual-host.git /var/www
rm -rf /var/www/.git

И удалите папку /var/www/.git, чтобы git не отслеживал последующие изменнения.

Настройка SSL

Создайте папку для наших сертификатов SSL и частных ключей:

mkdir -p /usr/local/etc/nginx/ssl

Сгенерируйте 4096bit RSA ключи и само-подписные сертификаты следюущей командой:

openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -subj "/C=US/ST=State/L=Town/O=Office/CN=phpmyadmin" -keyout /usr/local/etc/nginx/ssl/localhost.key -out /usr/local/etc/nginx/ssl/localhost.crt
openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -subj "/C=US/ST=State/L=Town/O=Office/CN=localhost" -keyout /usr/local/etc/nginx/ssl/phpmyadmin.key -out /usr/local/etc/nginx/ssl/phpmyadmin.crt

Включение виртуальных хостов

Теперь нам нужно создать симлинки в папке sites-enabled для виртуальных хостов с целью включить их:

ln -sfv /usr/local/etc/nginx/sites-available/default /usr/local/etc/nginx/sites-enabled/default
ln -sfv /usr/local/etc/nginx/sites-available/default-ssl /usr/local/etc/nginx/sites-enabled/default-ssl
ln -sfv /usr/local/etc/nginx/sites-available/phpmyadmin /usr/local/etc/nginx/sites-enabled/phpmyadmin

Снова стартуем Nginx:

sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

Последние тесты

Вот оно, всё должно работать. Щелкайте на ссылках ниже с целью удостовериться в этом:

Управление сервисами

В силу того, чтоы вам рано или поздно понадобиться перезапустить тот или иной вресив, вам возможно понадобятся дополнительные алиасы:

curl -L https://gist.github.com/frdmn/7853158/raw/bash_aliases -o /tmp/.bash_aliases
cat /tmp/.bash_aliases >> ~/.bash_aliases
echo "code ~/.bash_aliases" >> ~/.bash_profile

Вы можете или открыть новое окно/сессию Терминала или же вручную перезагрузить ~/.bash_profile при помощи команды:

code ~/.bash_profile

Теперь вы можете использовать алиасы вместо печатания длинных команд launchctl, как то было выше.

Nginx

Вы можете стартовать, остановить и перезапустить Nginx при помощи команд:

nginx.start
nginx.stop
nginx.restart

Быстрый доступ к логам:

nginx.logs.access
nginx.logs.default.access
nginx.logs.phpmyadmin.access
nginx.logs.default-ssl.access
nginx.logs.error
nginx.logs.phpmyadmin.error

Проверка конфига:

[sudo] nginx -t

PHP-FPM

Старт, стоп и перезагрузка PHP-FPM:

php-fpm.start
php-fpm.stop
php-fpm.restart

Проверка конфига:

[sudo] php-fpm -t

MySQL

Старт, стоп и рестарт MySQL-сервера:

mysql.start
mysql.stop
mysql.restart

Дайте мне знать, если застряли или у вас есть какие-либо дополнения!»


От себя добавлю, что также при создании локальных доменов и настройке Nginx для работы с ними не забывайте прописывать пару «IP domain.name» в файле hosts при помощи команды sudo vi /etc/hosts.