Безопасна ли переадресация портов на мой локальный хост на моем персональном компьютере с Ubuntu?
После установки Lamp на моем персональном компьютере с Ubuntu я запускаю приложение, которое должно подключаться к Интернету для отправки почты SMTP; например, PayPal нужен адрес www для уведомления об успешных или неудачных платежах ...
Мне удалось решить эту проблему путем приобретения бесплатного домена .tk, изменения настроек маршрутизатора и переадресации портов на IP-адрес моего компьютера.
Это безопасно? У меня есть брандмауэр, ограничивающий доступ только к порту: 80. Это мой персональный компьютер, на котором у меня есть личные файлы (за исключением папки / var / www).
Есть ли лучшая альтернатива?
Я думал об установке Ubuntu Server на VMware Workstation и переадресации портов на виртуальный сервер, но это может занять слишком много ресурсов.
2 ответа
Это будет так же безопасно, как конфигурация вашего веб-сервера и ваше веб-приложение, так же, как если бы оно было развернуто на «реальном» веб-сервере. Если веб-сервер работает от имени пользователя www-данных, вы можете изменить права доступа к домашнему каталогу на то, что пользователь www-данных не может прочитать:
cd ~
chmod 750 .
Запустите это, выполнив вход в систему под своим собственным именем пользователя. Остальное невозможно угадать без большой информации от вас, включая само веб-приложение. Но, по крайней мере, это может предложить немного больше душевного спокойствия, зная, что ваши файлы в вашем домашнем каталоге не будут прочитаны.
Добавьте еще один слой, создав файл .htaccess в DOCUMENT_ROOT (/ var / www /?), Так что любой, кто обращается к веб-серверу, должен будет сначала ввести имя пользователя и пароль. Это всегда можно удалить во время развертывания.
Предполагая, что вы используете Apache ... отредактируйте файл конфигурации Apache, чтобы убедиться, что все добавленные вами директивы AuthConfig будут работать. В директиве «Directory», которая указывает корневой каталог вашего документа, убедитесь, что в вашем выражении AllowOverride есть AuthConfig:
AllowOverride AuthConfig
Или вы можете использовать «All»:
AllowOverride All
This позволяет нам помещать директивы Apache в файлы .htaccess. Теперь создайте файл паролей где-нибудь за пределами общедоступной части веб-сайта. Здесь я создаю (-c) файл паролей с именем passwords в / usr / local / etc / apache / с первоначальным пользователем my_username. Он запросит пароль.
sudo mkdir -p /usr/local/etc/apache/
sudo htpasswd -c /usr/local/etc/apache/passwords my_username
Затем поместите некоторые директивы Apache AuthConfig в корень документа. Если корнем документа является / var / www /, используйте ваш любимый редактор для создания нового имени файла .htaccess ...
sudo vim /var/www/.htaccess
Содержимое этого файла ...
AuthType Basic
AuthName "My Web App"
AuthUserFile /usr/local/etc/apache/passwords
Require user my_username
Сохранить. Измените владельца и разрешения, если вы работаете как www-data:
sudo chown www-data /var/www/.htaccess
sudo chmod 400 /var/www/.htaccess
Теперь никто не может использовать веб-сервер без имени пользователя и пароля, плюс веб-сервер не может читать ваши личные файлы. Я не знаю, как или если этот метод пароля мог бы работать, хотя, когда PayPal перенаправляет обратно к вам.
Я полагаю, что вы можете перемещать .htaccess в / из каталога / var / www по мере необходимости, пока вы разрабатываете возвратную часть PayPal вашего веб-приложения.
Я думаю, что лучше понять последствия переадресации портов.
Обычно ваш маршрутизатор действует как брандмауэр, и обычно он блокирует все НОВЫЕ соединения, пытающиеся получить доступ к вашему серверу, в вашем случае apache.
Таким образом, если вы НЕ НЕ перенаправляете порт 80 с вашего маршрутизатора на локальный веб-сервер, доступ к нему можно получить только изнутри, от других пользователей вашей локальной сети.
Когда вы перенаправляете порт 80 и регистрируете полное доменное имя, другие пользователи, находящиеся за пределами вашей локальной сети, теперь также могут получить доступ к вашему серверу.
FQDN = полное доменное имя, в вашем случае = ваше имя .tk.
Это имеет свои преимущества: вы можете запускать свой почтовый сервер и обмениваться личными файлами, а также подвергать ваш сервер взломщикам.
Так что да, это (потенциальная) дыра в безопасности. Вы должны посмотреть на безопасность apache и следить за журналами на предмет подозрительной активности.
Я не был бы чрезмерно параноиком, но я бы не перенесся вперед, не понимая, как защитить ваш почтовый сервер и apache, и не научившись просматривать журналы (требуется немного времени, чтобы понять, что такое «нормальная» активность в журналах). ).
Проработайте документацию по безопасности на Apache, не чувствуйте себя перегруженными, это тонна информации, но и не игнорируйте ее.
В целом необходимость защищать веб-сервер пропорциональна ценности данных на сервере, поэтому вы не такая большая цель, как, скажем, финансовое учреждение.