Защищаем домен и отбиваем атаку рефспама с помощью Nginx.

Самым простым способом защиты будет перечисление проблемных реферов, и отдача 444 ошибки соединениям с ними:

if ($http_referer ~* "(domain1.com|domain2.com|domain3.com)") {
return 444;

Читать →

В сегодняшней статье рассмотрим конфигурацию Nginx для получения рейтинга A+ на сайте ssllabs.

Начальная конфигурация:

• Сервер Ubuntu Server 18.04
• VestaCP – контроль панель
• Web сервер Nginx v1.17.2
• DNS сервер bind9
• PHP v7.4
• MySQL v5.7

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

И так начнем:

Настройка сжатия в Nginx

Открываем файл конфигурации nginx

sudo nano /etc/nginx/nginx.conf

И вносим в секцию http следующие строки:

##Compression
gzip                on;
gzip_static         on;
gzip_vary           on;
gzip_comp_level     6;
gzip_min_length     1024;
gzip_buffers        16 8k;
gzip_types          text/plain text/css text/javascript text/js text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/x-font-t$
gzip_proxied        any;
gzip_disable        "MSIE [1-6].";

Настройка stapling в Nginx

Для начала создадим файл dhparams.pem:

sudo openssl dhparam -out /home/admin/conf/web/dhparams.pem 4096

путь можете указать свой, но не забудьте тогда поменять его и в конфигурации nginx

Также ускорим проверку сертификата клиентом и увеличим скорость загрузку сайта. Для этого у вас должен быть сертификат SSL. У меня сертификат от letsencrypt, для него и привожу пример. Сертификат получен при помощи certbot установленного в системе.

Давайте добавим в конфигурацию nginx, следующую секцию:

##Stapling Session
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/obu4alka.ru/chain.pem;
resolver 8.8.8.8;
ssl_session_tickets off;
ssl_dhparam /home/admin/conf/web/dhparams.pem;

название сайта и пути пишем свои.

Включаем HSTS в Nginx

В секцию http:

## HSTS Session
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";

Настройка TLSv3 в Nginx

Также вносим в секцию http:

##SSL Session
ssl_session_cache   shared:SSL:10m;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Если необходимо, то можете добавить TLSv1.1 и TLSv1.0 в ssl_protocols

Сгенерировать шрифты можно по адресу SSL Configuration Generator

Включаем SSL и HTTP2 в Nginx

Открываем на редактирование файлы виртуальных хостов. По умолчанию они находятся в директории /etc/nginx/sites-enabled/ваш-сайт.conf

В моем случае пути следующие:

sudo nano /home/admin/conf/web/mysite.nginx.ssl.conf

И вношу изменение:

##было
server {
     listen      80.81.82.83:443 ;
     server_name obu4alka.ru www.obu4alka.ru;

##стало
server {
     listen      80.81.82.83:443 http2 ssl;
     server_name obu4alka.ru www.obu4alka.ru;

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

server {
     listen      80.81.82.83:443 http2 ssl;
     server_name obu4alka.ru www.obu4alka.ru;
     if ($host != $server_name) {
        return 444;
     }

Тестирование на получения рейтинга A+

переходим на сайт ssllabs.com – для тестирования и получения рейтинга.

Также можете перейти на сайт hstspreload.org– для внесения сайта в списки HSTS сайтов.

[endtxt]

RSS

• Тест скорости дисков в Linux
• Как запустить команду в фоне в Linux
• Ошибка несоответствие размеров GPT PMBR
• nginx: [warn] protocol options redefined
• Как включить поддержку linux в windows 11

Всем доброе время суток. Сегодня рассмотрим пример по устранению ошибки nginx “SSL_ERROR_RX_RECORD_TOO_LONG”, которая появилась после обновления ключей ssl в админ панели VestaCP.

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

Что же делать. Вроде всё работает. В админку VestaCP заходит, сам nginx тоже отрабатывает без ошибок

sudo /etc/init.d/nginx restart
[sudo] password for user:
[[ ok  Restarting nginx (via systemctl): nginx.service.

но вот сайт работать отказывается.

Ну, интернет мне в помощь. А он мне говорит, что данная ошибка связана с SSL протоколом. SSL получила запись, длина которой превышает максимально допустимую величину. Тут я задумался, недавно настраивал nginx на получения статуса A+ на сайте ssllab. Ладно, лезу в настройке nginx. Открываю файл nginx.conf и выключаю stapling и add_header Strict-Transport-Security. Перезагружаю web сервер, а не тут то было. Ошибка все равно осталась. Посидев около часа на форумах набрёл на рекомендацию в добавлении записи ssl и http2 в конфигурационный файл сайта. Так, лезу и добавляю запись:

listen 11.11.11.11:443 ssl http2

После рестарта web сервера сайт заработал в обычном режиме.

Ура!!! Ошибка исправлена.

[endtxt]

Netcraft недавно опубликовал исследование сайтов SSL/TLS, которые они отслеживают, и заметил, что только 5% из них правильно реализуют HTTP Strict Transport Security (HSTS). В этой статье описывается настройка NGINX и NGINX Plus для реализации политики HSTS.

Что такое HSTS?

HTTPS (HTTP, зашифрованный SSL или TLS) является неотъемлемой частью мер по обеспечению безопасности трафика на веб-сайт, что делает его очень трудным для злоумышленника, чтобы перехватить, изменить или поддельный трафик между Пользователем и веб-сайта.

Когда пользователь вводит веб-домен вручную (предоставляя имя домена без префикса http:// или https://) или следует простой ссылке http://, первый запрос на веб-сайт отправляется незашифрованным, используя простой HTTP. Большинство защищенных веб‑сайтов немедленно отправляют перенаправление для обновления пользователя до HTTPS‑соединения, но хорошо расположенный злоумышленник может смонтировать атаку “человек в середине” (MITM) для перехвата первоначального HTTP‑запроса и может контролировать сеанс пользователя с этого момента.

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

Как работает HSTS?

Политика HSTS публикуется путем отправки следующего заголовка ответа HTTP с защищенных (HTTPS) веб-сайтов:

Strict-Transport-Security: max-age=31536000

Когда браузер видит этот заголовок с веб-сайта HTTPS, он “узнает”, что этот домен должен быть доступен только с помощью HTTPS (SSL или TLS). Он кэширует эту информацию на максимальный период (обычно 31536000 секунд – это примерно 1 год).

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

Strict-Transport-Security: max-age=31536000; includeSubDomains

Например, ответ HTML для https://www.example.com может включать запрос к ресурсу от https://example.com, чтобы убедиться, что HSTS установлен для всех поддоменов example.com

Настройка HSTS в NGINX и NGINX Plus

Настройка заголовка ответа Strict Transport Security (STS) в NGINX и NGINX Plus относительно проста. Добавте параметр в конфигурационный файл nginx.conf:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Параметр always гарантирует, что заголовок задан для всех ответов, включая ответы на внутренние ошибки. Более старые версии NGINX (до версии 1.7.5 или NGINX Plus R5) не поддерживают параметр always и не устанавливают заголовок для внутренних ответов об ошибках.

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

Блоки конфигурации NGINX наследуют директивы add_header от своих вложенных блоков, поэтому вам просто нужно поместить директиву add_header в серверный блок верхнего уровня. Существует одно важное исключение: если блок включает в себя директиву add_header, он не наследует заголовки от вложенных блоков, и вам нужно повторно объявить все директивы add_header:

server {     
    listen 443 ssl;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;     
# This 'location' block inherits the STS header     
    location / {         
        root /usr/share/nginx/html;     
    }     
# Because this 'location' block contains another 'add_header' directive,     
# we must redeclare the STS header     
    location /servlet {         
        add_header X-Served-By "My Servlet Handler";         
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;         
        proxy_pass http://localhost:8080;     
    } 
}

Тестируйте HTTP Strict Transport Security с осторожностью

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

Очень сложно отказаться от политики HSTS, чтобы удалить HTTPS-версию веб-сайта или службы. Когда вы тестируете HSTS, используйте очень короткий максимальный тайм-аут и убедитесь, что вам комфортно с эффектами и обязательством поддерживать HTTPS-версию вашего сайта. Когда вы впервые начнете жить с вашей политикой HSTS, держите max-age маленьким и увеличивайте его только тогда, когда вы уверены в этом.

Должен ли каждый ответ HTTPS иметь заголовок STS?

Цель состоит в том, чтобы представить политику HSTS пользователям как можно скорее, когда они начинают сеанс HTTPS. Если они не получают политику HSTS во время сеанса, они останутся уязвимыми для будущих атак захвата HTTP.

Браузер должен наблюдать за заголовком STS только один раз, поэтому нет необходимости добавлять его в каждый блок местоположения и каждый ответ. Однако добавление его только на домашнюю страницу или страницу входа в систему, вероятно, недостаточно, и если вы добавите заголовок только к кэшируемым ответам, клиент может не увидеть его. Убедитесь, что вы покрываете как можно больше своего URL‑пространства, уделяя особое внимание динамическому (не кэшируемому) контенту.

Запуск HTTP и HTTPS версий веб-сайта бок-о-бок

Некоторые сайты запускают HTTP и HTTPS версии веб-сайта на одном сервере NGINX или NGINX Plus, чтобы сделать его содержимое доступным по любому протоколу:

server {     
    listen  80;     
    listen  443 ssl http2;     
# ... 
}

Это не подходит при использовании HSTS, поэтому в файле конфигурации WEB домена прописываем редирект на протакол HTTPS:

server {     
    listen 80 default_server;     
    listen [::]:80 default_server;     
    server_name _;     
    return 301 https://$host;    
# Либо 
  # return 301 https://$host$request_uri; 
} 
server {     
    listen 443 ssl http2;     
    server_name www.example.com;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; 
}

Укрепление HSTS

Клиент защищен от перехвата HTTP после того, как он увидел заголовок STS для соответствующего домена в течение объявленного периода максимального возраста.

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

• Никогда раньше не посещал сайт
• Недавно переустановил свою операционную систему
• Недавно переустановил свой браузер
• Перешел на новый браузер
• Перешли на новое устройство (например, мобильный телефон)
• Удалил кэш браузера
• Не посещал сайт в последнее время, и время max-age прошло

Чтобы решить эту проблему, Google поддерживает “список предварительной загрузки HSTS” веб-доменов и поддоменов, которые используют HSTS и представили свои имена https://hstspreload.appspot.com/. Этот список доменов распространяется и жестко закодирован в основных веб-браузерах. Клиенты, обращающиеся к веб-доменам в этом списке, автоматически используют HTTPS и отказываются обращаться к сайту по протоколу HTTP.

Имейте в виду, что после установки заголовка STS или отправки доменов в список предварительной загрузки HSTS удалить его невозможно. Это одностороннее решение сделать ваши домены доступными через HTTPS.

Если вы планируете добавить заголовок STS в конфигурацию NGINX, сейчас также самое время рассмотреть возможность использования других HTTP‑заголовков, ориентированных на безопасность, таких как X-Frame-Options и X-XSS-Protection.

NGINX Plus имеет дополнительные функции для защиты вашего сайта от угроз безопасности и других проблем, таких как распределенные атаки типа “отказ в обслуживании” (DDoS).

[endtxt]

RSS

Распределенная атака типа “отказ в обслуживании” (DDoS) представляет собой попытку сделать службу, обычно веб‑сайт, недоступным путем бомбардировки его таким количеством трафика с нескольких машин, что сервер, предоставляющий службу, больше не может функционировать правильно из‑за исчерпания ресурсов.

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

Использование NGINX для борьбы с DDoS-атаками

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

Защита архитектуры NGINX по событиям

NGINX сконструирован так, чтобы он мог быть “амортизатором при ударе” DDOS на ваш сервер.

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

Ограничение скорости запросов в nginx

Можно ограничить скорость, с которой NGINX принимает входящие запросы, значением, типичным для реальных пользователей. Например: реальный пользователь, обращающийся к странице входа, может делать запрос только каждые 2 секунды. Исходя из этого настроим NGINX так, чтобы разрешить одному IP-адресу клиента пытаться войти в систему только каждые 2 секунды (эквивалентно 30 запросам в минуту):

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
# ... 
     location /login.html {
         limit_req zone=one;
     }
}

• limit_req_zone – Директива настраивает вызываемую зону общей памяти для хранения состояния запросов для указанного ключа, в данном случае IP-адреса клиента ( $binary_remote_addr).
• limit_req – Директива в location блоке для /login.html ссылается на зону общей памяти.

Ограничение количества соединений

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

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {     
# ...     
    location /store/ {         
        limit_conn addr 10;        
    } 
}

• limit_conn_zone– Директива настраивает зону общей памяти с именем addr для хранения запросов на указанный ключ, в этом случае (как и в предыдущем примере) IP-адрес клиента,$binary_remote_addr. 
• limit_conn– Директива в locationблоке for /store ссылается на зону общей памяти и устанавливает максимум 10 соединений от каждого IP-адреса клиента.

Закрытие Медленных Соединений

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

client_header_timeout           30s;
client_body_timeout             30s;

По умолчанию данный параметр равен 60 секундам

[endtxt]

Сегодня разберем как можно изменить шаблоны VestaCP у Web сервера Nginx для получения рейтинга A+.

Лучше всего отредактировать /usr/local/vesta/data/templates/web/nginx/default.stpl тем более, что VestaCP перезапишет сделанные вручную в конфигурационном файле изменения.

sudo nano /usr/local/vesta/data/templates/web/nginx/default.stpl

Поддержка SSl и HTTP2

Добавляем следующие два фрагмента:

После %ip%:%proxy_ssl_port% в той же строке:

ssl http2

Также открываем на редактирование файл основной конфигурации nginx:

sudo nano /etc/nginx/nginx.conf

С марта 2020 года все популярные браузеры отключают поддержку TLS 1.0 и TLS 1.1, поэтому в примере приведу два варианта конфигурации.

Находим секцию #SSL PCI Compliance и редактируем в соответствии с моим листингом:

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
 ssl_stapling on;
## ##Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

Также нужно сгенерировать dhparams.pem и положить в нужную папку:

sudo openssl dhparam -out /home/admin/conf/web/dhparams.pem 4096

Вывод

Сегодня научились редактировать конфигурационный файл Web сервера Nginx в админ-панели VestaCP.

Также приведу пример полного конфигурационного файла для VestaCP и секцию SSL для Nginx:

Пример файла default.stpl

server {

listen %ip%:%proxy_ssl_port% ssl http2;
server_name %domain_idn% %alias_idn%;
ssl_certificate %ssl_pem%;
ssl_certificate_key %ssl_key%;
error_log /var/log/%web_system%/domains/%domain%.error.log error;
location / {     
      proxy_pass  https://%ip%:%web_ssl_port%;
      location ~* ^.+.(%proxy_extentions%)$ 
      {
          root %sdocroot%;
          access_log /var/log/%web_system%/domains/%domain%.log combined;
          access_log /var/log/%web_system%/domains/%domain%.bytes bytes;
          expires max;
          try_files $uri @fallback;
      }
}
location /error/ {
     alias %home%/%user%/web/%domain%/document_errors/;
}
location @fallback {
     proxy_pass https://%ip%:%web_ssl_port%;
}
location ~ /.ht {return 404;}
location ~ /.svn/ {return 404;}
location ~ /.git/ {return 404;}
location ~ /.hg/ {return 404;}
location ~ /.bzr/ {return 404;}
include %home%/%user%/conf/web/snginx.%domain%.conf*;

Пример файла nginx.conf

Привожу кусок файла nginx.conf непосредственно секцию SSL PCI Compliance

Включим параметр HSTS, OCSP, dhparam, а также поддержу TLSv1.2 и TLSv.1.3 и алгоритмы шифрования:

### SSL PCI Compliance ###
 ssl_session_cache   shared:SSL:10m;
 ssl_prefer_server_ciphers on;
 ssl_stapling on;
## ## Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

После внесения данных изменений на сайте ssllab проверка будет показывать рейтинг A+ для ваших сайтов.

[endtxt]