Posted by elimS on Авг 26, 2010 in
Администрирование 
Подсмотрел на хабре. Решается настройкой групповых политик ограниченного использования программ.
настройка групповых политик ограниченного использования программ. Поскольку AppLocker является «прокачанной» версией данного механизма, логично попробовать именно политики, тем более они бесплатны для пользователей Windows 
Заходим в настройки:
gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики ограниченного использования программ
В случае, если правил нет, система предложит сгенерировать автоматические правила, разрешающие запуск программ из папки Windows и Program Files. Так же добавим запрещающее правило для пути * (любой путь). В результате мы хотим получить возможность запуска программ только из защищенных системных папок. И что же?
Да, это мы и получим, но вот только маленькая незадача — не работают ярлыки и http ссылки. На ссылки еще можно забить, а без ярлыков жить плоховато.
Если разрешить запуск файлов по маске *.lnk — мы получим возможность создать ярлык для любого исполняемого файла, и по ярлыку запустить его, даже если он лежит не в системной папке. Паршиво.
Запрос в гугл приводит к таким решениям: или разрешить запуск ярлыков из пользовательской папки, либо пользовать сторонние бары с ярлычками. Иначе никак. Лично мне такой вариант не нравится.
В итоге мы сталкиваемся с ситуацией, что *.lnk является с точки зрения винды не ссылкой на исполняемый файл, а исполняемым файлом. Бредово, но что ж поделать… Хотелось бы, чтобы винда проверяла не местонахождение ярлычка, а местонахождение файла, на который он ссылается.
И тут я нечаянно натолкнулся на настройки списка расширений, являщихся исполняемыми с точки зрения винды (gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Назначенные типы файлов). Удаляем оттуда LNK и заодно HTTP и релогинимся. Получаем полностью рабочие ярлычки и проверку на местонахождение исполняемого файла.
Было сомнение, можно ли будет передавать через ярлыки параметры — можно, так что все ок.
В результате мы получили реализацию идеи, описанной в статье «Windows-компьютер без антивирусов» без каких либо неудобств для пользователя.
Также для любителей стрелять себе в ногу, можно создать папку в Program Files и кинуть ярлык для нее на рабочий стол, назвав, например «Песочницей». Это позволит запускать оттуда программы без отключения политик, пользуясь защищенным хранилищем (защита через UAC).
Надеюсь описанный метод окажется для кого-то полезным и новым.
Источник
Автор: Popik
Метки: windows, безопасность
Posted by elimS on Июл 6, 2010 in
WordPress Набрел на хабрахабре на очень полезную статью, которая пригодиться не только админам wordpress’a:
На сегодняшний день WordPress как никогда популярен. Блоги, мини-сайты, а то и целые порталы — всё это строится на основе такого удобного движка-конструктора как WordPress. Но за удобностью и лёгкостью освоения кроются, прежде всего, вопросы, связанные с безопасностью вашего сайта. Большая распространённость — большее внимание злоумышленников.
В этой статье описаны десять простых уловок, которые позволят сделать ваш сайт на WordPress’e ещё более защищённым и позволят спокойнее спать по ночам.
1. Защищаем WordPress от XSS-инъекций
В чём проблема?
Программисты всегда стараются защитить GET- и POST- запросы, однако, иногда этого недостаточно. Необходимо защитить блог от XSS-инъекций и попыток модификации переменных GLOBALS и _REQUEST.
Что делаем?
Этот код блокирует использование XSS-инъекций и попытки модифицировать переменные GLOBALS и_REQUEST. Вставьте код в ваш файл .htaccess, расположенный в корне сайта. (И не забывайте бэкапить этот файл перед внесением любых изменений).
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
Как это работает?
Код позволяет проверять все запросы. Если запрос содержит тег <script> или попытку модифицировать значение переменных GLOBALS и _REQUEST, он просто блокирует его и выдаёт пользователю 403-ю ошибку.
2. Убираем показ лишней информации
В чём проблема?
Если при попытке зайти в админку WordPress’a вы ошибётесь с логином или паролем, вежливый движок скажет вам об этом. Ну а зачем злоумышленнику знать, что пароль, который он пытается подобрать – неверен? Давайте просто уберём вывод этой информации и чуток запутаем его.
Что делаем?
Открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем следующий код:
add_filter('login_errors',create_function('$a', "return null;"));
сохраняем файл. Вуаля – больше никаких сообщений.
Как это работает?
С помощью этого хука мы переписываем стандартную функцию the login_errors(). В результате этого, в случае, когда введены неправильный логин или пароль, никакой информации, объясняющей ситуацию не появится — то, что нам нужно.
3. Принудительное использование SSL
В чём проблема?
Если вы хотите, чтобы передаваемая вами информация была защищена, вам необходимо использовать SSL—протокол, обеспечивающий целостность и конфиденциальность обмена данными. В WordPress’e это сделать проще простого.
Что делаем?
Прежде всего узнаём, есть ли возможность у вашего провайдера использовать SSL. Если да, то открываем файл wp-config.php (обитающий в корне сайта) и добавляем следующую строку:
define('FORCE_SSL_ADMIN', true);
Как это работает?
Всё просто. WordPress использует множество констант и FORCE_SSL_ADMIN всего лишь одна из них. Эта константа включает принудительное использование SSL при заходе в панель администратора.
4. Используем .htaccess для защиты файла wp-config
В чём проблема?
wp-config.php содержит все данные, необходимые для подключения к серверу MySQL и базе данных. Защита этого файла – одна из самых главных задач.
Что делаем?
Находим файл .htaccess в корне нашего сайта и добавляем следующие строки:
<files wp-config.php>
order allow,deny
deny from all
</files>
Как это работает?
Мы просто запрещаем доступ к этому сайту кому бы то ни было. Теперь уж точно ни один бот не сможет и близко подойти к этому файлу.
5. Скрываем версию WordPress’a
В чём проблема?
Wordpress автоматически вставляет номер своей версии в исходный код страниц. К сожалению, не всегда удаётся вовремя обновлять движок. А это означает, что зная какая у вас версия WordPress’a со всеми её брешами и слабыми местами, злоумышленник может очень-очень огорчить вас. Что делаем? Правильно, убираем вывод версии.
Что делаем?
Снова открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем туда этот код —
remove_action('wp_head', 'wp_generator');
Как это работает?
Хуки WordPress’a позволяют легко заменять одну функцию на другую. Именно этим мы сейчас и воспользовались – мы просто запретили вывод информации о версии нашего движка.
6. Баним спамеров и ботов
В чём проблема?
Надоедливые постеры и спамеры. Решение – запретить им доступ к сайту по IP. Конечно, это не защитит от спам-скриптов, постоянно меняющих прокси, но немного облегчить жизнь вполне может.
Что делаем?
Вставьте этот код в файл .htaccess. Просто поменяйте адрес 123.456.789 на IP того редиски нехорошего человека, который вас достаёт и всё — он забанен всерьёз и надолго.
<Limit GET POST PUT>
order allow,deny
allow from all
deny from 123.456.789
</LIMIT>
Как это работает?
И снова нам на помощь приходит apache. Посредством файла .htaccess мы запрещаем доступ к сайтe пользователям с конкретным IP. Нужно забанить ещё кого-то? Просто добавим ещё одну строку, к примеру —
deny from 93.121.788
7. Пишем плагин для защиты от зловредных url-запросов
В чём проблема?
Хакеры и недохакеры всех родов очень часто пытаются найти слабые места при помощи всевозможных зловредных запросов. WordPress неплохо защищён от этого, но лишняя защита никогда не повредит.
Что делаем?
Создаём новый файл под названием blockbadqueries.php и помещаем его в папку wp-content/plugins. Затем просто активируйте его в админке как любой другой плагин.
<?php
/*
Plugin Name: Block Bad Queries
Plugin URI: perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests/
Description: Protect WordPress Against Malicious URL Requests
Author URI: perishablepress.com/
Author: Perishable Press
Version: 1.0
*/
global $user_ID;
if($user_ID) {
if(!current_user_can('level_10')) {
if (strlen($_SERVER['REQUEST_URI']) > 255 ||
strpos($_SERVER['REQUEST_URI'], "eval(") ||
strpos($_SERVER['REQUEST_URI'], "CONCAT") ||
strpos($_SERVER['REQUEST_URI'], "UNION+SELECT") ||
strpos($_SERVER['REQUEST_URI'], "base64")) {
@header("HTTP/1.1 414 Request-URI Too Long");
@header("Status: 414 Request-URI Too Long");
@header("Connection: Close");
@exit;
}
}
}
?>
Как это работает?
Работа этого плагина проста – он проверяет все длинные запросы (более 255 символов) и наличие php-функций eval или base64 в URI. Если что-то из этого находится, браузеру пользователя отдаётся страница с ошибкой 414.
8. Личеры!
В чём проблема?
Мир полон добрых людей, которые изо всех сил пытаются донести до других новость или статью, написанную вами. Всё бы ничего, но ведь по доброте душевной они берут картинки прямо с наших с вами серверов, скромно забывая при этом про слово «трафик». А теперь представьте что будет, если ссылки на наши картинки попадут на какой-нибудь популярный китайский блог, с их-то почти уже четырёхсотмиллионным интернет-населением! Свят-свят-свят… Значит сейчас будем защищать хотлинкинг, a.k.a. личинг, a.k.a. «да я просто вставил ссылки на файлы с вашего сервера».
Что делаем?
И опять всемогущий apache поможет защищить нам наш трафик. Достаём в очередной раз файлик.htaccess и пишем следующее:
RewriteEngine On
#Замените ?mysite\.ru/ на адрес вашего сайта
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Замените /images/nohotlink.jpg на название вашей картинки с лозунгом «личер идёт на…»
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]
Как это работает?
При помощи этих правил мы заставляем сервер проверять откуда пришёл запрос на нашу фотку — если со страниц нашего сайта, он отдаёт её пользователю. Если с «вражеского» — то показывает личерам какую-нибудь обидную картинку.
9. Убить админа. (Нет дефолтному юзернейму «admin»)!
В чём проблема?
Злоумышленникам всегда проще получить доступ к сайту при помощи брута, если уже известен логин. При этом на протяжении многих лет дефолтный логин админа был примитивным до зубного скрежета — «admin».
Надо сказать, что в новом WordPress 3.0 у вас есть право указать любой логин, какой только душе будет угодно. Для остальных версий нужно применить одно волшебное заклинание.
Что делаем?
Просто выполняем этот запрос к базе данных:
UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';
Как это работает?
С помощью sql-запроса меняем дефолтный логин. Правда, есть одно «но». Посты, написанные ранееadmin‘ом не поменяют своего автора. А для того чтобы извести admin‘a на корню, необходимо выполнить ещё один запрос:
UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';
10. Защита директорий на сервере от просмотра
В чём проблема?
Очень многие хостеры позволяют просматривать директории на своих серверах. Поэтому, если ввести в адресную строку www.вашблог.ru/wp-includes, то очень часто можно увидеть всё содержимое этой директории. Безусловно это небезопасно, поэтому лучше это сразу запретить.
Что делаем?
Вы можете либо добавить пустые файлы index.html в папки, просмотр которых хотели бы запретить. Либо дополнить наш .htaccess ещё одной строкой:
Options All -Indexes
Как это работает?
Пустой index.html будет выдаваться каждый раз, когда последует запрос к директории. Ну а директива в.htaccess просто запрещает апачу выдавать список содержимого директории.
Источник
Метки: WordPress, безопасность