MikroTik — Автоматически меняем MAC адрес на рандомный

Очередной приступ паранойи застал врасплох. Мысль о том что MAC-адрес беспощадно палит привязку твоих сессий в логах провайдера не давала покоя и надо было с этим что то делать.

Позвонив товарищу, который поинтересовался у инженеров провайдера (одного из представителей «Большой тройки») соображениями о том, просто ли получить информацию о сессиях абонента, имея на руках MAC-адрес. Ответ был очевиден — «Да как два пальца..». Нет, часто меняя MAC-и, разумеется, полной анонимности не добьешься, но некоторые затруднения это всё-таки вызовет.

Было решено, надо каким-то образом менять MAC адрес WAN-порта на рандомный, да с заданным интервалом. Имея на руках всё тот же MikroTik, всё решается с помощью одного лишь скрипта.

Подробнее под катом

MikroTik — режем рекламу (ADBlock) с помощью DNS

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

Прочитав пост тов. 4aba о том, как с помощью dnsmasq на прошитом роутере можно вполне успешно резать рекламные баннеры на всех устройствах, которые подключены к нашей точке доступа возник резонный вопрос — а можно ли реализовать аналогичное на маршрутизаторе Mikrotik hAP lite? Железка довольно таки достойная (650MHz @ RAM 32 Mb), но у нас нет полноценного linux-шелла на ней. Оказывается — можно, и результате было реализовано довольно простое, но эффективное решение.

Пришлось пойти немного другим путем, а именно — прописать статичные DNS маршруты, которые при запросе «рекламного домена» переадресовывали наш запрос на 127.0.0.1.

Списки «рекламных доменов» мы возьмем из открытых источников, таких как http://pgl.yoyo.org/adservers/ и https://adaway.org/hosts.txt (с легкостью можно изменить на любые другие), приведем их в подобающий вид и оформим в виде скрипта для нашего Mikrotik-а, чтоб с помощью одной команды все их ему и «скормить».
Подробнее под катом

MikroTik — автоматически выключаем и включаем WiFi в заданное время

Маршрутизатор от Mikrotik, должен признать — интересный зверь. То, что в «домашних роутерах» поставляется прямо из коробки — здесь в ряде случаев приходится доделывать ручками. Зато имеется огромный функционал в плане «настраивается всё что хочешь».

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

  1. Написать скрипт, который будет проверять текущее время, и в соответствии с ним выполнять требуемое действие;
  2. Убедиться, что он корректно работает;
  3. Добавить задание, которое будет выполнять этот скрипт с заданным промежутком времени;

Подробнее под катом

Прошивка роутера Asus RT-G32 ver. C1

При прошивки данной железки возникают некоторые вопросы, ответы на которые найти порой не так просто. Сейчас постараюсь ответить на основные:

  1. Можно ли установить на него dd-wrt или open-wrt?
    Нет, не заведется, к сожалению
  2. Можно ли установить wive-ng?
    Да, но «глючит» на столько, что работать с железкой в итоге не представляется возможным
  3. Можно ли после экспериментов «откатиться» на официальную версию?
    Да, и это делается очень просто

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

  • Для того, чтоб выполнять манипуляции с прошивкой роутера необходимо его запустить в Recovery mode. Для этого:
    1. Вынимаем штекер питания роутера
    2. Нажимаем и удерживаем клавишу Reset роутера
    3. Вставляем штекер питания роутера, продолжая удерживать нажатой клавишу Reset
    4. Когда диод WPS начнет медленно мигать (через ~5 секунд) — отпускаем клавишу Reset

    Последующее простое выключение/включение роутера заставит его запуститься в стандартном режиме

  • Для прошивки роутера лучше всего его подключать патч-кордом напрямую к сетевой карте машины с которой будет производиться его прошивка. Оставлять включенным только одно сетевое подключение, всё лишнее — выключать
  • IP адрес выставлять 192.168.1.2 и только. Маска подсети 255.255.255.0. Использование любого другого адреса приводит к тому, что железка не обнаруживается и не прошивается
  • То что 192.168.1.1 (роутер) в Recovery mode не пингуется — нормально, не стоит переживать
  • Для прошивки можно использовать как tftpd, так и утилиту от Asus Firmware Restoration. Вторая проще, и выполняет по видимому всё тот же tftp put %файл%

Подробнее под катом

Маленькая хитрость iptables

При сканировании портов целевой системы можно довольно часто наблюдать результат вида:

...
8080/tcp  filtered http-proxy
...

Что говорит нам о том что порт наверняка используется системой, но «прикрыт» извне. Не смотря на то что работать с ним врятли будет возможно — он всё же дает исследуемому дополнительную информацию о исследуемой системе.

Как проще всего прикрыть порт извне используя iptables?

$ iptables -A INPUT -p tcp --dport %номер_порта% -j DROP

А как можно прикрыть его так, чтоб он был недоступен только лишь извне, да ещё и не отображался в результатах nmap как filtered?

$ iptables -A INPUT ! -s 127.0.0.1/8 -p tcp --dport %номер_порта% -j REJECT --reject-with tcp-reset

Если по-человечески, то это означает:
Для всех входящих пакетов (кроме локального хоста (127.0.0.1/8)), приходящих по протоколу tcp на порт %номер_порта% ответить ICMP уведомлением tcp-reset, после чего пакет будет «сброшен»

Так же возможны варианты ICMP ответа: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited и icmp-host-prohibited

После чего не забудьте выполнить:

$ service iptables save; service iptables restart

Для выполнения $ service iptables save в системе должен присутствовать пакет iptables-services

Если в системе работает fail2ban обязательно перед выполнением $ service iptables save остановите его, выполнив $ service fail2ban stop

SSH Honeypot — просто и со вкусом

Honeypot («Ловушка») (англ. горшочек с мёдом) — ресурс, представляющий собой приманку для злоумышленников. (wikipedia.org)

Одно из первых средств, которое применяется для аудита целевых систем — это сканирование портов с целью выявления, какие же службы (сервисы) там крутятся. Можете даже сейчас натравить nmap на свой сервер и посмотреть, что же он нам о нем расскажет. Самый простой пример результата его работы:

$ nmap google.com

Starting Nmap 6.47 ( http://nmap.org ) at 2050-01-11 00:00 GMT
Nmap scan report for google.com (173.194.71.138)
Host is up (0.010s latency).
Other addresses for google.com (not scanned): 173.194.71.139 173.194.71.113 173.194.71.101 173.194.71.100 173.194.71.102
rDNS record for 173.194.71.138: lb-in-f138.1e100.net
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.92 seconds

Из которого мы видим, что на целевой системе открыты 2 порта (стелс-сканирование и прочее мы пока опустим — не к чему оно сейчас): 80/tcp и 443/tcp и это означает, что там наверняка крутится web-сервер, который работает по http и https.

Теперь подойдем к более интересному моменту.

Довольно часто администраторы используют для доступа к своим серверам SSH. Стандартный порт для SSH — 22/tcp. Если администратор хоть чуть-чуть «шарит», то после установки системы он сразу же перевешивает SSH на не стандартный порт (например 454545), запрещает логин от рута и настраивает авторизацию по сертификату вместо пароля. И оно совершенно правильно — держать SSH на стандартном порту, да без какой-либо дополнительной защиты — потенциально огромная брешь в безопасности.

А что если повесить на этот самый 22 порт ещё один ssh-демон, но при этом все попытки логина по нему сразу отправлять в fail2ban? Обычным нашим пользователям SSH не нужен, мы ходим через порт 454545, значит тот, кто будет ломиться на 22 порт — бот или злоумышленник, которого необходимо забанить по IP на довольно длительное время. Обойти это ограничение можно будет лишь заюзав VPN, прокси или другое средство смены IP, ну или дождаться пока не пройдет время бана которое мы установим.

Данную задачу будем решать в 3 этапа:

  1. Настроим и запустим дополнительный sshd-демон, который будет висеть на 22 порту;
  2. Настроим fail2ban, который будет читать логи на попытку коннекта по ssh на 22 порту;
  3. Поставим всё это дело в автозапуск;

Все манипуляции буду производить на CentOS 7, разница с другими дистрибутивами — минимальна

Подробнее под катом

Тотальная защита WordPress

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

Помогать нам будет уже не только nginx — но и fail2ban вкупе с некоторыми дополнениями и настройками самого WP.

Обозначим проблемы безопасности, которые «по умолчанию» имеют место быть:

  1. WordPress вставляет данные о своей версии в различные места генерируемого контента;
  2. Стандартные настройки его имеют довольно много потенциально слабых мест;
  3. Стандартные настройки доступа к сайту позволяют без особых трудностей собрать потенциальному взломщику довольно много информации;
  4. «Из коробки» отсутствуют какие-либо средства против перебора директорий и паролей.

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

Подробнее под катом