Блог о технологиях, технократии и методиках борьбы с граблями
Никак не мог понять, почему на моих основных сайтах под WordPress бэкап весит по полтора гига, при этом базы тянули по 700-800 метров, то есть фактически столько же сколько и здоровые архивы фотографий.
Необходимо скачать с сайта архив в rar, но негодяйский апач отдает архив в виде текстового файла в крякозябрах. Причем, как и следовало ожидать, при переименовывании файла в zip – скачка запускается корректно.
Уже как то писал о волне брут-форс атак, прошедших несколько месяцев назад по сайтам под управлением CMS WordPress. Смысл был в получении доступа к админской части сайта, с последующим заливом на него вредоносных кодов, основанных на редиректе пользователя на зараженные и фишинговые сайты.
В этой связи как никогда встал вопрос защиты веб-сайта wp от атаки перебора пароля. Наиболее простым видом защиты является смена дефолтного администратора сайта admin на рандомное имя и задание ему отдельного ник-нейма, чтобы реальное имя пользователя нигде не светилось. И создание для этого пользователя сложного пароля, включающего как заглавные буквы, так и цифры со спец.символами.
В начале апреля были обнаружены проблемы уязвимости веб-сервера Apache, благодаря которым вредоносное ПО Darkleech могло заражать компьютеры посетителей через уязвимости браузеров, используя iframe и JavaScript. Причем вредоносный код размещался как модуль Apache, что затрудняло его выявление.
Сам механизм заражения не был ясен, но уязвимости подвергались сервера под управлением панелей администрирования cPanel и Plesk.
После переезда блога WordPress на новый хостинг, образовался довольно интересный глюк- не хотели грузиться изображения в Media библиотеку, причем ошибка была такова, что не система не может загрузить изображение по старому пути, то есть имевшемуся на старом хостинге.
В одном из проектов мне пришлось прорабатывать тему видеосервера для телепрограммы под высокой нагрузкой, порядка 70-80к уников в сутки, которые генерили около полуляма просмотров, и что самое интересное- единственные кто мне смог дать внятную консультацию- это так называемые AWM, то есть вебмастера работающие в сфере адалта, так как в этой нише условия наиболее приближены к требуемым мне: видео и высокие нагрузки.
После ряда консультаций я продолжил общение с помогавшими мне людьми, так что когда мне предложили статью на тему балансировки нагрузки высоконагруженного сервера, на примере работающего проекта, я не отказался. Далее сохранена авторский стиль изложения. Учитывая что я с несколькими бывшими коллегами вел общение на тему моего проекта и творчества в интернете, то полагаю, что в дальнейшем буду публиковать еще статьи коллег по цеху.
Вебмастера, как правило, не особенно вникают в технические особенности настройки серверов – это дело администраторов. Но логику стоит знать, хотя бы затем, чтобы иметь возможность объяснить своему администратору, как и для чего вы хотите настроить вашу систему.
Нашел тут статейку, что кропал в начале 2012 года, но почему то до сих пор не запостил, так что как грится, привожу “без купюр”.
Возникла необходимость скоренько поднять на коленке веб сервер, в связи с чем понял что на филигранную отточку конфигов во фре у меня нет ни времени ни желания, поэтому решил что это будет CentOS 5.8, ибо на данный момент это последняя сборка.
Предполагаю, что со всеми сервисами вы более менее знакомы, поэтому все будет описано довольно кратко, ибо разбирать в процессе мануала тонкие настройки мускуля или апача- не вижу смысла.
Ставить операционку CentOS никаких проблем и секретов нет, так что просто поднимаем машину отключив все кроме X Windows, патчим её и приступаем к настройке сервака. Также в процессе настройки отключаем все фичи безопасности, типо фаервола и SELinux, ибо вещи это хорошие, но лучше их включить позже.
