Авторизация с помощью htaccess (базовая аутентификация)

ImageCache и защита от хотлинка через .htaccess

Для ImageCache предыдущий пункт работать не будет, поэтому добавляем такие настройки:

SetEnvIfNoCase Referer «^$» local_ref=1
# Allowed domains
# Далее разрешенные домены
SetEnvIfNoCase Referer «^http://(www\.)?domain\.ru» local_ref=1
SetEnvIfNoCase Referer «^http://(www\.)?domain\.com» local_ref=1
# File extensions that you want to protect
# Расширения файлов, которые нужно защитить
<FilesMatch «\.(bmp|jpe?g|gif|png)»>
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

Теперь и защита от хотлинка и модуль ImageCache работают превосходно. Одно «но» — таким способом, как вы видите не получится выдавать другую картинку; только защита изображений, что является основной целью.

Правила Redirect, RewriteRule и RewriteCond

1.1. Директива Redirect

Синтаксис Redirect:

Redirect  /откуда http://куда_полный_адрес

Redirect устанавливает прямой редирект с одной страницы на другую.

В пишут код редиректа. Является необязательным параметром. Чаще всего пишут 301, что сигнализирует о постоянном смене адреса страницы.

Например

Redirect 301 /oldpage.php http://site/newpage.php

Можно также писать по другому

RedirectPermanent 301 /oldpage.php http://site/newpage.php
или
Redirect permanent 301 /oldpage.php http://site/newpage.php

1.2. Директива RewriteRule

Директива RewriteRule устанавливает правила перехода. Синтаксис следующий:

RewriteRule Шаблон Подстановка

При внешнем редиректе меняется урл адреса в строке браузера — «»
При внутреннем — не меняет урл адреса в строке браузера — «» или «»

1.3. Директива RewriteCond

Директива RewriteCond определяет условия при котором выполняется правила в RewriteRule.

RewriteCond Сравниваемая_Строка Условие

Например, этими условиями могут быть браузер пользователя, IP-адрес, заголовок и т.д.

1.4. Директива RedirectMatch

Директива RedirectMatch аналогична Redirect с той лишь разницей, что позволяет записывать регулярные выражения.

RedirectMatch  Откуда Куда

Управление списками директорий

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

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

Аргументы со знаками и/или нельзя смешивать, подобная конструкция считается некорректным синтаксисом в Apache HTTP и может быть отклонена при запуске.

Добавление оператора отключает индексирование контента внутри пути (read listed) автоматически, если файл отсутствует, и запрещает отображение, если URL видит эту директорию. Также подобная практика будет применяться при использовании конфигураций виртуального хоста, например, хоста, используемого согласно предварительным требованиям для размещения сертификата Let’s Encrypt.

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

Запустите следующую команду для получения строки для редактирования в файле конфигурации:

Результат будет выглядеть примерно так:

Запустите следующую команду для прямого доступа к строке для редактирования:

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

/usr/local/etc/apache24/httpd.conf

Сохраните и закройте файл, введя и нажав .

Перезапустите Apache HTTP для вступления изменений в силу:

В браузере при попытке входа на домен вы увидите сообщение о запрете доступа (ошибку 403). Это результат внесенных вами изменений. Добавление в директиву позволило отключить автоматическое индексирование Apache HTTP, в результате чего файл по указанному пути отсутствует.

Вы можете решить эту проблему, разместив файл внутри виртуального хоста (), который вы активировали согласно для использования сертификата Let’s Encrypt. Вам нужно будет воспользоваться блоком по умолчанию внутри Apache HTTP и разместить его в той же папке, что и , объявленный в виртуальном хосте.

/usr/local/etc/apache24/extra/httpd-vhosts.conf

Для этого используйте следующую команду:

Теперь вы должны увидеть сообщение It works! при посещении вашего домена.

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

Где применяется

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

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

Также, этот способ защитит от подбора пароля в основную админку путём двойной авторизации. Пока не будет пройдена первая авторизация со стороны сервера, к второй путник просто не будет допущен. Это будет отличной защитой для админки Вордпресса в папке WP-admin.

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

Вариантов на самом деле много: от доступа в платную зону и скачивания файлов оттуда до распределения зон пользования разными сотрудниками.

Защита партнерских ссылок с помощью mod_rewrite

Текст данного урока поведает Вам о том, как защитить свои партнерские ссылки от жадных пользователей, которые специально обрезают Ваши партнерские коды
Не секрет, что многие интернет предприниматели львиную долю своих доходов получают с разных партнерских програм. Но иногда бывает так, что посетители сайта специально копирует УРЛ в адресную строку и обрезают партнерский код, тем самым лишая предпринимателей потенциального заработка. Зачем они это делают? У меня, к сожалению, нет ответа на этот вопрос Все равно цена для них от этого не изменится.
Хочу откровенно признаться, что сам так иногда делал
Давайте научимся защищать подобные ссылки и зарабатывать на каждом посетителе.
Надпись на рисунке: «Это не партнерская ссылка…»
Лучшим способом для этого является .htaccess и mod_rewrite.
От Вас требуется только создать в корневой папке файл .htaccess и внести туда следующий код:

Как создать файл .htaccess

Как уже говорилось, конфигурационные файлы имеют текстовый формат, и создать .htaccess также можно с помощью текстового редактора (например, Блокнота или NotePad++ в Windows).

Имя файла — .htaccess (с точкой в начале);

тип — «Все файлы»;

формат переноса по словам;

режим ASCII (при загрузке .htaccess на хостинг по FTP-протоколу).

Apache — регистрозависимый веб-сервер, поэтому важно написать название маленькими буквами: .HTaccess и .htaccess — это разные файлы. В Mac ОS файлы, начинающиеся с точки, невидимы

Поэтому вы можете назвать его иначе и после, переместив по FTP на хостинг, переименовать. Обычно размещают файл в корневой директории веб-сервера (/public_html) либо в корневой директории сайта (/public_html/site.com/)

В Mac ОS файлы, начинающиеся с точки, невидимы. Поэтому вы можете назвать его иначе и после, переместив по FTP на хостинг, переименовать. Обычно размещают файл в корневой директории веб-сервера (/public_html) либо в корневой директории сайта (/public_html/site.com/).

Как узнать полный путь от корня сервера

Это можно сделать тремя способами:

У поддержки хостинга;
С помощью глобальной функции phpinfo ();
Угадать. И это не шутка! В большом количестве случаев на обычном хостинге путь будет иметь вид: /home/users/p/login/domains/site.ru/wp-admin/, где login — это имя пользователя хостинга, а вторая выделенная цветом часть — просто путь на самом сайте с его доменом в начале без всяких http и https.

Но всё же надёжнее всего узнать через функцию phpinfo. Создаём любой файл в нужной нам папке на сервере, главное, чтобы расширение файла было .php . Например: siteinfo.php . Его опять же можно создать с помощью любого текстового редактора, Notepad++ я рекомендую всегда!

В этот файл пишем всего одну строчку:

Если возникла сложность с созданием столь простого скриптика или просто лень, то можете скачать его по этой ссылке.

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

В ней в поддаблице Apache Environment находим строку SCRIPT_FILENAME (лучше воспользоваться поиском в браузере путём одновременного нажатия клавиш CTRL+F) и ввода в открывшееся в правом верхнем углу окно поиска скопированную комбинацию: SCRIPT_FILENAME).

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

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

Но как же так, мы же его не указали ни имя пользователя, ни пароль…

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

Защита административной панели

Заключительной рекомендацией является защита административной панели веб-сайта, ведь она является одним из слабых мест в общей системе из-за обширного функционала, связанного с добавлением/редактированием постов и страниц, работой с файлами и многим другим. Поэтому важным условием является обеспечить надлежащий контроль доступа, а также максимальную скрытность от злоумышленников местонахождения административной панели, реализуемую простым переносом адреса на нестандартный и максимальной защитой данной точки входа посредством защиты от перебора, фильтрации по IP-адресам и т.д. При создании системы контроля доступа следует придерживаться следующих принципов: отправка всех запросов через систему контроля доступа; запрет доступа по умолчанию (т.е. отклонять запрос, если он не был разрешен специально); минимальные привилегии для всех пользователей, программ или процессов; отказ от использования ролевой модели управления доступом, жёстко заданной в коде; регистрация всех событий, связанных с контролем доступа.

Бэкап баз 1С

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

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

Доступ к ней максимально ограничен. Она сама забирает все бэкапы к себе. С windows машины к ней доступа нет. Сделано это для простейшей защиты от шифровальщиков. Если какой-то вирус попадет на сервер и зашифрует базы 1С, я очень быстро смогу их восстановить из архивных копий, которые хранятся на этом же гипервизоре, только в другой виртуальной машине.

На windows сервере можно просто расшарить директорию с базами 1С, а на виртуалке для бэкапов подключить ее. Я обычно использую Linux систему для этого. В ней монтирую шару по smb. Как это сделать рассказываю в отдельной статье — Как быстро подмонтировать сетевой диск в Linux. После того, как подключили папку с базами 1С к бэкап серверу, можете делать с ними все, что угодно. Например, куда-то копировать с помощью rsync и сохранять изменившиеся базы. Подробно схему бэкапов с помощью rsync описываю тоже отдельно — настройка rsync для бэкапа. Обязательно одну копию держу локально на сервере с бэкапами, вторую отправляю куда-то в удаленный приемник. После этого шару отмонтирую. Она подключена только для копирования баз с windows машины на linux.

Так же для бэкапов вы можете использовать какое-нибудь S3 хранилище, например у того же Selectel. По моим недавним сравнениям по ценам там наиболее выгодные условия из известных хостеров. По крайней мере я дешевле не нашел. Заливать бэкапы в S3 можно с помощью утилиты rclone. У Selectel еще очень удобно сделано в плане настройки времени хранения данных в контейнерах. Я обычно создаю 3 разных контейнера:

Day — в него заливаются архивы каждый день. Срок хранения файлов в этом контейнере — 7 дней. Настраивается это штатно в панели управления. На стороне хоста, с которого заливаются данные, ничего делать не надо.
Week — архивы заливаются раз в неделю и хранятся 31 день.
Month — архивы заливаются раз в месяц и хранятся условно бесконечно.

Таким образом мы просто каждый день льем файлы в S3 в разные контейнеры, а там они автоматом ротируются. Мы всегда имеем 7 последних копий, 4 недельные и помесячные. Удобная схема и не очень дорогая. Стоимость хранения можете сами прикинуть по калькулятору хранилища.

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

Кому нужен запрет доступа и как им пользоваться

Стоит учитывать, что файл htaccess позволяет не только делать запрет доступа сразу ко всему сайту, но и создавать белые и черные списки пользователей. То есть вы сможете, к примеру, закрыть доступ для некоторых IP. Точно так же вы сможете снять запрет только для выбранных вами IP, создав тем самым белый список пользователей. Но зачем вообще использовать эту функцию?

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

Создаём файлы

Нам нужно создать всего два файла и поместить их в ту директорию, которую мы хотим защитить. В случае с ограничением доступа в админку Вордпресса, нужно добавить их в папку WP-ADMIN на сервере, в случае защиты всего сайта (домена) кладём в корневую директорию.

Итак, открываем любой текстовый редактор, например, Notepad++ и создаём пока два пустых файла: .htaccess и .htpasswd . Точки в начале обязательны. Таким образом, это текстовые файлы без имени, но с разными расширениями.

В .htaccess вставляем вот такой текст:

Всего 4 строчки. Нам интересна только третья. После AuthUserFile нужно вставить полный путь до защищаемой папки, в которой будет лежать файл .htpasswd. Впрочем, он может лежать и в любом другом месте на сайте, тогда указываем полный путь от корня сервера к нему.

Безопасность сторонних модулей

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

SQL-инъекции и XSS-атаки

Рекомендация, относящаяся к обеспечению защиты от SQL-инъекций и XSS-атак, требует самого подробного объяснения, ведь целью злоумышленников здесь являются конкретные данные из базы данных (SQL-инъекция) и пользовательские данные (XSS-атака). Стоит также понимать, что вопросы, связанные с SQL-инъекциями, затрагивают обширный раздел, посвящённый обеспечению безопасного доступа ко всем хранилищам данных, включая реляционные базы данных и базы данных NoSQL, и включают вопросы безопасности запросов (необходимо избегать нелегитимных входных данных в составе SQL-команд и наилучшим решением является использование параметризованных запросов, которые можно применять к конструкциям SQL/OQL и хранимым процедурам), конфигурации (необходимо убедиться в корректной настройке имеющихся средств обеспечения безопасности СУБД и платформы, на которой она установлена), аутентификации (должна выполняться по защищенному каналу) и соединений (в связи с существованием нескольких способов взаимодействия с базой данных (посредством службы или API), необходимо обеспечить безопасность соединений с помощью шифрования и аутентификации). Что касается межсайтового выполнения сценариев (XSS-атака), то в данном случае последствия средней степени тяжести могут нанести отражённая XSS или XSS на основе объектной модели документа (DOM), а к серьезным последствиям может привести межсайтовое выполнение хранимых сценариев с исполнением кода в браузере пользователя с целью кражи учётных данных, перехвата сессий или установки вредоносного программного обеспечения. Главной мерой защиты в данном случае является экранирование (добавление определённых комбинаций символов перед символами или строками для недопущения их некорректной интерпретации), кодирование данных (преобразование определённых символов в комбинации символов, которые не представляют опасности для интерпретатора) на стороне сервера и использование набора HTTP-заголовков, в частности, Set-Cookie с параметрами HttpOnly и Secure, а также X-XSS-Protection со значением 1. Общей мерой защиты, используемой для предотвращения внедрения SQL-кода и межсайтового выполнения сценариев, является проверка всех входных данных на соответствие синтаксической и семантической норме. Под синтаксической нормой следует понимать полное соответствие входных данных ожидаемой форме представления, а семантическая норма свидетельствует о том, что входные данные не выходят за пределы конкретного функционала.

Какие бывают проблемы с работой в 1С через браузер

В таком режиме у меня уже пару лет работают несколько серверов с 1С. Иногда возникают нюансы с доступом через браузер. Например, не настроить обмен между базами, не зная их локальных путей. Бухгалтера сами его не смогут настроить. Им нужно будет передать информацию по директориям с базами. Понятное дело, что и обновить платформу они сами не смогут, так как нужно будет обновлять и публикацию баз. Когда вы сами подключены через браузер, сделать это невозможно.

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

Еще один нюанс, связанный с обменом между базами. После обновления платформы на сервере, он перестает работать через браузер. Возникает ошибка доступа к COM объекту. Чтобы это исправить, надо выполнить на сервере регистрацию comcntr.dll примерно так.

regsvr32 "C:\Program Files\1cv8\8.3.18.1208\bin\comcntr.dll"

Сделать это надо в cmd с правами администратора. И повторять каждый раз при обновлении платформы, не забывая указать путь к новой версии файла.

С недавних пор я столкнулся с новой для меня ошибкой при подобной публикации баз с использованием nginx и proxy_pass. Раньше я использовал отличный от 80-го порт в apache. Но периодически стали проскакивать ссылки при работе с опубликованной базой 1с примерно такого вида — https://1c.site.ru:81/ в случае, если вы используете 81-й порт. Запросы извне по этой ссылке уходят в никуда и возникают ошибки. На стороне клиента они выглядят так:

Uncaught TypeError: Cannot read property ‘toUpperCase’ of undefined on https://……./mod_main_loader.js

Ошибка совершенно не гуглится, так что потратил много времени на ее решение. Помог режим отладки в chrome. Я просто проверил все запросы и нашел ошибочные с кривыми урлами. И так и сяк пытался их решить редиректами на веб серверах, но в итоге пришлось в apache переехать на 80-й порт и ошибка ушла.

Ну и еще одно отмечу. Иногда apache зависает или начинает сильно тупить. Обычно после долгого аптайма в несколько недель. Я подробно не разбирался в проблеме. Предпочел просто перезапускать его раз в сутки ночью. Для этого сделал обычный bat файл и настроил запуск через планировщик Windows.

@echo off
sc stop "Apache2.4"
timeout 90
sc start "Apache2.4"

Понятно, что это грубый костыль, но проблему решает. Ночью все равно с 1С никто не работает. Это история не про отказоустойчивость, резервирование и работу 7/24/365.

Заключение

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

Дополнительную информацию о ресурсах или методах повышения безопасности Apache можно найти по этим ссылкам:

Советы по обеспечению безопасности Apache HTTP
Руководство по безопасности для Mozilla
Рекомендации по результатам аудита Центра интернет-безопасности для Apache HTTP

Дополнительные инструменты для защиты Apache HTTP:

— полезный инструмент для смягчения последствий DoS-атак. Дополнительную информацию см. в статье Защита от DoS и DDoS с помощью mod_evasive в руководстве по работе с Apache.
— это программное обеспечение для предотвращения повторных попыток входа в систему несанкционированных пользователей. Дополнительную информацию см. в руководстве Защита сервера Apache с помощью Fail2Ban.
— это брандмауэр веб-приложения (или WAF), который предоставляет широкий диапазон возможностей на основе предварительно заданных правил, написанный SpyderLabs и участниками сообщества. Дополнительную информацию об этом инструменте см. в руководстве Настройка ModSecurity в Apache.