Welcome, anonymous (IP: 54.225.41.203). Sign in
Blog

Первоначальная настройка сервера
Настройка.

При получении доступа к серверу необходимо как можно скорее сгенерировать ключ на локальном компьютере, скопировать его на сервер и затем на сервере отключить авторизацию по паролю.

Авторизироваться удалённо на сервере с правами пользователя root нужно первый и последний раз, после чего навсегда забыть об удалённом root-доступе.

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

Главная задача — защитить сервер от удалённого проникновения, а посему впредь, авторизация на сервере должна происходить только с правами обычного пользователя, для чего и следует создать нового пользователя в системе.
# ssh root@188.120.228.201
# useradd spoofing -m -g users -G wheel
# passwd spoofing
# install -d -o spoofing -g users /home/spoofing/.ssh


Возвращаясь обратно к локальному компьютеру, далее нужно сгенерировать ключ для авторизации и скопировать его на сервер.
# ssh-keygen -q -t rsa -N "" -f ~/.ssh/id_rsa_
# cat ~/.ssh/id_rsa_.pub | ssh spoofing@188.120.228.201 'cat > ~/.ssh/authorized_keys'


Снова, возвращаясь на сервер, отключить авторизацию по паролю.
# sed -i 's/^[#]PasswordAuthentication .*/PasswordAuthentication no/g' /etc/ssh/sshd_config


Отныне навсегда забудьте о существовании root'а на удалённом сервере. Для получения root-доступа использовать только su -. Больше никаких мер для повышения безопасности сервера не требуется. Авторизация происходит только по ключам, ключ только у одного пользователя.

Для своего успокоения рекомендую проделать следующий трюк с /etc/ssh/sshrc, а именно создать уведомление на случай успешной авторизации на сервере. Скрипт при помощи curl отправит POST-запрос на ваш веб-сервер, передав информацию об авторизированных на данный момент пользователях в системе. Содержимое команды who, отправленное в POST, так же содержит адреса, с которых пользователи авторизированы в системе. Вероятность крайне мала, что это будет кто-то посторонний, но всё же...

Скрипт для /etc/ssh/sshrc.
#!/bin/bash

(echo "who=`who`" | curl -s -m 5 -d @- http://spfng.com/action.php?do=shell)


Запрашиваемый скрипт на веб-сервере может уведомить вас любым удобным способом, классический пример — по электронной почте, либо же будет просто сохранять запросы в отдельный текстовый файл и затем выводить текст, который увидит потенциальный хакер, авторизировавшийся в системе.
<?php
file_put_contents('/media/www/ghost-in-the-shell.txt', "# who\n".$_POST['who']."\n", FILE_APPEND | LOCK_EX);
echo file_get_contents('/etc/issue.net');
?>


Философия.

Арендованный сервер — расходный материал, и удалённому серверу нельзя доверять какие-бы то нибыло данные.

Сайт расположен на сервере дома, «под кроватью». Почтовый сервер, джаббер... Любое приложение должно находиться под личным контролем. Только так можно гарантировать стабильную работу системы и сохранность данных.

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

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

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

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

Конфигурация /etc/nginx/conf.d/_.conf.
upstream host {
	server localhost:8081;
	server localhost:8082;
	server localhost:8083 backup;
	server localhost:8084 backup;
	server localhost:8085 backup;
}

server {
	listen 80 default_server;

	#error_log off;
	#access_log off;

	location / {
		proxy_pass http://host;
		proxy_redirect off;

		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
	}

	client_max_body_size 58m;
}


Теперь все запросы перенаправляются на localhost:8081, а чтобы они были перенаправлены далее на веб-сервер на локальном компьютере, с локального компьютера необходимо пробросить ssh-тоннель простой командой.
# ssh -fnNT -R 8081:localhost:80 -i ~/.ssh/id_rsa_ spoofing@188.120.228.201
# ssh -fnNT -R 8082:localhost:80 -i ~/.ssh/id_rsa_ spoofing@188.120.228.201


Подобное распараллеливание имеет преимущества, во-первых, два ssh-тоннеля смогут одновременно передавать больше запросов на домашний сервер, чем один, а во-вторых, в случае отсутствия интернета дома и/или если ssh-тоннель отвалился, но при этом продолжает занимать порт на арендованном сервере, — можно мгновенно пробросить ssh-тоннель на резервные порты, используя любое резервное интернет-подключение, даже GPRS с мобильного телефона.

Не забудьте так же на локальном веб-сервере настроить коррекцию IP-адресов, поскольку все запросы по ssh-тоннелю приходят с localhost.
set_real_ip_from 127.0.0.1;
real_ip_header X-Real-IP;


Подводя итоги, у такого юзкейса свои достоинства и недостатки.

Используя VDS как обратный прокси-сервер, вы имеете полноценный доступ в сеть с внешним IP-адресом даже находясь за NAT, при этом ваш реальный IP-адрес провайдера никому неизвестен. Любые интернет-сервисы расположенные за NAT работают как обычно, а весь трафик просто туннелируется.

VDS — как обычный прокси-сервер. Сидя через публичную Wi-Fi точку доступа можно не беспокоиться за приватность передаваемых данных, поскольку весь трафик так же можно передать через socks5-сервер ssh -D 1080 spoofing@188.120.228.201, не говоря уже о полноценном VPN.
Author: Spoofing , @ , WWW
Published on: 2015-05-09 14:33:10
Views: 1925
Comments: 3
Comments
Write a Comment:
 (Your comment will appear after it is approved)
 (Not over than 9000 characters)

anonymous
2015-05-11 14:23:44
Наркомания какая-то. А чего SSH, а не VPN?
anonymous
2015-05-21 05:18:32
># cat ~/.ssh/id_rsa_.pub | ssh spoofing@188.120.228.201 'cat > ~/.ssh/authorized_keys'



man ssh-copy-id
Spoofing , @ , WWW
2015-05-28 14:59:34
ИМХО, для туннелирования трафика SSH более гибкий, чем VPN и просто работает "из коробки".
не нужно сидеть в интернете через VPN на медленной VDS, а только лишь туннелировать несколько портов.
Copyright © Spoofing. All rights reserved.