Доступ к IP-ограниченному серверу с динамического IP
Наши серверы (все CentOS) ограничены по IP, но часто я не в себе и застрял на динамическом IP-адресе. Используя виджет DynDNS, я установил этот динамический IP-адрес, чтобы он всегда синхронизировался с именем хоста DynDNS, но как мне сделать это для разрешения IP-адреса в hosts.allow. На данный момент я написал скрипт cron, который запускается каждые несколько минут и проверяет IP, назначенный этому имени хоста, и записывает динамический IP в hosts.allow, но я не слишком заинтересован в этом как решении. Есть ли более элегантный способ, которым я мог бы сделать это?
Благодарю.
7 ответов
Нижеприведенный скрипт будет пинговать ваш динамический адрес и захватывать только ip, а затем сравнивать с ip, сохраненным в last_ip.txt, если они отличаются, ip в hosts.allow будет удален и заменен новым ip, а также ip в last_ip.текст.
Затем вы можете установить этот код в вашем crontab так, чтобы он запускался каждые 5 минут или 10, или как вам угодно.
Это не так сложно и может решить вашу проблему...
#!/bin/bash
DYN_IP="www.google.com.br"
CMD=$(ping -c1 $DYN_IP | head -1 | awk -F' ' '{ print $3}' | sed 's/(\|)//g')
FILE="./last_ip.txt"
NEW_IP=$CMD
if [ -e $FILE ]; then
OLD_IP=$(cat $FILE)
else
OLD_IP="0"
fi
if [ $OLD_IP != $NEW_IP ]; then
echo $NEW_IP > last_ip.txt
sed -i "/^sshd: $OLD_IP/d" /etc/hosts.allow
echo "sshd: $NEW_IP" >> /etc/hosts.allow
echo "Allow ip changed to $NEW_IP"
fi
Я понимаю, что вы беспокоитесь о том, что третьи лица играют с открытым SSH-портом. Я решил это по-другому. На моем частном сервере SSH-порт открыт для всех, но за ним следит fail2ban, небольшой умный пакет, доступный для Debian (и, вероятно, для большинства других дистрибутивов). Как только кому-то не удается войти в систему после 3 попыток с того же IP-адреса, этот адрес блокируется в брандмауэре на несколько дней.
С тех пор, как я это установил, на моем сервере было тихо и спокойно. И я все еще могу войти (используя мой ключ от флешки) из любой точки мира.
Если вы единственный, кто входит на этот сервер, вы также можете сделать простой переадресацию портов в брандмауэре или запустить sshd на другом порту.
Мое текущее решение для этого - webknocking, где я сначала делаю запрос к специальной веб-странице (возможно, с моим пользователем / паролем), которая открывает ворота SSH для IP, с которого я запрашиваю. Вот как я ssh на некоторые из моих серверов с моего телефона. Это сводит дополнительное программное обеспечение к минимуму, чтобы я мог сесть за какой-нибудь компьютер кафе и через несколько секунд авторизовать его для стандартного доступа по ssh, но не позволяет злоумышленникам даже играть с моим портом ssh. Недостатком любого стучащего решения является дополнительная точка отказа. Моя сеть безопасности - это несколько жестко закодированных IP-адресов, которым разрешен доступ, и если что-то пойдет не так со скриптами стука или веб-сервером, который их обрабатывает, мне просто нужно использовать одну из других машин, которые имеют постоянный доступ, чтобы войти и исправить сломанный коробка.
В качестве альтернативы некоторые динамические системы IP имеют "ловушки" или "обратные вызовы", которые можно использовать для автоматического уведомления об изменениях IP-адресов. Это может быть по электронной почте или http-запрос, который можно использовать как "стук". В качестве альтернативы вы можете написать сценарий на локальном конце, чтобы при каждом запуске сетевых сценариев или изменении локального IP-адреса вы автоматически запускали какой-либо стук или триггер, который вызывает и обновляет динамический список IP-доступа.
Я бы подошел к этому с другой стороны. Вместо того, чтобы ваши серверы поддерживали список IP-адресов из белого списка, я бы настроил их все так, чтобы разрешить ssh только с "внутренних" IP-адресов. Затем настройте отдельный хост шлюза / посадочной панели, к которому вы можете подключиться через VPN. Теперь вы можете прыгнуть через это окно, чтобы безопасно добраться до остальных серверов.
Это ограничивает вашу поверхность атаки одним блоком вместо всех ваших блоков. Кроме того, многие / большинство VPN-решений позволяют повысить требования к безопасности для соединения, используя сертификаты, двухфакторную аутентификацию и другие вещи вместе с (или вместо) простыми паролями. В целом, это обеспечит вам большую безопасность, большую гибкость и намного лучшую ремонтопригодность.
Существует ряд доступных вариантов VPN (я сам большой поклонник OpenVPN), которые вы можете использовать для правильной настройки безопасной точки доступа для ваших устройств. Многие из них относительно просты в настройке, и для такой небольшой установки они требуют минимальных ресурсов.
Я бы предложил в качестве альтернативы стук портов, в качестве альтернативы арендуйте учетную запись ssh на стороннем сервере и SSH оттуда.
Мое решение — заблокировать весь ssh-доступ в hosts.deny с помощьюsshd: ALL
Чтобы разрешить доступ с серверов со специальным (динамическим) доменом, я создал скрипт, который превращает список разрешенных доменов в список с IP-адресами. Этот список IP-адресов включается в файл hosts.allow путем добавления следующей строки:
файл: /etc/hosts.allow
sshd: /etc/ssh_dyn_allow/hosts_sshd.allow
Исходник скрипта выглядит так:
файл: /etc/ssh_dyn_allow/renew_allowed_ip_list.sh
#!/bin/bash
SCRIPT=$(readlink -f "$0")
WORKDIR=$(dirname "$SCRIPT")
ALLOWFILE=$WORKDIR/hosts_sshd.allow
DOMAINFILE=$WORKDIR/allowed_domain.list
DOMAINS=$(cat $DOMAINFILE |grep -v "^#")
echo "# automatic generated : $(date)" > $ALLOWFILE
for DOMAIN in $DOMAINS
do
echo ""
IP=$(dig $DOMAIN A | grep "^$DOMAIN" | sed -e 's/\s\s*/ /g' | cut -d " " -f5)
echo "# $DOMAIN"
echo $IP
echo
done >> $ALLOWFILE
Скрипт выполняется с помощью cronjob каждые 15 минут.
Файл с разрешенными доменами представляет собой текстовый файл с одним доменом в строке и выглядит следующим образом.
файл: /etc/ssh_dyn_allow/allowed_domain.list
# domainlist
# one domain per line
user1.ddnss.org
user2.ddnss.org
# fired_user.ddnss.org
# our other servers
web1.example.com
web2.example.com
Преимущества:
- можно обрабатывать более одного (динамического) домена (возможно, для коллеги или других серверов)
- исходный файл hosts.allow не может быть уничтожен ошибочным сценарием, манипулирующим файлом.