безопасность mamp и dyndns

Question

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

I порт перенаправленный порт 80. Какой риск, если таковые имеются?

Спасибо

R.

Answer 1

Во-первых, знайте, что независимо от того, что вы делаете, всегда есть риски, поэтому вы должны вместо этого подумать о снижении этих рисков. Некоторые из основных пунктов атаки, которые вы должны учитывать:

• dyndns - насколько надежен ваш пароль, и вы входите через https? Если ваш аккаунт скомпрометирован, кто-то может похитить ваших клиентов.
• маршрутизатор - может ли ваш маршрутизатор быть скомпрометирован, разрешив нежелательный трафик в вашей локальной сети? Для этого, если вы используете коммерческий маршрутизатор (а не компьютер, подключенный непосредственно к глобальной сети, против которого я бы порекомендовал), убедитесь, что он обновлен до последней версии.
• операционная система - в вашей ОС могут быть уязвимости. Хорошо, что вы принимаете трафик только через порт 80, но при этом сохраняете его исправленным и следите за уязвимостями по мере их обнаружения.
• веб-сервер - это большой сервер, отвечающий за обработку входящих запросов. Использование здесь уязвимости может позволить кому-то захватить ваш компьютер. Рассмотрите возможность блокировки доступа с помощью http auth. Это не помешает людям, которые действительно хотят дозвониться, но заблокирует поисковые системы и множество сценариев, если у вас возникнут проблемы с самим приложением.
• веб-приложение - здесь я не буду упоминать распространенные атаки (sql инъекция, xss, csrf, ...), потому что для этого потребуется книга, но помните, что если другие люди, кроме ваших клиентов, увидят ваше приложение может показывать данные, которые вы намеревались сделать конфиденциальными, и в зависимости от того, что делает ваше приложение / как оно закодировано / на какой платформе оно работает, вы можете подвергать свой компьютер какой-либо королевской власти. Блокировка его за брандмауэром (маршрутизатором) и простой аутентификацией - хорошее начало, и, вероятно, этого достаточно для ваших нужд, но следите за вашим доступом и системными журналами, а также регулярно меняйте http-пароли аутентификации (так как вы предоставляете их клиенты).
• (это просто царапает поверхность, так как я уверен, что вы можете указать и на многие другие векторы атаки)

Другие идеи:

• вызывать сайт только для демонстраций и использовать разные учетные данные для каждой демонстрации. Таким образом, вам не нужно заботиться о безопасности пароля, и вы снижаете риск подвергнуться атаке, когда не ожидаете этого. (поэтому отключите переадресацию, когда вы не запускаете демонстрацию)
• получите дешевую стойку, ec2, linode или бесплатный тестовый аккаунт heroku для этих демоверсий. Вам по-прежнему нужно беспокоиться о безопасности сервера и ваших приложений, но если они скомпрометированы, вы не потеряете личные данные на своем домашнем компьютере.
• аналогично пункту выше, если вам нужно работать в домашней сети, подумайте о том, чтобы получить недорогую коробку linux только для размещения ваших сайтов, и поместите ее в отдельный сетевой раздел из ваших персональных компьютеров.
• ssl-сертификаты - это всегда хорошая идея, если ваше приложение отправляет / получает конфиденциальные данные.