Защита от хакеров | Информационный портал К2®

Tag Archives: Защита от хакеров

Ещё 10 уловок для защиты WordPress’a

Posted on 26.06.2015 by rudjuk Leave a comment

На сегодняшний день 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]

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]

Как это работает?
Код позволяет проверять все запросы. Если запрос содержит тег или попытку модифицировать значение переменных GLOBALS и _REQUEST, он просто блокирует его и выдаёт пользователю 403-ю ошибку.

2. Убираем показ лишней информации

В чём проблема? Если при попытке зайти в админку WordPress’a вы ошибётесь с логином или паролем, вежливый движок скажет вам об этом. Ну а зачем злоумышленнику знать, что пароль, который он пытается подобрать – неверен? Давайте просто уберём вывод этой информации и чуток запутаем его.

Что делаем?
Открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем следующий код:

add_filter('login_errors',create_function('$a', "return null;"));

1	add_filter('login_errors',create_function('$a', "return null;"));

сохраняем файл. Вуаля – больше никаких сообщений.

Как это работает?
С помощью этого хука мы переписываем стандартную функцию login_errors(). В результате этого, в случае, когда введены неправильный логин или пароль, никакой информации, объясняющей ситуацию не появится — то, что нам нужно.

3. Принудительное использование SSL

В чём проблема? Если вы хотите, чтобы передаваемая вами информация была защищена, вам необходимо использовать SSL—протокол, обеспечивающий целостность и конфиденциальность обмена данными. В WordPress’e это сделать проще простого.

Что делаем?
Прежде всего узнаём, есть ли возможность у вашего провайдера использовать SSL. Если да, то открываем файл wp-config.php (обитающий в корне сайта) и добавляем следующую строку:

define('FORCE_SSL_ADMIN', true);

1	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>

order allow,deny

deny from all

</files>

Как это работает? Мы просто запрещаем доступ к этому файлу кому бы то ни было. Теперь уж точно ни один бот не сможет и близко подойти к этому файлу.

5. Скрываем версию WordPress’a

В чём проблема? Wordpress автоматически вставляет номер своей версии в исходный код страниц. К сожалению, не всегда удаётся вовремя обновлять движок. А это означает, что зная какая у вас версия WordPress’a со всеми её брешами и слабыми местами, злоумышленник может очень-очень огорчить вас. Что делаем? Правильно, убираем вывод версии.

Что делаем?
Снова открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем туда этот код —

remove_action('wp_head', 'wp_generator');

1	remove_action('wp_head', 'wp_generator');

Как это работает? Хуки WordPress'a позволяют легко заменять одну функцию на другую. Именно этим мы сейчас и воспользовались – мы просто запретили вывод информации о версии нашего движка.

+ как справедливо указал пользователь rOOse, необходимо также удалить файл readme.html, находящийся в корне сайта. В нём тоже содержится информация о текущей версии 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>

order allow,deny

allow from all

deny from 123.456.789

</LIMIT>

Как это работает? И снова нам на помощь приходит apache. Посредством файла .htaccess мы запрещаем доступ к сайтe пользователям с конкретным IP. Нужно забанить ещё кого-то? Просто добавим ещё одну строку, к примеру -

deny from 93.121.788

1	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;
    }
  }
}

?>

<?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]

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';

1	UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';

Как это работает? С помощью sql-запроса меняем дефолтный логин. Правда, есть одно «но». Посты, написанные ранее admin'ом не поменяют своего автора. А для того чтобы извести admin'a на корню, необходимо выполнить ещё один запрос:

UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

1	UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

10. Защита директорий на сервере от просмотра

В чём проблема? Очень многие хостеры позволяют просматривать директории на своих серверах. Поэтому, если ввести в адресную строку www.вашблог.ru/wp-includes, то очень часто можно увидеть всё содержимое этой директории. Безусловно это небезопасно, поэтому лучше это сразу запретить.

Что делаем?
Вы можете либо добавить пустые файлы index.html в папки, просмотр которых хотели бы запретить. Либо дополнить наш .htaccess ещё одной строкой:

Options All -Indexes

1	Options All -Indexes

Как это работает? Пустой index.html будет выдаваться каждый раз, когда последует запрос к директории. Ну а директива в .htaccess просто запрещает апачу выдавать список содержимого директории.

Источник: http://habrahabr.ru/post/98083/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Защита файла wp-config.php в nginx

Posted on 26.06.2015 by rudjuk Leave a comment

А в т о р : Р у д ю к С . А .
https://corp2.net
E-Mail: rs@corp2.net

В файле wp-config.php CMS WordPress хранит пароли и логины для доступа к базе данных. Это очень безопасная информация. Есть вероятность, что в момент отладки приложения или веб-сервера данный файл может быть доступен злоумышленникам, поэтому, рекомендуется защищать данный файл от доступа в веб-серверах.

Защита в веб-сервере Apache указывается в файле .htaccess:

# Deny public access to wp-config.php
<Files wp-config.php>
    Order allow,deny
    Deny from all
</Files>

# Deny public access to wp-config.php

Order allow,deny

Deny from all

</Files>

Защита в веб-сервере Nginx:

# Deny public access to wp-config.php
location ~* wp-config.php { 
    deny all; 
}

# Deny public access to wp-config.php

location ~* wp-config.php {

deny all;

}

А в т о р : Р у д ю к С . А . https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Безопасность WordPress. 3 самых эффективных способа защиты от брутфорса

Posted on 26.06.2015 by rudjuk Leave a comment

По статистике, около 19% от общего количества всех сайтов Интернета, работают на WordPress — это почти каждый пятый сайт. Успех платформы вполне логичен и закономерен, не зря еще 5 лет назад я сделал ставку именно на нее. Но сегодня речь пойдет не о преимуществах WordPress, а о его безопасности. Высокая популярность платформы активизировала злые силы, и вот уже на протяжении нескольких месяцев в Рунете идут массовые атаки на сайты, работающие на WordPress. Атаки настолько серьезные и настолько массовые, что не выдерживают даже самые мощные серверы. Хостинг-провайдеры, конечно, принимают меры, порой даже самые радикальные, вплоть до полной блокировки администраторских консолей WordPress. Поэтому, если вас еще не заблокировали, лучше самостоятельно провести ряд несложный действий по укреплению обороны вашего WordPress.

В этой статье я расскажу о самых эффективных способах защиты вашего сайта именно от брутфорса (brute force) — метода подбора и взлома пароля путем перебора всех теоретически возможных вариантов. Так как все последние массовые атаки работают по этому методу.

1. Первое с чего нужно начать — это избавиться от пользователя admin. Если у вас нет пользователя admin, можете сразу переходить к пункту 2. В WordPress начиная с 3 версии это делается очень просто. Достаточно создать нового пользователя, наделить его администраторскими правами, а старого пользователя «admin» — удалить. При его удалении, WordPress предложит вам выбрать нового пользователя, который станет автором публикаций старого администратора.

В старых версиях WordPress эта процедура проделывается с помощью пары SQL-запросов:

UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';
UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

1 2	UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin'; UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

2. Очень важно обратить внимание на пароль администратора. Лучше если это будет хаотичная комбинация заглавных и строчных букв, знаков и цифр не менее чем из 10-12 символов.

3. При бутфорсе WordPress, производится огромное количество запросов к файлу авторизации «wp-login.php», и будет правильно обеспечить ему двойную защиту.

Если вы работаете с сайтом один, и ваш интернет-провайдер предоставляет вам статичный IP-адрес, вы можете разрешить доступ к директории «wp-admin» только с вашего IP-адреса, заблокировав тем самым для всех остальных даже возможность авторизации. Делается это следующим образом. В директории «wp-admin» создаем файл «.htaccess» следующего содержания:

order deny,allow
deny from all
allow from IP

order deny,allow

deny from all

allow from IP

Где IP — это ваш IP-адрес. Узнать его вы можете, например, здесь.

Если же, кроме вас с сайтом работают еще люди со статическими IP-адресами, вы можете просто добавить их в список ниже. Например, так:

order deny,allow
deny from all
allow from IP1
allow from IP2
allow from IP3

order deny,allow

deny from all

allow from IP1

allow from IP2

allow from IP3

Где, IP1, IP2, IP3 — разрешенные IP-адреса.

Благодаря этому, все пользователи (боты) с IP-адресами, не указанными в списке разрешенных, просто не получат доступа к директории «wp-admin» и, соответственно, не смогут брутфорсить файл «wp-login.php». Всем им будет возвращаться ошибка 403.

Если провайдер вам выдает динамический IP-адрес, меняющийся с каждым новым подключением к Интернету, тогда этот способ не пройдет, т.к «.htaccess» придется редактировать при каждом вашем подключении к Сети. С помощью все того же «.htaccess» мы можем установить дополнительную серверную HTTP-авторизацию. Делается это следующим образом.

Все в той же директории «wp-admin» создаются два файла: «.htaccess» и «.htpasswd». В первом будут храниться инструкции, во втором разрешенные данные для доступа к директории.

В «.htaccess» пишем следующее:

AuthType basic
AuthName 'Access Denied'
AuthUserFile '/fullpath/.htpasswd'
Require valid-user
DirectoryIndex index.php

AuthType basic

AuthName 'Access Denied'

AuthUserFile '/fullpath/.htpasswd'

Require valid-user

DirectoryIndex index.php

Где fullpath — полный путь к файлу «.htpasswd». Обратите на это должное внимание, т.к это самая частая ошибка. Полный путь вы можете узнать у своего хостинг-провайдера или с помощью небольшого php-скрипта:

$dir = dirname(__FILE__);
echo '<p>Полный путь: ' . $dir . '/</p>';

1 2	$dir = dirname(__FILE__); echo '<p>Полный путь: ' . $dir . '/</p>';

Или другим способом:

echo '<p>Полный путь: ' . $_SERVER['DOCUMENT_ROOT'] . '/</p>';

1	echo '<p>Полный путь: ' . $_SERVER['DOCUMENT_ROOT'] . '/</p>';

Если вы по каким-то причинам не хотите паролить всю директорию «wp-admin», вы можете запаролить непосредственно файл «wp-login.php». Делается это аналогично, но в «.htaccess» нужно написать следующее:

<filesmatch "wp-login.php"="">
AuthName 'Access Denied'
AuthType Basic
AuthUserFile '/fullpath/.htpasswd'
require valid-user
</filesmatch>

AuthName 'Access Denied'

AuthType Basic

AuthUserFile '/fullpath/.htpasswd'

require valid-user

</filesmatch>

Файл «.htpasswd» в обоих случаях должен выглядеть следующим образом:

username:password

1	username:password

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

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

username1:password1
username2:password2
username3:password3

username1:password1

username2:password2

username3:password3

Если вы сделаете все правильно, перед авторизацией в WordPress вам будет предложено ввести логин и пароль доступа к директории (файлу). И только после успешного входа вы сможете авторизоваться и войти в администраторскую консоль.

В Safari 6.0.5 на Mac OS это выглядит примерно так:

В других браузерах возможно немного иначе.

Выполнив хотя бы эти 3 пункта, вы в разы снизите вероятность взлома вашего WordPress.

Дополнительные меры по защите WordPress

Дополнительно вы можете защитить таким же образом файл настроек WordPress «wp-config.php». Я бы рекомендовал его защитить, потому что в нем содержатся данные для подключения к БД MySQL. Делается это аналогично:

<files wp-config.php="">
order allow,deny
deny from all
</files>

order allow,deny

deny from all

</files>

Также, я бы рекомендовал вам проверить директории вашего сайта. Дело в том, что очень многие хостеры и безалаберные сисадмины не закрывают по-дефолту просмотр директорий сайтов своих клиентов. Если, к примеру, ввести в адресную строку браузера: http://вашсайт/wp-includes/ и вы увидете содержимое этой директории — нужно бить тревогу и срочно закрывать просмотр. Для этого можно создать в директориях, которые вы хотите закрыть от просмотра, пустые файлы «index.html» или дописать в ваш «.htaccess» всего одну строку:

Options All -Indexes

1	Options All -Indexes

Которая запретит серверу показывать содержимое директорий.

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

Их обзор в рамках данной публикации я проводить не буду.

Если в процессе настройки защиты WordPress от брутфорса у вас возникнут сложности — вы всегда можете обратиться ко мне за помощью. Контакты здесь.

Кстати

Защита от хакеров Linux Ubuntu

Posted on 08.06.2015 by rudjuk Leave a comment

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

1. Есть подозрение, что кто-то подключился к рабочему столу

Смотрим:
who

r tty7 2013-03-11 06:52 (:0)
r pts/2 2013-04-03 05:21 (192.168.3.62)
r pts/6 2013-04-03 08:27 (192.168.3.62)
r pts/5 2013-04-03 07:58 (192.168.3.62)
(unknown) tty8 2013-04-03 06:16 (:1)
(unknown) tty9 2013-04-03 08:28 (:2)
(unknown) tty10 2013-04-03 08:47 (:3)

Прежде всего, обращаем внимание на подозрительных пользователей. Так, например, пользователь (unknown) — это странное явление. Значит, нужно его выкинуть и закрыться от возможности его подключения.
Выполняем:

who -a -p
завантаження системи 2013-03-11 06:54
рівень виконання 2 2013-03-11 06:54
ВХІД tty4 2013-03-11 06:54 1575 id=4
ВХІД tty5 2013-03-11 06:54 1581 id=5
ВХІД tty2 2013-03-11 06:54 1588 id=2
ВХІД tty3 2013-03-11 06:54 1589 id=3
ВХІД tty6 2013-03-11 06:54 1593 id=6
r + tty7 2013-03-11 06:52 да 4824 (:0)
ВХІД tty1 2013-03-11 06:52 5937 id=1
pts/2 2013-03-11 06:57 0 id=/2 термінал=0 вихід=0
r + pts/2 2013-04-03 05:21 01:26 2104 (192.168.3.62)
r + pts/6 2013-04-03 08:27 . 409 (192.168.3.62)
pts/7 2013-03-11 11:45 0 id=/7 термінал=0 вихід=0
pts/8 2013-04-03 09:21 15957 id=ts/8 термінал=0 вихід=0
pts/10 2013-04-03 09:13 14507 id=s/10 термінал=0 вихід=0
pts/12 2013-03-11 10:18 19235 id=s/12 термінал=0 вихід=0
pts/14 2013-03-11 10:31 21030 id=s/14 термінал=0 вихід=0
r + pts/5 2013-04-03 07:58 00:05 23871 (192.168.3.62)
pts/3 2013-04-03 07:36 5537 id=ts/3 термінал=0 вихід=0
pts/7 2013-04-03 09:17 10140 id=ts/7 термінал=0 вихід=0
pts/9 2013-04-03 09:14 14013 id=ts/9 термінал=0 вихід=0
pts/11 2013-03-19 18:33 6218 id=s/11 термінал=0 вихід=0
pts/13 2013-03-11 22:14 17281 id=s/13 термінал=0 вихід=0
pts/15 2013-03-11 22:33 18853 id=s/15 термінал=0 вихід=0
pts/17 2013-03-11 21:52 19310 id=s/17 термінал=0 вихід=0
pts/6 2013-03-25 07:43 0 id=/6 термінал=0 вихід=0
pts/8 2013-03-25 07:43 0 id=/8 термінал=0 вихід=0
(unknown) + tty8 2013-04-03 06:16 да 5873 (:1)
(unknown) + tty9 2013-04-03 08:28 да 813 (:2)
tty10 2013-04-03 09:10 7691 id=:3 термінал=0 вихід=0

Убиваем злодея:
kill 5873 813

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

2. Запрет удаленного подключения к X11 через ssh
По умолчанию, ssh разрешает запускать x11 через ssh. Т.е. можно запускать графические приложения linux на сервере, используя протокол ssh.
Как это делается, написано в статье: http://d51x.ru/page/udalennyj-dostup-x11-forwarding

Но, вопреки этому, советую все же данную возможность отключать.
Редактируем файл: /etc/ssh/sshd_config
Меняем выражение:
X11Forwarding no

Перезагружаем ssh:

<b><span class="sh_symbol">/</span>etc<span class="sh_symbol">/</span>init<span class="sh_symbol">.</span>d<span class="sh_symbol">/</span>ssh restart</b>

1	<b><span class="sh_symbol">/</span>etc<span class="sh_symbol">/</span>init<span class="sh_symbol">.</span>d<span class="sh_symbol">/</span>ssh restart</b>

3. Ограничиваем доступ по ssh
Редактируем все тот же конфигурационный файл для ssh: /etc/ssh/sshd_config
Желательно, сменить номер порта ssh (чтоб никто не знал, что там находится ssh :):
Port 22

Так же, можно изменить адрес, на котором слушает демон:
ListenAddress 0.0.0.0

Разрешаем вход по ssh только определенным пользователям:
AllowUsers user1 user2 user3

Перезагружаем ssh:

<b><span class="sh_symbol">/</span>etc<span class="sh_symbol">/</span>init<span class="sh_symbol">.</span>d<span class="sh_symbol">/</span>ssh restart</b>

1	<b><span class="sh_symbol">/</span>etc<span class="sh_symbol">/</span>init<span class="sh_symbol">.</span>d<span class="sh_symbol">/</span>ssh restart</b>

4. Настраиваем файервол

Устанавливаем расширение (настройки) для iptables:
apt-get install arno-iptables-firewall

Конфигурируем порты /etc/arno-iptables-firewall/conf.d
Например:

EXT_IF=»eth0 ppp0″
EXT_IF_DHCP_IP=1

# 3343,4434 — Порты для администрирования svn
# 9000 — порт для darkstat
# 3389 — терминал Windows
# 1500 — ???
# 8080 — порт для доступа к svn
# 1500 — ISP админка
# 440 — новый номер порта для ssh
# 22 — был ssh УБРАН

OPEN_TCP=»80,443,21,6543,47,3343,4434,8080,1500,440″

# 110,25,995

OPEN_UDP=»»
INT_IF=»eth1″
NAT=0
INTERNAL_NET=»192.168.3.0/24″
NAT_INTERNAL_NET=»eth1″
OPEN_ICMP=1
LAN_OPEN_TCP=»80,443,21,6543,1723,47,3389,1500,9000,5900,440″

Перезагружаем:
invoke-rc.d arno-iptables-firewall restart

5. Из sudo удаляем лишних пользователей

Редактируем файл: /etc/sudoers

Комментарим root, перечисляем наших пользователей-админов и комментарим доступ к sudo для груп администраторов и т.п.

Вот пример, того, что у меня получилось:

# User privilege specification
#root ALL=(ALL:ALL) ALL
r ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
#%sudo<>ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on «#include» directives:

#includedir /etc/sudoers.d

6. Делаем сложный пароль для пользователя root
Хакеры пытаются подобрать пароль супер-пользователя root простым перебором. Поэтому, делайте пароль для данного пользователя не менее 12 символом и посложнее.

Для изменения пароля пользователя root, выполняем:
passwd root

7. Защита дыр в Apache.
Выполните команду:
curl -I -H "Request-Range: bytes=0-1,0-2,0-3,0-4,0-5,0-6" -s Ваш домен/robots.txt | grep Partial
Если у Вас выдастся ответ 206 Partial Content, то это означает, что Ваш Apache имеет не плохую уязвимость.

Для того, чтоб убрать данную уязвимость, выполните:
sudo a2enmod headers

В Nginx пропишите:
proxy_set_header Range ""; proxy_set_header Request-Range "";
В Apache пропишите:
SetEnvIf Range (?:,.*?){5,5} bad-range=1 RequestHeader unset Range env=bad-range RequestHeader unset Request-Range

Перезагрузите веб-сервис:
/etc/init.d/apache2 restart

Приложение SECUREit в Lenovo S860

Posted on 08.06.2015 by rudjuk Leave a comment

А в т о р : Р у д ю к С . А .
https://corp2.net
E-Mail: rs@corp2.net

Нужно признать, что телефон Lenovo S860 (black) оправдал все мои надежды:
— Данный телефон дешевле, чем телефоны Samsung Galaxy — мне он обошелся около 3 тыс. грн.
— В нем вставляется 2 SIM-карты.
— Параметры его конкурируют даже с одно-симковыми телефонами Samsung Galaxy.
— Высокое время реальной автономной работы в активном режиме эксплуатации 2-3 дня.
— Большой удобный экран.
— Есть дополнительное программное обеспечение SECUREit — для защиты информации на телефоне.
С помощью SECUREit можно отслеживать трафик, производить удаленную блокировку и удаление данных с телефона, снимать задачи, оптимизировать процессы. защищаться от спама и т.п.