Это личный опыт, который звучит как паранойя, но для меня - скорее гигиена. Можно считать пошаговой инструкцией. Я пользуюсь Mikrotik, но часть пунктов применима и к устройствам других производителей, да и не только к роутерам.
Сбрасываю к заводским настройкам
Зачем: устройство из магазина могли вернуть, а предыдущий пользователь мог наломать дров, которые не бросаются в глаза. При покупке устройства с рук - вероятность такой ситуации повышается на порядки. Хорошо если продавец наломал дрова по глупости, но он мог и изначально иметь недобрые намерения.
Альтернатива: если устройство это поддерживает и вы опытны в администрировании Linux, можно перепрошить его на OpenWRT.
Провожу аудит конфигурации
- Текущие настройки экспортируется в текстовый формат.
- Копирую конфиг к себе в Git-репозиторий в качестве начального коммита, дальнейшие изменения (см. пункты 3 и 4) попадают туда же. Изменение легитимное - документирую в commit message, нет - отменяю настройку на роутере. Изменения вносятся в интерактивном режиме, с ревью, через git add -p. Внимательно изучаю параметры сверху вниз, удаляю то, что кажется подозрительным (чуть подробнее ниже - в разделе "минимизирую поверхность атаки").
- Добавляю недостающее. Я стараюсь придерживаться правила - нельзя ничего, кроме того, что разрешено явно, а разрешаю минимум и точечно.
- Ставлю тег версии на последний коммит. Последняя тегированная версия резервной копии служит эталоном.
Зачем:
- Возможность откатиться и легко посмотреть что изменилось, хоть через полгода, не отсматривая весь конфиг, который может быть большим.
- Производитель может жертвовать безопасностью в угоду удобству пользователя.
- Процесс аудита подразумевает понимание того, что настроено работает на роутере. Понимание ценно само по себе.
Меняю пароли
- Учётная запись администратора. Если есть возможность - меняю и логин. В Mikrotik сменить логин нельзя, только удалить. Не удаляйте стандартную учётку, не создав и проверив (!) работу нового пользователя в группе full!
- Пароли Wi-Fi сетей.
- Отключаю гостевые профили и сети.
Минимизирую поверхность атаки
Выключаю неиспользуемые сервисы
- WinBox - субъективно, не вошло в привычку. Вроде уже под Linux запускается, раньше были проблемы с Wine.
- Telnet (нет шифрования)
- FTP-сервер (не использую)
- API и API-SSL (не использую)
Зачем: мне они ни к чему, а рисков полно. Для администрирования мне хватает веб-интерфейса + SSH.
Отключаю "лишние" физические интерфейсы
- На одном из портов настраиваю статическую адресацию в отдельной подсети с маской /30 и явно разрешаю управление (доступ к админке) на нём. Это будущий резервный канал для подключения к роутеру с ноутбука, если накосячу во время настройки или проводя эксперименты.
- Отключаю неиспользуемые Ethernet-порты.
- Если не использую, то отключаю частоту Wi-Fi 2.4GHz.
Зачем: первые два пункта - security by obscurity, третий - минимизация поверхности атаки. Wi-Fi сложный протокол, в нём могут быть дыры. В теории, снижается энергопотребление устройства.
Ограничиваю доступ к управлению
В настройках файрвола и на уровне админки, если это возможно, разрешаю подключение к админке и по SSH только с двух IP: основного, с моего ПК и резервной подсети. Дополнительно устанавливаю ограничение по IP-адресу на уровне самого пользователя:
/user set admin address=1.2.3.4/32,5.4.3.2/32
Здесь важный нюанс - не забывайте про резервное подключение через порт из раздела выше.
Примечание: создайте запасного юзера на время настройки и отладки, предварительно проверив его работу.
Зачем ограничения в нескольких местах? Многоуровневая безопасность. Чем раньше будет срезан злоумышленник - тем лучше. В идеале его пакеты не должны доходить до роутера. Сломается файрвол - подстрахует приложение.
Настраиваю шифрование
У меня дома есть удостоверяющий центр. Я стараюсь даже внутри дома шифровать трафик, поэтому генерирую и настраиваю использование TLS-сертификата для веб-интерфейса админки. HTTP-доступ я отключаю, оставляю только HTTPS. УЦ - самопальный, на bash + openssl, поэтому публиковать инструкции к нему нет смысла.
Зачем: даже если мой трафик перехватят - его скорее всего не расшифруют. Часть инструментов взлома столкнётся с неизвестным издателем сертификата и обломается на этом.
Примечание: чтобы это работало - нужно обеспечивать безопасность процесса управления ключами шифрования:
- приватный ключ корневого сертификата должен храниться надёжно и далеко;
- это должен быть именно УЦ с внятными механизмами распространения публичных ключей для конечных устройств пользователей, а не исключение в правилах браузера для домена, которое приведёт к игнорированию самоподписного SSL-сертификата, то есть корневые сертификаты этого УЦ должны быть установлены на все устройства дома.
Финальная проверка
Я пользуюсь "белым" IP-адресом. Поэтому запускаю два Nmap-сканирования:
- Из локальной сети — проверяю отсутствие открытых портов, кроме необходимых.
- Через внешний хост, например, VPS — убеждаюсь, что роутер не виден из интернета.
Итоги
Описанные действия требуют времени, но сокращают риски взлома и неисправимой самостоятельной поломки на порядок.
Ключевые принципы:
- Все изменения документируются и версионируются (использование Git для конфига).
- Не верим никому, даже себе (просматриваем вносимые в конфигурацию изменения перед тем, как коммитить; перепроверяем nmap'ом за собой).
- Каждая настройка понятна администратору (полный аудит, удаление лишнего).