Не открывайте порты в мир — вас поломают (риски) / Хабр

Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list’ом встречаюсь со стеной непонимания. Даже очень крутые админы/DevOps’ы спрашивают: «Зачем?!?»

Предлагаю рассмотреть риски в порядке убывания вероятности наступления и ущерба.

1. Ошибка конфигурации
2. DDoS по IP
3. Брутфорс
4. Уязвимости сервисов
5. Уязвимости стека ядра
6. Усиление DDoS атак

Ошибка конфигурации

Наиболее типичная и опасная ситуация. Как это бывает. Разработчику надо быстро проверить гипотезу, он поднимает временный сервер с mysql/redis/mongodb/elastic. Пароль, конечно, сложный, он везде его использует. Открывает сервис в мир — ему удобно со своего ПК гуём коннектиться без этих ваших VPN. А синтаксис iptables вспоминать лень, все равно сервер временный. Еще пару дней разработки — получилось отлично, можно показывать заказчику.

Заказчику нравится, переделывать некогда, запускаем в ПРОД!

Пример намеренно утрированный с целью пройтись по всем граблям:

1. Ничего нет более постоянного, чем временное — не люблю эту фразу, но по субъективным ощущениям, 20-40% таких временных серверов остаются надолго.
2. Сложный универсальный пароль, который используется во многих сервисах — зло. Потому что, один из сервисов, где использовался этот пароль, мог быть взломан. Так или иначе базы взломанных сервисов стекаются в одну, которая используется для [брутфорса]*.
   Стоит добавить, что redis, mongodb и elastic после установки вообще доступны без аутентификации, и часто пополняют коллекцию открытых баз.
3. Может показаться, что за пару дней никто не насканит ваш 3306 порт. Это заблуждение! Masscan — отличный сканер, и может сканировать со скоростью 10М портов в секунду. А в интернете всего 4 миллиарда IPv4. Соответственно, все 3306-ые порты в интернете находятся за 7 минут. Карл!!! Семь минут!
   
   «Да кому это надо?» — возразите вы. Вот и я удивляюсь, глядя в статистику дропнутых пакетов. Откуда за сутки 40 тысяч попыток скана с 3-х тысяч уникальных IP? Сейчас сканят все кому не лень, от мамкиных хакеров до правительств. Проверить очень просто — возьмите любую VPS’ку за $3-5 у любого** лоукостера, включите логирование дропнутых пакетов и загляните в лог через сутки.

Включение логирования

В /etc/iptables/rules.v4 добавьте в конец:
-A INPUT -j LOG —log-prefix «[FW — ALL] » —log-level 4

А в /etc/rsyslog.d/10-iptables.conf
:msg,contains,»[FW — » /var/log/iptables.log
& stop

DDoS по IP

Если злоумышленник знает ваш IP, он может на несколько часов или суток заддосить ваш сервер. Далеко не у всех лоукост-хостингов есть защита от DDoS и ваш сервер просто отключат от сети. Если вы спрятали сервер за CDN, не забудьте сменить IP, иначе хакер его нагуглит и будет DDoS’ить ваш сервер в обход CDN (очень популярная ошибка).

Уязвимости сервисов

Во всем популярном ПО рано или поздно находят ошибки, даже в самых оттестированных и самых критичных.

В среде ИБэшников, есть такая полу-шутка — безопасность инфраструктуры можно смело оценивать по времени последнего обновления. Если ваша инфраструктура богата торчащими в мир портами, а вы ее не обновляли год, то любой безопасник вам не глядя скажет, что вы дырявы, и скорее всего, уже взломаны.
Так же стоит упомянуть, что все известные уязвимости, когда-то были неизвестными. Вот представьте хакера, который нашел такую уязвимость, и просканировал весь интернет за 7 минут на ее наличие… Вот и новая вирусная эпидемия ) Надо обновляться, но это может навредить проду, скажете вы. И будете правы, если пакеты ставятся не из официальных репозиториев ОС. Из опыта, обновления из официального репозитория крайне редко ломают прод.

Брутфорс

Как описал выше, есть база с полу миллиардом паролей, которые удобно набирать с клавиатуры. Другими словами, если вы не сгенерировали пароль, а набрали на клавиатуре рядом расположенные символы, будьте уверены* — вас сбрутят.

Уязвимости стека ядра.

Бывает**** и такое, что даже не важно какой именно сервис открывает порт, когда уязвим сам сетевой стек ядра. То есть абсолютно любой tcp/udp-сокет на системе двухлетней давности подвержен уязвимости приводящий к DDoS.

Усиление DDoS-атак

Напрямую ущерба не принесет, но может забить ваш канал, поднять нагрузку на систему, ваш IP попадет в какой-нибудь black-list*****, а вам прилетит абуза от хостера.

Неужели вам нужны все эти риски? Добавьте ваш домашний и рабочий IP в white-list. Даже если он динамический — залогиньтесь через админку хостера, через веб-консоль, и просто добавьте еще один.

Я 15 лет занимаюсь построением и защитой IT-инфраструктуры. Выработал правило, которое всем настоятельно рекомендую — ни один порт не должен торчать в мир без white-list’a.

Например, наиболее защищенный web-сервер*** — это тот, у которого открыты 80 и 443 только для CDN/WAF. А сервисные порты (ssh, netdata, bacula, phpmyadmin) должны быть как минимум за white-list’ом, а еще лучше за VPN. Иначе вы рискуете быть скомпрометированным.

У меня все. Держите свои порты закрытыми!

---

• (1) UPD1: Здесь можно проверить свой крутой универсальный пароль (не делайте этого не заменив этот пароль на рандомные во всех сервисах ), не засветился ли он в слитой базе. А тут можно посмотреть сколько сервисов было взломано, где фигурировал ваш email, и, соответственно, выяснить, не скомпрометирован ли ваш крутой универсальный пароль.
• (2) К чести Amazon — на LightSail минимум сканов. Видимо, как-то фильтруют.
• (3) Еще более защищенный web-сервер это тот, что за выделенным firewall’ом, своим WAF, но речь о публичных VPS/Dedicated.
• (4) Segmentsmak.
• (5) Firehol.

Сетевые порты для клиентов и поток почты в Exchange

• 891Z» data-article-date-source=»git»>24.03.2021
• Чтение занимает 9 мин

В этой статье

В этом разделе приводится информация о сетевых портах, используемых Exchange Server 2016 и Exchange Server 2019 г. для связи с клиентами электронной почты, серверами интернет-почты и другими службами, внешними для локальной организации Exchange.This topic provides information about the network ports that are used by Exchange Server 2016 and Exchange Server 2019 for communication with email clients, internet mail servers, and other services that are external to your local Exchange organization. Прежде чем начать, обдумайте следующие основные правила.Before we get into that, understand the following ground rules:

• Мы не поддерживаем ограничение или изменение сетевого трафика между внутренними серверами Exchange, между внутренними серверами Exchange и внешними серверами Lync либо Skype для бизнеса или между внутренними серверами Exchange и внутренними контроллерами домена Active Directory в любых типах топологии.

  We do not support restricting or altering network traffic between internal Exchange servers, between internal Exchange servers and internal Lync or Skype for Business servers, or between internal Exchange servers and internal Active Directory domain controllers in any and all types of topologies. Если у вас есть брандмауэры или сетевые устройства, которые потенциально могут ограничить или изменить этот вид внутреннего сетевого трафика, необходимо настроить правила, которые позволяют свободно и неограниченное общение между этими серверами: правила, которые позволяют входящий и исходяющий сетевой трафик в любом порту (в том числе случайные порты RPC) и любой протокол, который никогда не изменяет биты на проводе.If you have firewalls or network devices that could potentially restrict or alter this kind of internal network traffic, you need to configure rules that allow free and unrestricted communication between these servers: rules that allow incoming and outgoing network traffic on any port (including random RPC ports) and any protocol that never alter bits on the wire.

• Внешние транспортные серверы почти всегда находятся в сети периметра, поэтому ожидается, что вы ограничите сетевой трафик между транспортным сервером Edge и Интернетом, а также между краем транспортного сервера и вашей внутренней организацией Exchange.Edge Transport servers are almost always located in a perimeter network, so it’s expected that you’ll restrict network traffic between the Edge Transport server and the internet, and between the Edge Transport server and your internal Exchange organization. Эти сетевые порты описаны в данном разделе.These network ports are described in this topic.

• Ожидается, что вы ограничите сетевой трафик между внешними клиентами и службами и внутренней организацией Exchange. Также можно ограничить трафик между внутренними клиентами и внутренними серверами Exchange. Эти сетевые порты описаны в данном разделе.It’s expected that you’ll restrict network traffic between external clients and services and your internal Exchange organization.

  It’s also OK if you decide to restrict network traffic between internal clients and internal Exchange servers. These network ports are described in this topic.

Сетевые порты, необходимые для клиентов и службNetwork ports required for clients and services

Сетевые порты, которые необходимы почтовым клиентам для доступа к почтовым ящикам и другим службам в организации Exchange, описаны на следующей диаграмме и в таблице.The network ports that are required for email clients to access mailboxes and other services in the Exchange organization are described in the following diagram and table.

Примечания.Notes:

• Предназначением для этих клиентов и служб являются службы клиентского доступа на сервере почтовых ящиков.The destination for these clients and services is the Client Access services on a Mailbox server. В Exchange 2016 и Exchange 2019 службы клиентского доступа (frontend) и backend устанавливаются вместе на одном сервере почтовых ящиков.

  In Exchange 2016 and Exchange 2019, Client Access (frontend) and backend services are installed together on the same Mailbox server. Дополнительные сведения см. в архитектуре протокола клиентского доступа.For more information, see Client Access protocol architecture.

• Хотя на схеме показаны клиенты и службы из Интернета, концепции одинаковы для внутренних клиентов (например, клиенты в лесу учетных записей, которые имеют доступ к серверам Exchange в лесу ресурсов).Although the diagram shows clients and services from the internet, the concepts are the same for internal clients (for example, clients in an accounts forest accessing Exchange servers in a resource forest). Кроме того, в таблице нет столбца источника, так как источником может быть любое расположение, внешнее для организации Exchange (например, интернет или лес учетных записей).Similarly, the table doesn’t have a source column because the source could be any location that’s external to the Exchange organization (for example, the internet or an accounts forest).

• Пограничные транспортные серверы не участвуют в сетевом трафике, связанном с этими клиентами и службами.Edge Transport servers have no involvement in the network traffic that’s associated with these clients and services.

НазначениеPurpose	ПортыPorts	ПримечанияComments
Зашифрованные веб-подключения используются следующими клиентами и службами.Encrypted web connections are used by the following clients and services: • Служба автооткрытия• Autodiscover service • Exchange ActiveSync• Exchange ActiveSync • Веб-службы Exchange (EWS)• Exchange Web Services (EWS) • Распространение автономной адресной книги (OAB)• Offline address book (OAB) distribution • Outlook Anywhere (RPC over HTTP)• Outlook Anywhere (RPC over HTTP) • Outlook MAPI над HTTP• Outlook MAPI over HTTP • Outlook в Интернете (ранее известный как Outlook Web App)• Outlook on the web (formerly known as Outlook Web App)	443/TCP (HTTPS)443/TCP (HTTPS)	Дополнительные сведения об этих клиентах и службах см. в следующих статьях. For more information about these clients and services, see the following topics: • Служба автооткрытия в Exchange Server• Autodiscover service in Exchange Server • Exchange ActiveSync• Exchange ActiveSync • ссылка на EWS для Exchange• EWS reference for Exchange • Автономные адресные книги в Exchange Server• Offline address books in Exchange Server • Outlook Anywhere• Outlook Anywhere • MAPI над HTTP в Exchange Server• MAPI over HTTP in Exchange Server
Незашифрованные веб-подключения используются следующими клиентами и службами.Unencrypted web connections are used by the following clients and services: • Публикация календаря в Интернете• Internet calendar publishing • Outlook в Интернете (перенаправление на 443/TCP)• Outlook on the web (redirect to 443/TCP) • Автоматическое открытие (откат, когда не доступен 443/TCP)• Autodiscover (fallback when 443/TCP isn’t available)	80/TCP (HTTP)80/TCP (HTTP)	По возможности рекомендуется использовать зашифрованное веб-подключения на TCP-порте 443 для защиты учетных и других данных. Whenever possible, we recommend using encrypted web connections on 443/TCP to help protect data and credentials. Однако вы можете обнаружить, что некоторые службы должны быть настроены для использования незашифрованных веб-подключений на 80/TCP к службам клиентского доступа на серверах почтовых ящиков.However, you may find that some services must be configured to use unencrypted web connections on 80/TCP to the Client Access services on Mailbox servers. Дополнительные сведения об этих клиентах и службах см. в следующих статьях. For more information about these clients and services, see the following topics: • Включить публикацию интернет-календаря• Enable Internet Calendar Publishing • Служба автооткрытия в Exchange Server• Autodiscover service in Exchange Server
Клиенты IMAP4IMAP4 clients	143/TCP (IMAP), 993/TCP (безопасный IMAP)143/TCP (IMAP), 993/TCP (secure IMAP)	По умолчанию IMAP4 отключен.IMAP4 is disabled by default. Дополнительные сведения см. в pop3 и IMAP4 в Exchange Server.For more information, see POP3 and IMAP4 in Exchange Server. Служба IMAP4 в службах клиентского доступа на прокси-серверах почтовых ящиков подключена к службе backend IMAP4 на сервере почтовых ящиков.The IMAP4 service in the Client Access services on the Mailbox server proxies connections to the IMAP4 Backend service on a Mailbox server.
Клиенты POP3POP3 clients	110/TCP (POP3), 995/TCP (безопасный POP3)110/TCP (POP3), 995/TCP (secure POP3)	По умолчанию протокол POP3 отключен.POP3 is disabled by default. Дополнительные сведения см. в pop3 и IMAP4 в Exchange Server.For more information, see POP3 and IMAP4 in Exchange Server. Служба POP3 в службах клиентского доступа на прокси-серверах почтовых ящиков подключена к службе backend POP3 на сервере почтовых ящиков.The POP3 service in the Client Access services on the Mailbox server proxies connections to the POP3 Backend service on a Mailbox server.
Клиенты SMTP (с проверкой подлинности)SMTP clients (authenticated)	587/TCP (SMTP с проверкой подлинности)587/TCP (authenticated SMTP)	Соединиттель по умолчанию получил имя «Client Frontend» в передней транспортной службе прослушивает проверку подлинности клиентских представлений SMTP в <Server name> порту 587. The default Received connector named «Client Frontend <Server name>» in the Front End Transport service listens for authenticated SMTP client submissions on port 587. Примечание. Если у вас есть клиенты электронной почты, которые могут отправлять только проверку подлинности SMTP-почты в порту 25, вы можете изменить привязки сетевого адаптера соединиттеля получения клиента, чтобы также прослушивать проверку подлинности сообщений электронной почты SMTP в порту 25.Note: If you have email clients that are only able to submit authenticated SMTP email on port 25, you can modify the network adapter bindings of the client Receive connector to also listen for authenticated SMTP email submissions on port 25.

Сетевые порты, необходимые для потока обработки почтыNetwork ports required for mail flow

Способ доставки почты в организацию Exchange и из нее зависит от топологии Exchange. Наиболее важный фактор — наличие подписанного пограничного транспортного сервера, развернутого в сети периметра. How mail is delivered to and from your Exchange organization depends on your Exchange topology. The most important factor is whether you have a subscribed Edge Transport server deployed in your perimeter network.

Сетевые порты, необходимые для потока обработки почты (без пограничных транспортных серверов)Network ports required for mail flow (no Edge Transport servers)

Сетевые порты, необходимые для потока почты в организации Exchange, которая имеет только серверы почтовых ящиков, описаны в следующей схеме и таблице.The network ports that are required for mail flow in an Exchange organization that has only Mailbox servers are described in the following diagram and table.

НазначениеPurpose	ПортыPorts	ИсточникSource	НазначениеDestination	ПримечанияComments
Входящая почтаInbound mail	25/TCP (SMTP)25/TCP (SMTP)	Интернет (все)Internet (any)	Сервер почтовых ящиковMailbox server	Соединиттель получения по умолчанию с именем «Frontend по умолчанию» в передней транспортной службе прослушивает анонимные входящие сообщения SMTP в <Mailbox server name> порту 25. The default Receive connector named «Default Frontend <Mailbox server name>» in the Front End Transport service listens for anonymous inbound SMTP mail on port 25. Почта передается из передней транспортной службы в службу транспорта на сервере почтовых ящиков с помощью неявного и невидимого соединителя отправки внутри организации, который автоматически отправляет почту между серверами Exchange в той же организации.Mail is relayed from the Front End Transport service to the Transport service on a Mailbox server using the implicit and invisible intra-organization Send connector that automatically routes mail between Exchange servers in the same organization. Дополнительные сведения см. в включении неявных соединителов отправки.For more information, see Implicit Send connectors.
Исходящая почтаOutbound mail	25/TCP (SMTP)25/TCP (SMTP)	Сервер почтовых ящиковMailbox server	Интернет (все)Internet (any)	По умолчанию Exchange не создает соединители отправки, которые позволяют отправлять почту в Интернет. By default, Exchange doesn’t create any Send connectors that allow you to send mail to the internet. Необходимо создать соединители отправки вручную.You have to create Send connectors manually. Дополнительные сведения см. в сообщении Create a Send connector для отправки почты в Интернет.For more information, see Create a Send connector to send mail to the internet.
Исходящие почтовые сообщения (если они прокси-серверы с помощью транспортной службы переднего конца)Outbound mail (if proxied through the Front End transport service)	25/TCP (SMTP)25/TCP (SMTP)	Сервер почтовых ящиковMailbox server	Интернет (все)Internet (any)	Исходящие сообщения подключаются через службу переднего транспорта только в том случае, если соединитель отправки настроен с помощью прокси-сервера клиентского доступа в центре администрирования Exchange или в центре управления -FrontEndProxyEnabled $true Exchange.Outbound mail is proxied through the Front End Transport service only when a Send connector is configured with Proxy through Client Access server in the Exchange admin center or -FrontEndProxyEnabled $true in the Exchange Management Shell. В этом случае соединиттель получения по умолчанию с именем «Исходящие прокси-серверы» в службе транспорта переднего конца прослушивает исходящие сообщения из транспортной службы на сервере почтовых <Mailbox server name> ящиков.In this case, the default Receive connector named «Outbound Proxy Frontend <Mailbox server name>» in the Front End Transport service listens for outbound mail from the Transport service on a Mailbox server. Дополнительные сведения см. в статье Configure Send connectors to proxy outbound mail.For more information, see Configure Send connectors to proxy outbound mail.
DNS-сервер для разрешения имен следующего перехода почты (не показан на рисунке)DNS for name resolution of the next mail hop (not pictured)	53/UDP, 53/TCP (DNS)53/UDP,53/TCP (DNS)	Сервер почтовых ящиковMailbox server	DNS-серверDNS server	В этом разделе см. раздел Разрешение имен.See the Name resolution section in this topic.

Сетевые порты, необходимые для потока обработки почты с пограничными транспортными серверамиNetwork ports required for mail flow with Edge Transport servers

Установленный в сети периметра поддерживаемый edge transport server влияет на поток почты следующим образом:A subscribed Edge Transport server that’s installed in your perimeter network affects mail flow in the following ways:

• Исходящие сообщения из организации Exchange никогда не проходят через службу переднего транспорта на серверах почтовых ящиков.Outbound mail from the Exchange organization never flows through the Front End Transport service on Mailbox servers. Почта всегда перетекает из транспортной службы на сервере почтовых ящиков на подписанном сайте Active Directory на краевой транспортный сервер (независимо от версии Exchange на краевом транспортном сервере).Mail always flows from the Transport service on a Mailbox server in the subscribed Active Directory site to the Edge Transport server (regardless of the version of Exchange on the Edge Transport server).

• Входящие почтовые потоки с краевом транспортного сервера на сервер почтовых ящиков на подписанном сайте Active Directory.Inbound mail flows from the Edge Transport server to a Mailbox server in the subscribed Active Directory site. Это означает следующее:Specifically:

  • Почта с транспортного сервера Exchange 2013 или более позднего края сначала поступает в службу переднего транспорта, а затем поступает в службу транспорта на сервере почтовых ящиков Exchange 2016 или Exchange 2019.Mail from an Exchange 2013 or later Edge Transport server first arrives at the Front End Transport service before it flows to the Transport service on an Exchange 2016 or Exchange 2019 Mailbox server.

  • В Exchange 2016 почта с кражного транспортного сервера Exchange 2010 всегда доставляет почту непосредственно в службу транспорта на сервере почтовых ящиков Exchange 2016.In Exchange 2016, mail from an Exchange 2010 Edge Transport server always delivers mail directly to the Transport service on an Exchange 2016 Mailbox server. Обратите внимание, что сосуществование с Exchange 2010 не поддерживается в Exchange 2019.Note that coexistance with Exchange 2010 isn’t supported in Exchange 2019.

Дополнительные сведения см. в перетоке почты и транспортном конвейере.For more information, see Mail flow and the transport pipeline.

Сетевые порты, необходимые для потока обработки почты в организациях Exchange с пограничными транспортными серверами, описаны на следующей диаграмме и в таблице.The network ports that are required for mail flow in Exchange organizations that have Edge Transport servers are described in the following diagram and table.

НазначениеPurpose	ПортыPorts	ИсточникSource	НазначениеDestination	ПримечанияComments
Входящая почта — из Интернета на пограничный транспортный серверInbound mail — Internet to Edge Transport server	25/TCP (SMTP)25/TCP (SMTP)	Интернет (все)Internet (any)	Пограничный транспортный серверEdge Transport server	Соединиттель получения по умолчанию с именем «Внутренний соединиттель получения по умолчанию» на краевом транспортном сервере прослушивает анонимные сообщения SMTP в <Edge Transport server name> порту 25. The default Receive connector named «Default internal Receive connector <Edge Transport server name>» on the Edge Transport server listens for anonymous SMTP mail on port 25.
Входящая почта — от пограничного транспортного сервера во внутреннюю организацию ExchangeInbound mail — Edge Transport server to internal Exchange organization	25/TCP (SMTP)25/TCP (SMTP)	Пограничный транспортный серверEdge Transport server	Серверы почтовых ящиков на подписанном сайте Active DirectoryMailbox servers in the subscribed Active Directory site	Соединититель отправки по умолчанию с именем «EdgeSync — Входящий» передает входящий почтовый ящик в порте 25 на любой сервер почтовых ящиков на сайте <Active Directory site name> Active Directory.The default Send connector named «EdgeSync — Inbound to <Active Directory site name>» relays inbound mail on port 25 to any Mailbox server in the subscribed Active Directory site. Дополнительные сведения см. в журнале Send connectors created automatically by the Edge Subscription.For more information, see Send connectors created automatically by the Edge Subscription. Соединитель получения по умолчанию с именем «Frontend по умолчанию» в передней транспортной службе на сервере почтовых ящиков прослушивает все входящие сообщения (включая почту с серверов транспорта Exchange 2013 или более поздней части) в порту <Mailbox server name> 25.The default Receive connector named «Default Frontend <Mailbox server name>» in the Front End Transport service on the Mailbox server listens for all inbound mail (including mail from Exchange 2013 or later Edge Transport servers) on port 25.
Исходящая почта — от внутренней организации Exchange на пограничный транспортный сервераOutbound mail — Internal Exchange organization to Edge Transport server	25/TCP (SMTP)25/TCP (SMTP)	Серверы почтовых ящиков на подписанном сайте Active DirectoryMailbox servers in the subscribed Active Directory site	Пограничные транспортные серверыEdge Transport servers	Исходящие сообщения всегда обходят службу переднего транспорта на серверах почтовых ящиков. Outbound mail always bypasses the Front End Transport service on Mailbox servers. Почта передается из транспортной службы на любом сервере почтовых ящиков на подписанном сайте Active Directory на краевой транспортный сервер с помощью неявного и невидимого соединителя отправки внутри организации, который автоматически отправляет почту между серверами Exchange в той же организации.Mail is relayed from the Transport service on any Mailbox server in the subscribed Active Directory site to an Edge Transport server using the implicit and invisible intra-organization Send connector that automatically routes mail between Exchange servers in the same organization. Соединиттель получения по умолчанию с именем «Внутренний соединиттель получения по умолчанию» на краевом транспортном сервере прослушивает почту SMTP в порту 25 из транспортной службы на любом сервере почтовых ящиков на подписанном сайте <Edge Transport server name> Active Directory.The default Receive connector named «Default internal Receive connector <Edge Transport server name>» on the Edge Transport server listens for SMTP mail on port 25 from the Transport service on any Mailbox server in the subscribed Active Directory site.
Исходящие сообщения — edge Transport server to internetOutbound mail — Edge Transport server to internet	25/TCP (SMTP)25/TCP (SMTP)	Пограничный транспортный серверEdge Transport server	Интернет (все)Internet (any)	Соединититель отправки по умолчанию с именем «EdgeSync — в Интернет» передает исходящие сообщения в порте 25 с сервера edge <Active Directory site name> Transport в Интернет.The default Send connector named «EdgeSync — <Active Directory site name> to Internet» relays outbound mail on port 25 from the Edge Transport server to the internet.
Синхронизация EdgeSyncEdgeSync synchronization	50636/TCP (безопасный LDAP)50636/TCP (secure LDAP)	Серверы почтовых ящиков на подписанном сайте Active Directory, которые участвуют в синхронизации EdgeSyncMailbox servers in the subscribed Active Directory site that participate in EdgeSync synchronization	Пограничные транспортные серверыEdge Transport servers	При подписке на веб-сайт Active Directory на сервере Edge Transport server все серверы почтовых ящиков, которые существуют на сайте в момент, участвуют в EdgeSync синхронизации. When the Edge Transport server is subscribed to the Active Directory site, all Mailbox servers that exist in the site at the time participate in EdgeSync synchronization. Однако все серверы почтовых ящиков, которые будут добавлены позже, автоматически не участвуют в EdgeSync синхронизации.However, any Mailbox servers that you add later don’t automatically participate in EdgeSync synchronization.
DNS-сервер для разрешения имен следующего перехода почты (не показан на рисунке)DNS for name resolution of the next mail hop (not pictured)	53/UDP, 53/TCP (DNS)53/UDP,53/TCP (DNS)	Пограничный транспортный серверEdge Transport server	DNS-серверDNS server	Далее в этом разделе см. раздел Разрешение имен.See the Name resolution section later in this topic.
Обнаружение прокси-сервера в репутации отправитель (не изображено)Open proxy server detection in sender reputation (not pictured)	см. комментарииsee comments	Пограничный транспортный серверEdge Transport server	ИнтернетInternet	По умолчанию репутация отправитель (агент анализа протоколов) использует обнаружение открытых прокси-серверов в качестве одного из критериев для вычисления уровня репутации отправитель (SRL) сервера исходных сообщений. By default, sender reputation (the Protocol Analysis agent) uses open proxy server detection as one of the criteria to calculate the sender reputation level (SRL) of the source messaging server. Дополнительные сведения см. в разделе Sender reputation and the Protocol Analysis agent.For more information, see Sender reputation and the Protocol Analysis agent. Обнаружение открытых прокси-серверов использует следующие протоколы и порты TCP для тестирования исходных серверов обмена сообщениями для открытых прокси:Open proxy server detection uses the following protocols and TCP ports to test source messaging servers for open proxy: • SOCKS4, SOCKS5: 1081, 1080• SOCKS4, SOCKS5: 1081, 1080 • Wingate, Telnet, Cisco: 23• Wingate, Telnet, Cisco: 23 • HTTP CONNECT, HTTP POST: 6588, 3128, 80• HTTP CONNECT, HTTP POST: 6588, 3128, 80 Кроме того, если ваша организация использует прокси-сервер для управления исходящие интернет-трафик, необходимо определить имя, тип сервера прокси-сервера и порт TCP, для доступа к интернету для обнаружения открытых прокси-серверов. Also, if your organization uses a proxy server to control outbound internet traffic, you need to define the proxy server name, type, and TCP port that sender reputation requires to access the internet for open proxy server detection. Кроме того, можно отключить обнаружение открытых прокси-серверов в репутации отправитель.Alternatively, you can disable open proxy server detection in sender reputation. Дополнительные сведения см. в дополнительных сведениях о процедурах репутации отправитель.For more information, see Sender reputation procedures.

Разрешение именName resolution

Разрешение DNS следующего перехода почты является фундаментальной составляющей потока обработки почты в любой организации Exchange. Серверы Exchange, ответственные за получение входящей почты или доставку исходящей, должны иметь возможность разрешать как внутренние, так и внешние имена узлов для правильной маршрутизации почты. Все внутренние серверы Exchange должны иметь возможность разрешать внутренние имена узлов для правильной маршрутизации почты. Существует множество различных способов разработки инфраструктуры DNS, но важный результат — обеспечение правильного разрешения имен для следующего перехода на всех серверах Exchange.DNS resolution of the next mail hop is a fundamental part of mail flow in any Exchange organization. Exchange servers that are responsible for receiving inbound mail or delivering outbound mail must be able to resolve both internal and external host names for proper mail routing. And all internal Exchange servers must be able to resolve internal host names for proper mail routing. There are many different ways to design a DNS infrastructure, but the important result is to ensure name resolution for the next hop is working properly for all of your Exchange servers.

Сетевые порты, необходимые для гибридных развертыванийNetwork ports required for hybrid deployments

Сетевые порты, необходимые для организации, использующей как локальное Exchange, так и Microsoft 365 или Office 365, охватываются протоколами гибридного развертывания,портами и конечными точками. The network ports that are required for an organization that uses both on-premises Exchange and Microsoft 365 or Office 365 are covered in Hybrid deployment protocols, ports, and endpoints.

Сетевые порты, необходимые для единой системы обмена сообщениями в Exchange 2016Network ports required for Unified Messaging in Exchange 2016

Сетевые порты, необходимые для единой системы обмена сообщениями в Exchange 2013 и Exchange 2016, охватываются протоколами единой системы обмена сообщениями, портами и службами.The network ports that are required for Unified Messaging in Exchange 2013 and Exchange 2016 are covered in the topic UM protocols, ports, and services.

Личный кабинет юридического лица | Статьи по 1С

Интернет-сервис «Личный кабинет юридического лица» предназначен для юридических лиц — российских организаций и позволяет:

• получать актуальную информацию о задолженности по налогам перед бюджетом, о суммах начисленных и уплаченных налоговых платежей, о наличии переплат, невыясненных платежей, об исполненных налоговым органом решениях на зачет и на возврат излишне уплаченных (излишне взысканных) сумм, о принятых решениях об уточнении платежа, об урегулированной задолженности, о неисполненных налогоплательщиком требованиях на уплату налога и других обязательных платежей, о мерах принудительного взыскания задолженности;
• получать выписку из ЕГРН в отношении самого себя;
• направлять запросы и получать справку о состоянии расчетов по налогам, сборам, пеням, штрафам, процентам, акт совместной сверки расчетов по налогам, сборам, пеням, штрафам, процентам;
• направлять запрос на получение справки об исполнении обязанности по уплате налогов, сборов, пеней, штрафов, процентов;
• составлять и направлять в налоговые органы заявления на уточнение невыясненного платежа, заявление на уточнение платежных документов, в которых налогоплательщик самостоятельно обнаружил ошибки в оформлении, заявления о зачете/возврате переплаты, заявления для инициирования сверки расчетов с бюджетом;
• направлять в налоговый орган сообщения по форме С-09-6 об участии в российских организациях;
• получать услуги по постановке и снятию с учета организации по месту нахождения обособленного подразделения, внесению изменений в сведения об обособленном подразделении на основании формализованных электронных сообщений налогоплательщика по формам № С-09-3-1, С-09-3-2, 1-6-Учет, 3-Учет, в качестве налогоплательщика ЕНВД на основании заявлений по формам № ЕНВД-1, ЕНВД-3, 3-Учет;
• направлять документы для государственной регистрации юридических лиц или внесения изменений в сведения, содержащиеся в ЕГРЮЛ, в налоговый орган для осуществления процедур государственной регистрации или внесения изменений в ЕГРЮЛ;
• получать информацию о ходе исполнения его заявлений и запросов самостоятельно контролировать сроки оказания услуги налоговым органом, получать решения налогового органа по направлению заявлениям;

Проверка выполнения условий доступа к личному кабинету

При работе в «Личном кабинете юридического лица» используется защищенное соединение и авторизация пользователя по квалифицированному сертификату ключа проверки электронной подписи, выданному Удостоверяющим центром, аккредитованным в сети доверенных удостоверяющих центров Минкомсвязи России, участником которой является и ФНС России. Рекомендуется использовать квалифицированный сертификат ключа проверки электронной подписи, соответствующий положениям Федерального закона от 06.04.2011 N 63-ФЗ.

Поэтому, чтобы воспользоваться данным интернет-сервисом, необходимо выполнение ряда технических условий:

• Microsoft Windows XP или выше, либо Mac OS X 10.9 или выше;
• Криптопровайдер с поддержкой алгоритмов шифрования ГОСТ 34.10-2001 и ГОСТ 28147-89;
• Браузер с поддержкой шифрования защищенных соединений по ГОСТ 34.10-2001, 28147-89;
• Программный компонент для работы с электронной подписью с использованием Web-браузера
  (Крипто ПРО ЭЦП browser plug-in версия 2.0, скачать).
• Набор драйверов и дополнительных утилит для работы с электронными ключами eToken PKI Client 5.1 SP1;

Необходимо установить сертификаты ключей проверки электронной подписи:

• Сертификат «Головного Удостоверяющего Центра» (скачать с сайта Головного Удостоверяющего Центра) — в хранилище сертификатов «Доверенные корневые центры»;
• Цепочку КСКПЭП, начиная от КСКПЭП УЦ, непосредственно выдавшего юридическому лицу его КСКПЭП, и до корневого КСКПЭП, последнего в цепочке сертификатов, установить в соответствующие хранилища:
  Самоподписанный (поле «Кому выдан» совпадает с полем «Кем выдан») квалифицированный сертификат ключа проверки электронной подписи (КСКПЭП) удостоверяющего центра, — в хранилище сертификатов «Доверенные корневые центры»;
  Остальные сертификаты цепочки — в хранилище сертификатов «Промежуточные центры сертификации».
• КСКПЭП, выданный юридическому лицу удостоверяющим центром, аккредитованным в соответствии с требованиями Федерального закона № 63-ФЗ, — в хранилище сертификатов «Личные».

Дополнительные настройки:

• Установить узлы //lkul.nalog.ru и //lkul.nalog.ru в зону надежных узлов;
• Порты 80 и 443 должны быть открыты для отправки и приема данных из сети Интернет.
• Узел //lkuls.nalog.ru должен быть доступен (порт 443). Доступность узла можно наблюдать ниже.

Порядок предоставления доступа в личный кабинет юридического лица

Для подключения к сервису «Личный кабинет юридического лица» необходимо получить квалифицированный сертификат ключа проверки электронной подписи (далее КСКПЭП) в удостоверяющем центре, аккредитованном в сети доверенных удостоверяющих центров Минкомсвязи России, участником которой является и ФНС России в соответствии с требованиями Федерального закона от 06.04.2011 № 63-ФЗ.

КСКПЭП должен быть выдан на руководителя организации либо лицо, имеющее право действовать без доверенности от имени организации по сведениям ЕГРЮЛ, либо лицо, имеющее действующую доверенность с полными полномочиями.

Обязательным условием является наличие в КСКПЭП ИНН и ОГРН юридического лица.

Для управляющей компании КСКПЭП должен содержать ФИО руководителя управляющей компании и реквизиты той организации, управление которой осуществляется (ИНН, ОГРН).

Могут быть использованы КСКПЭП, выданные для представления налоговой и бухгалтерской отчетности по телекоммуникационным каналам связи.

Для входа в «Личный кабинет юридического лица»:

• подключите носитель ключа электронной подписи к компьютеру;
• выполните проверку условий подключения к личному кабинету налогоплательщика юридического лица;

Первый вход в «Личный кабинет юридического лица» осуществляется с ключом электронной подписи, выданным руководителю ЮЛ либо лицу, имеющему право действовать без доверенности в отношении ЮЛ по сведениям ЕГРЮЛ, либо лицу, имеющего действующую доверенность с полными полномочиями и требует прохождения процедуры регистрации в сервисе.

Регистрация руководителем организации, либо лицом имеющим право действовать без доверенности от имени организации по сведениям ЕГРЮЛ:

1. На странице регистрации:
   • ознакомьтесь с текстом Соглашения об открытии доступа, подпишите его своей электронной подписью;
   • введите адрес электронной почты;
   • введите код с картинки;
   • нажмите «Далее».
2. В появившемся окне проверьте введенные ранее данные. В случае необходимости уточните адрес электронной почты, на который в течение двух часов будет направлена ссылка активации Личного кабинета. Ожидайте ссылки активации Личного кабинета юридического лица.
3. После получения на указанный при регистрации адрес электронной почты сообщения:
   • откройте сообщение с ссылкой активации Личного кабинета юридического лица;
   • перейдите по указанной ссылке.
4. Для предоставления доступа филиалам и другим обособленным подразделениям руководитель ЮЛ (лицо, имеющее право действовать без доверенности от имени организации по сведениям ЕГРЮЛ) должен завести сведения своих обособленных подразделений в разделе «Администрирование» сервиса «Личный кабинет налогоплательщика юридического лица».

Регистрация юридического лица при наличии управляющей компании:

1. Руководитель управляющей компании подписывает соглашение с ключом квалифицированной электронной подписи, с данными той организации, доступ в Личный кабинет которой необходимо получить.
2. На странице регистрации:
   • ознакомьтесь с текстом Соглашения об открытии доступа, подпишите его своей электронной подписью;
   • введите адрес электронной почты;
   • введите код с картинки;
   • нажмите «Далее».
3. В появившемся окне проверьте введенные ранее данные. В случае необходимости уточните адрес электронной почты, на который в течение двух часов будет направлена ссылка активации Личного кабинета. Ожидайте ссылки активации Личного кабинета юридического лица.
4. После получения на указанный при регистрации адрес электронной почты сообщения:
   • откройте сообщение с ссылкой активации Личного кабинета юридического лица;
   • перейдите по указанной ссылке.
5. Для предоставления доступа филиалам и другим обособленным подразделениям руководитель управляющей компании должен завести сведения обособленных подразделений организации в разделе «Администрирование» сервиса «Личный кабинет юридического лица».

Регистрация лицом, имеющим действующую доверенность с полными полномочиями:

1. На странице регистрации:
   • ознакомьтесь с текстом Соглашения об открытии доступа, подпишите его своей электронной подписью;
   • введите адрес электронной почты;
   • введите код с картинки;
   • нажмите «Далее».
2. Выбрать способ ввода доверенности:
   • вручную;
   • загрузить информационное сообщение о доверенности;
   • введите код с картинки;
   • нажать «Далее»;
3. В появившемся окне проверьте введенные ранее данные. В случае необходимости уточните адрес электронной почты, на который в течение двух часов будет направлена ссылка активации Личного кабинета. Ожидайте ссылки активации Личного кабинета юридического лица.
4. После получения на указанный при регистрации адрес электронной почты сообщения:
   • откройте сообщение с ссылкой активации Личного кабинета юридического лица;
   • перейдите по указанной ссылке.
5. Для предоставления доступа филиалам и другим обособленным подразделениям лицо, имеющее действующую доверенность с полными полномочиями должно завести сведения обособленных подразделений организации в разделе «Администрирование» сервиса «Личный кабинет юридического лица».

Фриланс-проекты › Настроить Firewall Настроить Firewall

Не могу Зарегистрировать личный кабинет на https://www.nalog.ru
Для ИП
С ключем

Выдает ошибку на последнем шаге

Проверка защищённого соединения с сервером Личного кабинета индивидуального предпринимателя.                 

Пишет вот такую фигню:

Проверка закончилась с ошибкой

Не удалось проверить возможность соединения с сервером. Попробуйте перейти по ссылке.

Уважаемый пользователь, выполните пожалуйста следующие действия:

1. Проверьте, не включен ли в системе Firewall и не используется ли прокси-сервер в сети, которые могут блокировать https-соединения. Также проверьте, не влияет ли ваш антивирус на попытку установления защищенного соединения с сервисом Личного кабинета ИП (для этого на время выполнения условий проверки антивирус необходимо отключить). Если после отключения антивируса все проверки выполняются успешно, значит адреса https://lkip.nalog.ru и https://lkipgost.nalog.ru нужно исключить из зоны проверки вашего антивируса (т.е. добавить в настройках антивируса в исключения). (Особенно это актуально для антивируса Avast)

2. Убедитесь что у вас не установлено более одного криптопровайдера для ГОСТ алгоритмов.

3. Скачайте последнюю актуальную версию вашего криптопровайдера с официального сайта с учетом вашей лицензии (например, если у вас КриптоПро CSP версии 3.6.7491, его нужно обновить до версии 3. 6.7777). Это актуально для всех версий КриптоПро 3.6, 3.9 и 4.0 и для всех операционных систем (Windows XP, Windows7, Windows 8, Windows 8.1). Для Windows 10 можно установить версии КриптоПро 3.9 либо КриптоПро 4.0. Актуальные версии КриптоПро можно найти на официальном сайте https://www.cryptopro.ru/products/csp/downloads Подобрать версию продукта можно на сайте разработчика по ссылке http://cryptopro.ru/products/csp/compare

4. Проверьте, что все условия для подключения к Личному кабинету соблюдены. (В том числе, что узлы https://lkip.nalog.ru и https://lkipgost.nalog.ru установлены в зону надежных узлов. Это можно проверить, если ваша версия браузера отображает уровень безопасности узла, надо включить в браузере отображение строки состояния (если не включено), при переходе по этому адресу в ней должна быть надпись «Надежный узел», другие надписи свидетельствуют о неверных настройках.
Также порты 80 и 443 должны быть открыты для отправки и приема данных из сети Интернет).
Ознакомьтесь с разделом «Вопрос-ответ», ссылка на который расположена в правом верхнем углу страницы Личного кабинета и страницей «Проверка выполнения условий доступа»

5. Включите в параметрах безопасности браузера режимы SSL 3.0, TLS 1.0, TLS 1.1 и TLS 1.2, режим SSL 2.0 должен быть выключен. Для этого зайдите в меню Сервис — Свойства обозревателя — закладка Дополнительно.

6. Очистите cookie и кэш браузера (ctrl+shift+del) (для очистки нужно выбрать все галочки)

7. Пройдите проверку условий доступа заново.

8. Если при проверке возникает ошибка, то перейдите в Личный кабинет по прямой ссылке.

9. Если при переходе по прямой ссылке возникнут проблемы, то сделайте скриншот полученной страницы так, чтобы были видны адресная строка и строка состояния браузера. Затем перейдите на тестовый сервер по адресу https://lk3-nalog.ru/ (это необходимо для проведения анализа возникающих проблем соединения с Личным кабинетом, адрес не предназначен для перехода на портал), сделайте скриншот и этой страницы.

Если ВСЕ вышеописанные действия не помогли решить проблему, то просим попробовать выполнить действия, описанные в Часто задаваемых вопросах, тематика «Доступ в Личный кабинет с помощью ЭП. «, подраздел «Не удается пройти последний пункт проверки выполнения условий доступа к Личному кабинету, а также не удается открыть главную страницу после перехода по ссылке «Перейти в Личный кабинет индивидуального предпринимателя»», а если проблему всё ещё решить не удалось, то просим сообщить нам о ней, создав обращение в службу технической поддержки по ссылке https://lkip.nalog.ru/support, в котором обязательно укажите:

1) Время (московское) и дату попытки подключения к серверу https://lkipgost.nalog.ru/lk

2) Внешний ip-адрес компьютера. Определить его можно, перейдя по ссылке (http://myip.ru)

3) Приложите 2 скриншота страниц: https://lkipgost.nalog.ru/lk и https://lk3-nalog.ru, сделанные в п. 9 с отображением строк адреса и состояния

4) Точную полную версию криптопровайдера, (например. у КриптоПро CSP она должна быть не менее 3.6.7777 (или, что то же самое, 3.6 R4))

5) Версию браузера (полную, можно узнать в меню Справка->О программе)

6) Версию операционной системы

7) Приложите экспортированный сертификат БЕЗ закрытого ключа (см. раздел «Часто задаваемые вопросы» или на странице составления обращения, ссылка «инструкция по выгрузке»)

8) Если при прохождении проверок в одном из пунктов показывается сообщение об ошибке, сделайте и приложите снимок экрана (скриншот) этой страницы с сообщением об ошибке

9) Приложите снимок экрана со страницей настроек браузера для зоны надежных узлов, на которой видно, что https://lkip.nalog.ru и https://lkipgost.nalog.ru добавлены в зону надежных узлов

10) Приложите снимок экрана со страницей дополнительных настроек браузера, на которой видно протоколы SSL и TLS (в меню Сервис — Свойства обозревателя — закладка Дополнительно)

11) Выполните стандартную команду Telnet ОС Windows для проверки доступности адреса lkipgost.nalog.ru через порт 443. Для этого наберите в Командной строке (включается через меню Пуск — Программы — Стандартные — Командная строка или сочетанием клавиш Win+R, затем набрать текст cmd и нажать клавишу ввод (Enter)) такую команду telnet lkipgost. nalog.ru 443 (имя команды telnet, за ним два параметра, имя хоста и номер порта, параметры команды разделены пробелом). После набора команды, выполните ее, нажав клавишу ввод. Приложите снимок экрана, на котором виден результат выполнения команды. Примечание — в некоторых версиях операционных систем команда Telnet может быть не активирована. Для её активации необходимо зайти в Панель управления и найти раздел «Программы и компоненты». Попав в него, в меню справа найти пункт «Включение или отключение компонентов Windows». Откроется окно «Компоненты Windows», в котором надо найти и отметить пункт «Клиент Telnet»

12) Скриншот вкладки «Настройки TLS» (утилиты КриптоПро CSP) со снятой галочкой в пункте «Не использовать устаревшие cipher suite-ы»

Собранную информацию пришлите, пожалуйста, в виде архивного файла.

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

Удаленный доступ через протокол WebDAV | Windows IT Pro/RE

Удобный способ доступа к внутренним файл-серверам компании

Чтобы организовать доступ сотрудников, находящихся за пределами предприятия, к внутренним файл-серверам, лучше всего воспользоваться встроенным протоколом Windows XP и Windows Server 2003, Web Distributed Authoring and Versioning (WebDAV), который обеспечивает безопасный доступ через приложение-посредник. Пример такого доступа — защищенный доступ Outlook 2003 к Exchange Server через HTTP-proxy. Реализовать WebDAV просто, так как протокол инкапсулирован в классическом HTML. Поэтому брандмауэры не являются препятствием для использования протокола, который совместим не только с платформой Windows, но и с другими операционными системами, в частности Mac OS. Для защиты WebDAV достаточно применить HTTP Secure (HTTPS).

Рассмотрим этапы подготовки удаленного доступа через WebDAV к папке на внутреннем файл-сервере. Основные компоненты — сервер Microsoft Internet Information Services (IIS) 6.0, файл-сервер, офисное сетевое соединение и клиентские компьютеры. Сервер IIS и файл-сервер не обязательно должны размещаться на одном компьютере. Также необходима система Windows 2003, подключенная к внутренней сети и доступная через Internet. Этот сервер называется WebDAV-сервером, так как он будет работать с IIS 6.0 и серверным модулем расширения WebDAV. Не беда, если WebDAV-сервер еще не подключен к Internet; однако его нужно защитить.

Доступ к серверу WebDAV через Internet

Способ доступа к серверу WebDAV через Internet зависит от текущего состояния среды и размеров предприятия. Обязательное условие — назначить IP-адрес или имя DNS и номер TCP-порта, с помощью которых удаленные пользователи будут обращаться к серверу WebDAV. Рассмотрим типичные сценарии. На малом предприятии единственное устройство, подключенное к Internet, — типовой широкополосный маршрутизатор/брандмауэр, но это не помешает организовать доступ с использованием WebDAV. Необходим IP-адрес, по которому удаленные пользователи будут обращаться к файл-серверу. Во-первых, следует выяснить, имеется ли у маршрутизатора статический IP-адрес. Если нет, то проще всего получить его у Internet-провайдера. Если статический IP-адрес получить нельзя, можно использовать DDNS. Большинство широкополосных маршрутизаторов совместимы с DDNS. Затем нужно решить проблему TCP-порта. Если для доступа к узлам за маршрутизатором уже применяется HTTPS, можно просто сделать в брандмауэре исключение для передачи входящих соединений в TCP-порт 443 внутреннего сервера, на котором выполняется IIS 6. 0 с WebDAV. На данном этапе порт открывать не следует; предварительно необходимо убедиться, что внутренний сервер готов к этому.

Если IIS-сервер еще не подключен к Internet, можно назначить файл-сервер WebDAV-сервером.

В более сложной сети, возможно, уже имеется система Windows 2003, подключенная к Internet напрямую или через брандмауэр, как описано выше. Не составит труда задействовать эту систему. Если сервер Windows 2003 уже работает с IIS, например для Microsoft Outlook Web Access (OWA), SharePoint или общедоступного Web-узла, можно создать виртуальный каталог в существующем Web-узле или подготовить новый узел. Различие в том, что при использовании существующего Web-узла для настройки клиентского доступа WebDAV нужно к имеющемуся URL-адресу Internet добавить имя виртуального каталога. Если создан новый узел, то для него может потребоваться новый номер TCP-порта. При доступе к существующему узлу через HTTPS с использованием стандартного HTTPS-порта 443 необходимо выбрать новый порт для клиентского доступа WebDAV. Если существующий узел настроен на использование порта 443, но никто не обращается к нему через HTTPS, можно изменить текущий порт Secure Sockets Layer (SSL). Если использовать в качестве SSL-порта какой-либо порт, кроме 443, то необходимо добавить к URL-адресу номер порта. Например, для домена с именем webdav.ultimatewindowssecurity.com URL-адрес будет https://webdav.ultimatewindowssecurity.com:XXXXX, где XXXXX — номер порта.

Настройка безопасного WebDAV

В следующих поэтапных инструкциях предполагается, что IIS и WebDAV устанавливаются на системе, отличной от файл-сервера. В этом случае достаточно установить IIS без активизации Active Server Pages (ASP) и любых других необязательных компонентов. После установки IIS следует открыть оснастку Internet Information Services (IIS6) Manager консоли Microsoft Management Console (MMC) (см. экран 1), развернуть папку Web Service Extensions и активизировать узел WebDAV. Чтобы максимально сузить поверхность атаки на IIS, не следует активизировать другие модули расширения.

Экран 1. Активизация WebDAV в IIS 6.0

Затем нужно настроить IIS для приема только проверенных, шифрованных соединений. Из оснастки IIS Manager консоли MMC следует открыть диалоговое окно Default Web Site Properties и выбрать вкладку Directory Security (экран 2). Прежде всего необходим сертификат SSL для сервера. Если в компании запущена служба Microsoft Certificate Services для домена, то запросить сертификат можно с помощью мастера. В противном случае потребуется купить сертификат в общедоступном удостоверяющем центре или создать сертификат с собственной подписью. В комплекте ресурсов Microsoft Windows Internet Information Server Resource Kit есть инструмент для генерации сертификатов с собственной подписью. Если имеется корпоративный удостоверяющий центр, необходимо щелкнуть на кнопке Server Certificate и пройти по операциям мастера Web Server Certificate Wizard. На странице Delayed or Immediate Request нужно выбрать пункт Send the request immediately to an online certification authority и щелкать на кнопке Next до тех пор, пока не появится страница Your Site?s Common Name. На ней требуется ввести имя DNS или IP-адрес для обращения удаленных пользователей к Web-узлу. Если введен IP-адрес и используется DHCP с DDNS, то сертификат при изменении IP-адреса окажется недействительным. Не следует указывать https:// или номер порта. В приведенном выше примере с URL необходимо ввести webdav.ultimatewindowssecurity.com. Нажимая Next, нужно перейти к странице SSL Port и ввести выбранный ранее TCP-порт, а затем щелкать на кнопке Next до появления кнопки Finish. После щелчка на ней сертификат SSL будет установлен. Вернувшись на вкладку Default Web Site Properties Directory Security, следует щелкнуть на кнопке Edit в разделе Secure communications, чтобы вызвать диалоговое окно Secure Communications и установить флажки Require secure channel (SSL) и Require 128-bit encryption.

Экран 2. Параметры вкладки Directory Security

На следующем этапе необходимо потребовать, чтобы все пользователи при обращении к серверу проходили проверку подлинности. На вкладке Directory Security следует щелкнуть Edit в разделе Authentication and access control. Сбросив флажок Enable anonymous access (экран 3), нужно установить флажок Basic authentication (password is sent in clear text). Не обязательно выбирать обычную проверку подлинности, если на предприятии имеются только клиенты Windows. Можно не обращать внимания на предупреждение о простом тексте от IIS — шифрование SSL уже активизировано. Стандартный домен следует настроить в соответствии с параметрами домена, в котором размещены учетные записи удаленных пользователей; в результате пользователям не придется добавлять перед своими именами domain name. Вид диалогового окна Authentication Methods должен быть похож на экран 3.

Экран 3. Правильно настроенные параметры Home Directory

Настраиваем IIS на общедоступную папку

Всякий раз, когда устанавливается новый IIS-сервер, создается виртуальный каталог на существующем Web-узле или новый Web-узел на имеющемся IIS-сервере; необходимо настроить IIS на соответствующую папку файл-сервера, в которую будут направляться запросы от URL-адреса WebDAV. Если создан узел или виртуальный каталог в существующем узле, то IIS предоставляет возможность указать папку, которая содержит информацию для этого каталога или узла. Поскольку используется экземпляр IIS, выделенный для WebDAV, необходимо только связать корневой каталог выбираемого по умолчанию Web-узла с файл-сервером. В диспетчере IIS Manager следует вернуться к Default Web Site Properties и выбрать вкладку Home Directory, затем установить флажок A share located on another computer и ввести в текстовом поле Network directory путь в формате Universal Naming Convention (UNC) для общей папки, к которой предстоит обращаться удаленным пользователям (экран 4).

Необходимо убедиться, что IIS олицетворяет текущего пользователя перед доступом к файл-серверу. Следует щелкнуть на кнопке Connect As… и установить флажок Always use the authenticated user?s credentials when validating access to the network directory. Чтобы пользователи могли получать, отправлять и просматривать файлы в папке через WebDAV, нужно установить флажки Read, Write и Directory browsing на вкладке Home Directory (экран 4). Эти флажки определяют только операции WebDAV, которые может запросить пользователь. Файл-сервер применяет разрешения NTFS для доступа к файлам так, как будто пользователь подключен локально. Остальные параметры на вкладке Home Directory активизировать не нужно, а параметру Execute permissions следует присвоить значение, обеспечивающее максимально надежную защиту.

Экран 4. Правильно настроенные методы Authentication Methods

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

Активизация пользователей

Теперь остается лишь активизировать удаленных пользователей. Для этого нужно создать ярлык Add Network Place для пользователей, чтобы они могли получить доступ в My Network Places на своих клиентских компьютерах. Затем каждому пользователю необходимо обратиться в My Network Places, дважды щелкнуть на ярлыке Add Network Place и ввести URL-адрес узла WebDAV. При первом обращении к ярлыку в My Network Places программа Windows Explorer запрашивает учетные данные; впоследствии пользователи получают доступ к файл-серверу как к обычной общей папке.

Проблемы безопасности

Насколько безопасен этот метод? Удаленный доступ через WebDAV сопоставим по защищенности с VPN-доступом на основе пароля пользователя. Единственное различие — увеличенная площадь атаки WebDAV из-за открытого порта 443. Однако, чтобы воспользоваться HTTP для проникновения в систему, взломщикам требуется успешно пройти проверку подлинности. Чтобы усилить безопасность, можно внести элемент неизвестности, изменив номер HTTPS-порта Web-узла с 443 на более высокий. Следует иметь в виду, что при этом ограничивается доступ удаленных пользователей, находящихся за брандмауэром другой компании со строгими ограничениями для исходящих соединений. Лучший способ еще более надежно защитить любой тип Web-соединений — требовать клиентские сертификаты наряду с аутентификацией с применением пароля. Для получения сертификата удаленным пользователям достаточно пройти по нескольким Web-страницам.

Рэнди Франклин Смит — редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: [email protected]

Поделитесь материалом с коллегами и друзьями

Порт 443 — все, что вам нужно знать о HTTPS 443

Знаете ли вы, что более 95% запросов через Chrome обслуживаются с использованием HTTPS-соединения через порт 443? Вот что еще вам следует знать о порте 443

В свете постоянно увеличивающегося числа кибератак обеспечение безопасного просмотра стало приоритетной задачей для владельцев веб-сайтов, компаний и Google. Благодаря поддержке почти всех других основных браузеров технический гигант помечает веб-сайты без установленного сертификата SSL / TLS как «Небезопасные.Но что вы можете сделать, чтобы удалить это предупреждение системы безопасности (или вообще предотвратить его появление на вашем веб-сайте)? Используйте инструмент, который позволяет подключаться по безопасному протоколу через порт 443.

Установка сертификата SSL на веб-сервер, на котором размещен сайт, к которому вы пытаетесь получить доступ, устранит это сообщение с предупреждением о небезопасном соединении. Сертификат SSL / TLS устанавливает зашифрованный безопасный канал связи между браузером клиента и сервером. Это означает, что при следующем посещении сайта соединение будет установлено по HTTPS с использованием порта 443.

Что такое порт 443?

Порт — это виртуальный нумерованный адрес, который используется в качестве конечной точки связи протоколами транспортного уровня, такими как UDP (протокол пользовательской диаграммы) или TCP (протокол управления передачей). Сетевые порты направляют трафик в нужные места, т. Е. Помогают задействованным устройствам определить, какая услуга запрашивается.

Например, порт, который отвечает за обработку всего незашифрованного веб-трафика HTTP, — это порт 80. Когда мы используем сертификат TLS, канал связи между браузером и сервером зашифровывается для защиты всех обменов конфиденциальными данными.

Все такие безопасные передачи выполняются с использованием порта 443, стандартного порта для трафика HTTPS. Однако порт 443 HTTPS также поддерживает доступность сайтов через HTTP-соединения. Если сайт использует HTTPS, но недоступен через порт 443 по какой-либо причине, порт 80 будет загружать веб-сайт с поддержкой HTTPS.

Как работает HTTPS?

Итак, что происходит за кулисами и как на самом деле работает HTTPS? Давай выясним!

Когда ваш клиентский браузер отправляет запрос на веб-сайт по защищенному каналу связи, любой происходящий обмен — например, учетные данные вашей учетной записи (если вы пытаетесь войти на сайт) — остается зашифрованным. Это означает, что злоумышленник не сможет прочитать его в сети. Это происходит потому, что исходные данные передаются через алгоритм шифрования, который генерирует зашифрованный текст, который затем отправляется на сервер.

Даже если трафик будет перехвачен, у злоумышленника останутся искаженные данные, которые можно преобразовать в читаемую форму только с помощью соответствующего ключа дешифрования. Вот визуальное представление того, как работает этот процесс:

Визуальная разбивка того, как HTTPS-соединение шифрует трафик через порт 443.

HTTP через соединение SSL / TLS использует шифрование с открытым ключом (где есть два ключа — открытый и частный) для распространения общего симметричного ключа, который затем используется для массовой передачи. Соединение TLS обычно использует порт HTTPS 443. В качестве альтернативы клиент может также отправить запрос, например STARTTLS, на обновление с незашифрованного соединения на зашифрованное.

Прежде чем соединение может быть установлено, браузеру и серверу необходимо выбрать параметры соединения, которые могут быть развернуты во время связи. Они приходят к соглашению, выполняя рукопожатие SSL / TLS:

• Процесс начинается с обмена приветственными сообщениями между клиентским браузером и веб-сервером.
• Как только начинается согласование протокола, передаются стандарты шифрования, поддерживаемые двумя сторонами, и сервер совместно использует свой сертификат.
• Теперь у клиента есть открытый ключ сервера, полученный из этого сертификата. Он проверяет действительность сертификата сервера перед использованием открытого ключа для генерации предварительного главного секретного ключа.Затем предварительный секрет шифруется открытым ключом и передается серверу.
• На основе значения предварительного главного секретного ключа обе стороны независимо вычисляют симметричный ключ.
• Обе стороны отправляют сообщение об изменении спецификации шифра, указывающее, что они вычислили симметричный ключ, и при массовой передаче данных будет использоваться симметричное шифрование.

На этом рисунке представлена ​​визуальная разбивка процесса подтверждения TLS. Он демонстрирует взаимодействия, которые происходят между клиентом и сервером для установления безопасного зашифрованного соединения.

Что защищает порт HTTPS 443 и зачем он нам нужен?

HTTPS — это протокол прикладного уровня в четырехуровневой модели TCP / IP и семиуровневой модели взаимодействия открытых систем, или для краткости так называемой модели OSI. (Не волнуйтесь, мы не будем втянуты в утомительный монолог о том, как работают модели TCP / IP и OSI.) Вкратце, это означает, что это гарантирует, что ваш интернет-провайдер (или кто-либо другой в сети ) не может читать или вмешиваться в диалог, который происходит между вашим браузером и сервером.

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

Когда веб-сайт использует сертификат SSL / TLS, рядом с URL-адресом в адресной строке появляется блокировка, указывающая на его безопасность. Однако эта безопасная блокировка часто может вводить в заблуждение, потому что, хотя канал связи зашифрован, нет гарантии, что злоумышленник не контролирует сайт, к которому вы подключаетесь. Кроме того, несколько других уязвимостей безопасности могут привести к компрометации данных, и только использование сертификатов SSL / TLS не может защитить ваш сервер или компьютер от них.Например, ваш компьютер по-прежнему может загружать вредоносное ПО из-за атак с попутной загрузкой, или данные, которые вы вводите на сайте, могут быть извлечены из-за инъекционной атаки на сайт.

Чтобы избежать каких-либо предположений о том, что HTTPS может защитить, а что не может, важно отметить, что преимущества безопасности не распространяются по уровням. Под этим мы подразумеваем то, что, хотя HTTPS шифрует данные прикладного уровня, и хотя они остаются защищенными, на сетевом или транспортном уровне добавляется дополнительная информация (например, продолжительность соединения и т. Д.).) могут быть обнаружены. Когда ваш браузер устанавливает HTTPS-соединение, TCP-запрос отправляется через порт 443. Однако после установления соединения, хотя данные уровня приложения (сообщение, которым обмениваются клиент и сервер) зашифрованы, это не защищает пользователей. против атак по отпечаткам пальцев.

Помимо самого разговора, злоумышленник может прочитать определенные типы информации, в том числе:

• IP-адрес и местоположение пользователя,
• Размер сообщения,
• Веб-сайт, к которому выполняется подключение, и
• Частота этих подключений.

И последнее важное замечание: хотя это распространенное заблуждение, использование HTTPS-порта 443 не обеспечивает анонимного просмотра.

Резюме по теме порта HTTPS 443

Независимо от того, являетесь ли вы владельцем веб-сайта или его посетителем, просмотр незашифрованного соединения, по которому ваши данные передаются в виде открытого текста и могут быть прочитаны любым, кто перехватывает сообщения в сети, представляет серьезную угрозу безопасности. Хотя преимущества безопасности, обеспечиваемые подключением SSL / TLS через HTTPS-порт 443, ограничены, это решительный шаг на пути к более безопасному серфингу в Интернете.

Существует несколько авторитетных центров сертификации (ЦС), которые могут выдавать цифровые сертификаты в зависимости от ваших конкретных требований и количества доменов, которые вы хотите защитить. Кроме того, еще одним следствием инициативы Google по созданию полностью зашифрованного Интернета является способ ранжирования веб-сайтов. С 2014 года Google использует HTTPS в качестве ранжирующего сигнала для своих поисковых алгоритмов. А поскольку большинство пользователей сети избегают небезопасных веб-сайтов, это означает, что сертификаты SSL стали обязательными.

Что такое порт 443?

Говоря о компьютерах, существует множество различных типов портов. Сетевые порты не являются физическими портами на компьютере или каком-либо устройстве. Вместо этого они виртуальные. Сетевые порты — это пронумерованные адреса, такие как порт 80, порт 443, порт 22 и порт 465, которые компьютеры могут использовать для направления нужного сетевого трафика в нужное место.

Для чего нужны порты?

Когда вы заходите на веб-сайт, ваш компьютер обращается к серверу, на котором он находится.Он ищет соединение через порт HTTP или HTTPS, потому что именно они связаны с веб-трафиком. Сервер установит соединение с любым портом и отправит обратно информацию о веб-сайте, которую ваш компьютер получит через тот же порт.

Pixabay

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

Для чего нужен порт 443?

Вы когда-нибудь видели значок замка рядом с URL-адресом в адресной строке браузера? Может быть, вы даже заметили «https: //», а не «http: //» в начале URL-адреса веб-сайта? В обоих случаях вы подключились к веб-сайту, используя безопасный протокол HTTPS вместо HTTP.

Pixabay

HTTPS устанавливает зашифрованное соединение с веб-сервером, а не незашифрованное соединение HTTP.Поскольку HTTP и HTTPS — это два разных протокола, они используют два разных порта. HTTP доступен на порту 80, а HTTPS — на порту 443. Когда вы подключаетесь к веб-сайту, имя которого начинается с «https: //» или видите значок замка, вы подключаетесь к этому веб-серверу через порт 443.

Почему важен порт 443?

Порт 443 — это стандартный порт для всего защищенного HTTP-трафика, что означает, что он абсолютно необходим для большинства современных веб-операций. Шифрование необходимо для защиты информации, поскольку она проходит между вашим компьютером и веб-сервером.Это шифрование предотвращает отслеживание такими вещами, как ваши пароли и конфиденциальная информация, отображаемая на страницах (например, банковская информация). Благодаря обычному протоколу HTTP через порт 80 все, чем вы обмениваетесь между вашим компьютером и веб-сайтом, может увидеть любой желающий в виде обычного текста.

Порт 443 также позволяет веб-сайтам быть доступными как по HTTP, так и по HTTPS. Большинство веб-сайтов настроены для работы с HTTPS через порт 443, но если он по какой-то причине недоступен, веб-сайт все равно будет работать через HTTPS через порт 80.Раньше не все веб-браузеры поддерживали HTTPS, а это означало, что он не был общедоступным. Однако теперь большинство основных браузеров начинают отмечать веб-сайты, которые не предлагают трафик HTTPS, как небезопасные.

Как использовать порт 443

Когда вы просматриваете веб-страницы, вам обычно не нужно ничего делать для подключения через порт 443. Вы можете вручную ввести «https: //» перед URL-адресами, которые вы посещаете, но обычно в этом нет необходимости.

Если вы хотите убедиться, что используете HTTPS, когда это возможно, изучите надстройку HTTPS Everywhere от Electronic Frontier Foundation (EFF).Он доступен для Chrome, Firefox и Opera.

Администраторам серверов необходимо будет особенно внимательно следить за тем, чтобы их веб-сайты были доступны через порт 443. Вам необходимо настроить приложения веб-сервера (например, Apache или Nginx) для обслуживания своего веб-сайта через порт 443; чтобы шифрование работало, вам понадобится сертификат шифрования. Вы можете приобрести их на своем веб-хостинге или в любом количестве центров сертификации. LetsEncrypt — еще один отличный вариант для бесплатных сертификатов шифрования SSL.

Спасибо, что сообщили нам!

Расскажите, почему!

Другой Недостаточно подробностей Сложно понять

Проброс портов для новичков. Прежде чем приступить к экспедированию портов… | Стив Дэвис

Перенаправление портов

Прежде чем перейти к перенаправлению портов, позвольте мне объяснить несколько основных сетевых концепций. Каждое устройство, подключенное к сети, имеет уникальный идентификатор — IP-адрес. Этот адрес используется для идентификации устройства и связи с ним.

Рассмотрим вашу домашнюю сеть.У вас, вероятно, будет установлен маршрутизатор, подключенный к сети интернет-провайдера (ISP), такого как Verizon или Comcast. Маршрутизатор имеет IP-адрес — уникальный общедоступный IP-адрес, используемый для идентификации устройства и связи с Интернетом. Вы подключаете к этому роутеру различные устройства — либо с помощью кабеля Ethernet, либо с помощью Wi-Fi. У этих устройств есть собственный IP-адрес? Да, это так. Но это частные адреса, то есть эти адреса используются для идентификации устройства в вашей домашней сети.Эти IP-адреса отличаются от общедоступного IP-адреса вашего маршрутизатора, и устройства за пределами вашей домашней сети не могут связываться с вашими устройствами, используя только частный IP-адрес. Когда одно из устройств хочет связаться с Интернетом (устройства за пределами вашей домашней сети), маршрутизатор заменяет частный IP-адрес своим общедоступным IP-адресом для исходящего трафика и заменяет общедоступный адрес конкретным частным IP-адресом для всего входящего трафика. Это сопоставление называется преобразованием сетевых адресов (NAT).

Давайте внимательнее рассмотрим устройство, например ноутбук, подключенное к маршрутизатору.На нем может быть запущено несколько процессов или служб, например SQL-сервер, git-сервер, TCP, FTP и т. Д. Так же, как устройству нужен уникальный идентификатор, каждая служба должна быть идентифицирована для обеспечения связи. Номера портов помогают идентифицировать услуги. Всякий раз, когда сервису необходимо обмениваться данными, номер порта помогает определить правильный пункт назначения / источник на устройстве и помогает в соответствующей передаче данных. Проще говоря, IP-адрес — это адрес устройства в сети, а порт — это адрес службы на устройстве.Комбинация IP-адреса и номера порта обеспечивает связь, идентифицируя источник / место назначения конкретной услуги на конкретном устройстве. С большинством популярных сервисов связан порт по умолчанию, например порт 80 для HTTP, порт 443 для https, порт 25 для SMTP, порт 20 для FTP и т. Д.

Перенаправление портов — это процесс перенаправления связи, адресованной к одна комбинация IP-адреса / порта на другую комбинацию адреса / порта. Но зачем нам переадресация портов? Переадресация портов позволяет сделать устройство, подключенное к вашей частной сети, доступным из Интернета.Рассмотрим, например, Gitstorage — локальный сервер git для безопасного хранения исходного кода. Если вы подключили его к своей домашней сети, вы можете получить к нему доступ, используя частный IP-адрес, и работать без каких-либо дополнительных настроек.

Однако что происходит, когда вы идете выпить кофе в Starbucks и решите получить доступ к gitstorage? Как получить доступ к своему устройству через Wi-Fi Starbucks? Чтобы это произошло, вы должны настроить переадресацию портов. Домашний маршрутизатор должен быть настроен для направления всего входящего трафика с порта 443 на gitstorage.TCP-порт 443 — это стандартный TCP-порт, используемый для веб-сайта, использующего SSL. После настройки gitstorage станет доступен в Интернете, и вы сможете получить к нему доступ за пределами своей домашней сети. Всякий раз, когда на ваш маршрутизатор отправляется запрос (с использованием общедоступного IP-адреса) с портом 443 в качестве пункта назначения, ваш маршрутизатор направляет этот трафик непосредственно на ваше устройство. Вы можете безопасно войти в систему и продолжить разработку. Чтобы уменьшить открытость для общественности, было бы лучше использовать нестандартный порт при переадресации портов.Это позволит избежать опасности со стороны сканеров в Интернете, которые постоянно пытаются получить доступ к устройствам на стандартных портах.

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

Gitstorage — идеальное устройство для людей, разрабатывающих новое программное обеспечение или рассматривающих альтернативы облачным репозиториям git.

Как открыть порты в брандмауэре — IBM Watson Media

Компьютерные порты и сетевые порты

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

Открытие сетевых портов

При открытии портов в сети первое, что вам нужно сделать, это открыть страницу конфигурации маршрутизатора. Это можно сделать, набрав IP-адрес вашего маршрутизатора в браузере. IP-адрес вашего маршрутизатора обычно имеет значение по умолчанию в зависимости от марки маршрутизатора, который вы используете, но вы всегда можете найти его, набрав «ipconfig» в окне командной строки вашего компьютера с Windows. На компьютере Mac вы можете найти свой адрес маршрутизатора, открыв меню системных настроек, перейдя к значку сети, нажав кнопку дополнительных настроек, а затем выбрав вкладку TCP / IP.В этом окне вы увидите IP-адрес вашего роутера.

После того, как вы получите IP-адрес вашего маршрутизатора, введите его в браузере. Вы попадете на страницу конфигурации вашего маршрутизатора. Вам будет предложено ввести имя пользователя и пароль. Значения по умолчанию для них обычно — «admin» и «admin», но вам нужно будет проконсультироваться в центре поддержки компании, которая сделала ваш маршрутизатор, для подтверждения.

Конкретные шаги в дальнейшем будут зависеть от марки вашего маршрутизатора. Вам нужно будет открыть раздел «переадресация портов» или раздел «Приложения и игры».Затем вам нужно будет нажать «добавить новое правило».

См. Наш документ о необходимых открытых портах для использования IBM Watson Media.

для ПК

Чтобы открыть порт (или набор портов) в брандмауэре Windows, вам нужно открыть панель управления и перейти на вкладку настроек брандмауэра Windows на вкладке «Безопасность». Выберите Advanced Settings.

Вы увидите, что в окне брандмауэра слева отображается список правил. В списке выберите Правила для входящих подключений, чтобы отобразить раздел правил для входящих подключений.Затем выберите «Новое правило». Откроется Мастер создания нового правила для входящих подключений. Выберите правило порта для создания, затем выберите TCP или UDP в качестве типа порта (см. Нашу статью о брандмауэре для конкретного типа порта). Выберите конкретные локальные порты и введите номер порта, который вы хотите открыть.

После этого вы можете разрешить или заблокировать определенный порт. Для IBM Watson Media выберите разрешить. Затем назовите новое правило порта и нажмите «Готово».

для Mac

Брандмауэры

Mac работают немного иначе, обеспечивая доступ к определенным приложениям.Если вам нужно открыть определенные порты на Mac, вы можете сделать это через Терминал. В противном случае вы можете разрешить доступ определенным приложениям через брандмауэр через меню системных настроек. Перейдите в Системные настройки и выберите вкладку Безопасность и конфиденциальность.

Отсюда нажмите вкладку «Брандмауэр» и нажмите кнопку «Параметры брандмауэра». Затем вы попадете на страницу, на которой показаны приложения, которым разрешен доступ через ваш брандмауэр, и вы сможете добавлять новые приложения в список, щелкнув значок плюса.

Сетевые порты для клиентов и потока почты в Exchange

• 22.03.2021
• Читать 9 минут

В этой статье

В этом разделе представлена ​​информация о сетевых портах, которые используются Exchange Server 2016 и Exchange Server 2019 для связи с почтовыми клиентами, почтовыми серверами в Интернете и другими службами, внешними по отношению к вашей локальной организации Exchange.Прежде чем мы перейдем к этому, необходимо понять следующие основные правила:

• Мы не поддерживаем ограничение или изменение сетевого трафика между внутренними серверами Exchange, между внутренними серверами Exchange и внутренними серверами Lync или Skype для бизнеса, а также между внутренними серверами Exchange и внутренними контроллерами домена Active Directory в любых и всех типах топологий. Если у вас есть брандмауэры или сетевые устройства, которые потенциально могут ограничивать или изменять этот вид внутреннего сетевого трафика, вам необходимо настроить правила, разрешающие свободный и неограниченный обмен данными между этими серверами: правила, разрешающие входящий и исходящий сетевой трафик на любом порту (включая случайный RPC порты) и любой протокол, который никогда не изменяет биты на проводе.

• Пограничные транспортные серверы почти всегда расположены в сети периметра, поэтому ожидается, что вы ограничите сетевой трафик между пограничным транспортным сервером и Интернетом, а также между пограничным транспортным сервером и вашей внутренней организацией Exchange. Эти сетевые порты описаны в этом разделе.

• Ожидается, что вы ограничите сетевой трафик между внешними клиентами и службами и своей внутренней организацией Exchange. Также нормально, если вы решите ограничить сетевой трафик между внутренними клиентами и внутренними серверами Exchange.Эти сетевые порты описаны в этом разделе.

Сетевые порты, необходимые для клиентов и услуг

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

Примечания:

• Назначением этих клиентов и служб являются службы клиентского доступа на сервере почтовых ящиков. В Exchange 2016 и Exchange 2019 клиентский доступ (интерфейс) и внутренние службы устанавливаются вместе на одном сервере почтовых ящиков.Для получения дополнительной информации см. Архитектура протокола клиентского доступа.

• Хотя на схеме показаны клиенты и службы из Интернета, концепции для внутренних клиентов одинаковы (например, клиенты в лесу учетных записей, обращающиеся к серверам Exchange в лесу ресурсов). Точно так же в таблице нет исходного столбца, потому что источником может быть любое расположение, внешнее по отношению к организации Exchange (например, Интернет или лес учетных записей).

• Пограничные транспортные серверы не участвуют в сетевом трафике, связанном с этими клиентами и службами.

Назначение	Порты	Комментарии
Зашифрованные веб-соединения используются следующими клиентами и службами: • Служба автообнаружения • Exchange ActiveSync • Веб-службы Exchange (EWS) • Распространение автономной адресной книги (OAB) • Outlook Anywhere (RPC через HTTP) ) • Outlook MAPI через HTTP • Outlook в Интернете (ранее известный как Outlook Web App)	443 / TCP (HTTPS)	Дополнительные сведения об этих клиентах и ​​службах см. В следующих разделах: • Служба автообнаружения в Exchange Server • Exchange ActiveSync • Справочник EWS для Exchange • Автономные адресные книги в Exchange Server • Outlook Anywhere • MAPI через HTTP в Сервер Exchange
Незашифрованные веб-соединения используются следующими клиентами и службами: • Публикация календаря в Интернете • Outlook в Интернете (перенаправление на 443 / TCP) • Автообнаружение (откат, когда 443 / TCP недоступен)	80 / TCP (HTTP)	По возможности мы рекомендуем использовать зашифрованные веб-соединения на 443 / TCP, чтобы защитить данные и учетные данные.Однако вы можете обнаружить, что некоторые службы необходимо настроить для использования незашифрованных веб-подключений по 80 / TCP к службам клиентского доступа на серверах почтовых ящиков. Дополнительные сведения об этих клиентах и ​​службах см. В следующих разделах: • Включение публикации календаря в Интернете • Служба автообнаружения в Exchange Server
Клиенты IMAP4	143 / TCP (IMAP), 993 / TCP (безопасный IMAP)	IMAP4 по умолчанию отключен. Дополнительные сведения см. В разделе POP3 и IMAP4 в Exchange Server. Служба IMAP4 в службах клиентского доступа на сервере почтовых ящиков прокси-серверы подключений к внутренней службе IMAP4 на сервере почтовых ящиков.
Клиенты POP3	110 / TCP (POP3), 995 / TCP (безопасный POP3)	POP3 по умолчанию отключен. Дополнительные сведения см. В разделе POP3 и IMAP4 в Exchange Server. Служба POP3 в службах клиентского доступа на сервере почтовых ящиков проксирует подключения к внутренней службе POP3 на сервере почтовых ящиков.
SMTP-клиенты (аутентифицированные)	587 / TCP (аутентифицированный SMTP)	Полученный соединитель по умолчанию с именем «Клиентский интерфейс <имя сервера> » в транспортной службе переднего плана прослушивает прошедшие проверку подлинности отправления клиента SMTP через порт 587. Примечание : Если у вас есть почтовые клиенты, которые могут отправлять только аутентифицированную электронную почту SMTP через порт 25, вы можете изменить привязки сетевого адаптера клиентского соединителя приема, чтобы также прослушивать аутентифицированные отправления электронной почты SMTP через порт 25.

Сетевые порты, необходимые для потока почты

Как почта доставляется в вашу организацию Exchange и из нее, зависит от топологии Exchange. Наиболее важным фактором является наличие у вас подписанного пограничного транспортного сервера, развернутого в вашей сети периметра.

Сетевые порты, необходимые для потока почты (без пограничных транспортных серверов)

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

Назначение	Порты	Источник	Пункт назначения	Комментарии
Входящая почта	25 / TCP (SMTP)	Интернет (любой)	Сервер почтовых ящиков	Соединитель получения по умолчанию с именем «Default Frontend <имя сервера почтовых ящиков> » в службе транспорта переднего плана прослушивает анонимную входящую почту SMTP на порту 25. Почта ретранслируется из внешней транспортной службы в транспортную службу на сервере почтовых ящиков с помощью неявного и невидимого внутриорганизационного соединителя отправки, который автоматически маршрутизирует почту между серверами Exchange в одной организации. Дополнительные сведения см. В разделе Неявные соединители отправки.
Исходящая почта	25 / TCP (SMTP)	Сервер почтовых ящиков	Интернет (любой)	По умолчанию Exchange не создает никаких соединителей отправки, которые позволяют отправлять почту в Интернет.Соединители отправки необходимо создавать вручную. Дополнительные сведения см. В разделе Создание соединителя отправки для отправки почты в Интернет.
Исходящая почта (если проксируется через службу транспорта переднего плана)	25 / TCP (SMTP)	Сервер почтовых ящиков	Интернет (любой)	Исходящая почта передается через службу транспорта переднего плана только в том случае, если соединитель отправки настроен с прокси-сервером через сервер клиентского доступа в центре администрирования Exchange или -FrontEndProxyEnabled $ true в командной консоли Exchange. В этом случае соединитель приема по умолчанию с именем «Outbound Proxy Frontend <Имя сервера почтовых ящиков> » в транспортной службе переднего плана прослушивает исходящую почту от транспортной службы на сервере почтовых ящиков. Дополнительные сведения см. В разделе Настройка соединителей отправки для прокси-сервера исходящей почты.
DNS для разрешения имен следующего почтового перехода (без изображения)	53 / UDP, 53 / TCP (DNS)	Сервер почтовых ящиков	DNS-сервер	См. Раздел «Разрешение имен» в этом разделе.

Сетевые порты, необходимые для потока почты с пограничными транспортными серверами

Подписанный пограничный транспортный сервер, установленный в вашей сети периметра, влияет на поток почты следующим образом:

• Исходящая почта из организации Exchange никогда не проходит через транспортную службу переднего плана на серверах почтовых ящиков. Почта всегда проходит от транспортной службы на сервере почтовых ящиков подписанного сайта Active Directory на пограничный транспортный сервер (независимо от версии Exchange на пограничном транспортном сервере).

• Входящая почта передается с пограничного транспортного сервера на сервер почтовых ящиков на подписанном сайте Active Directory. В частности:

  • Почта с пограничного транспортного сервера Exchange 2013 или более поздней версии сначала поступает в транспортную службу переднего плана, а затем передается в транспортную службу на сервере почтовых ящиков Exchange 2016 или Exchange 2019.

  • В Exchange 2016 почта с пограничного транспортного сервера Exchange 2010 всегда доставляет почту непосредственно в транспортную службу на сервере почтовых ящиков Exchange 2016.Обратите внимание, что сосуществование с Exchange 2010 не поддерживается в Exchange 2019.

Для получения дополнительной информации см. Почтовый поток и транспортный конвейер.

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

Назначение	Порты	Источник	Пункт назначения	Комментарии
Входящая почта — из Интернета на пограничный транспортный сервер	25 / TCP (SMTP)	Интернет (любой)	Пограничный транспортный сервер	Соединитель приема по умолчанию с именем «Внутренний соединитель приема по умолчанию <имя пограничного транспортного сервера> » на пограничном транспортном сервере прослушивает анонимную почту SMTP на порту 25.
Входящая почта — пограничный транспортный сервер для внутренней организации Exchange	25 / TCP (SMTP)	Пограничный транспортный сервер	Серверы почтовых ящиков на подписанном сайте Active Directory	Соединитель отправки по умолчанию с именем «EdgeSync — Inbound to <имя сайта Active Directory> » ретранслирует входящую почту через порт 25 на любой сервер почтовых ящиков на подписанном сайте Active Directory. Дополнительные сведения см. В разделе Соединители отправки, автоматически создаваемые пограничной подпиской. Соединитель получения по умолчанию с именем «Default Frontend <Имя сервера почтовых ящиков> » в транспортной службе переднего плана на сервере почтовых ящиков прослушивает всю входящую почту (включая почту от Exchange 2013 или более поздних пограничных транспортных серверов) на порту 25.
Исходящая почта — внутренняя организация Exchange на пограничный транспортный сервер	25 / TCP (SMTP)	Серверы почтовых ящиков на подписанном сайте Active Directory	Пограничные транспортные серверы	Исходящая почта всегда обходит службу транспорта переднего плана на серверах почтовых ящиков. Почта ретранслируется из транспортной службы на любом сервере почтовых ящиков на подписанном сайте Active Directory на пограничный транспортный сервер с помощью неявного и невидимого внутриорганизационного соединителя отправки, который автоматически маршрутизирует почту между серверами Exchange в одной организации. Соединитель получения по умолчанию с именем «Внутренний соединитель получения по умолчанию <имя пограничного транспортного сервера> » на пограничном транспортном сервере прослушивает почту SMTP на порту 25 от транспортной службы на любом сервере почтовых ящиков на подписанном сайте Active Directory.
Исходящая почта — пограничный транспортный сервер в Интернет	25 / TCP (SMTP)	Пограничный транспортный сервер	Интернет (любой)	Соединитель отправки по умолчанию с именем «EdgeSync — <имя сайта Active Directory> в Интернет» ретранслирует исходящую почту через порт 25 с пограничного транспортного сервера в Интернет.
Синхронизация EdgeSync	50636 / TCP (безопасный LDAP)	Серверы почтовых ящиков на подписанном сайте Active Directory, которые участвуют в синхронизации EdgeSync	Пограничные транспортные серверы	Когда пограничный транспортный сервер подписан на сайт Active Directory, все серверы почтовых ящиков, существующие на сайте в момент , участвуют в синхронизации EdgeSync.Однако любые серверы почтовых ящиков, которые вы добавляете позже, не автоматически участвуют в синхронизации EdgeSync.
DNS для разрешения имен следующего почтового перехода (без изображения)	53 / UDP, 53 / TCP (DNS)	Пограничный транспортный сервер	DNS-сервер	См. Раздел «Разрешение имен» далее в этом разделе.
Обнаружение открытого прокси-сервера в репутации отправителя (без изображения)	см. Комментарии	Пограничный транспортный сервер	Интернет	По умолчанию репутация отправителя (агент анализа протокола) использует обнаружение открытого прокси-сервера в качестве одного из критериев для расчета уровня репутации отправителя (SRL) исходного сервера обмена сообщениями.Дополнительные сведения см. В разделах «Репутация отправителя» и «Агент анализа протокола». Обнаружение открытого прокси-сервера использует следующие протоколы и порты TCP для тестирования исходных серверов обмена сообщениями для открытого прокси: • SOCKS4, SOCKS5: 1081, 1080 • Wingate, Telnet, Cisco: 23 • HTTP CONNECT, HTTP POST: 6588, 3128 , 80 Кроме того, если ваша организация использует прокси-сервер для управления исходящим интернет-трафиком, вам необходимо определить имя, тип и TCP-порт прокси-сервера, который репутация отправителя требует для доступа к Интернету для обнаружения открытого прокси-сервера. Кроме того, вы можете отключить обнаружение открытого прокси-сервера в репутации отправителя. Для получения дополнительной информации см. Процедуры репутации отправителя.

Разрешение имени

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

Сетевые порты, необходимые для гибридных развертываний

Сетевые порты, необходимые для организации, использующей как локальную версию Exchange, так и Microsoft 365 или Office 365, рассматриваются в протоколах, портах и ​​конечных точках гибридного развертывания.

Сетевые порты, необходимые для единой системы обмена сообщениями в Exchange 2016

Сетевые порты, необходимые для единой системы обмена сообщениями в Exchange 2013 и Exchange 2016, описаны в разделе Протоколы, порты и службы единой системы обмена сообщениями.

Настройка связи с Интернетом

В предыдущей главе мы обсуждали, как настроить SSL для защиты трафика между клиентами (браузерами, мобильными устройствами и т. Д.) И Tableau Server. Настройка SSL — это всегда хорошая идея, но необходимо , если вы собираетесь разрешить клиентам из-за пределов вашей сети (то есть из общедоступного Интернета) доступ к Tableau Server. Если вы пропустили эту главу, но можете разрешить людям доступ к Tableau Server из-за пределов вашей сети, вернитесь и просмотрите ее.На самом деле, вы абсолютно не должны разрешать доступ к серверу, если у вас не настроен SSL.

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

Пора позвонить своему другу в области ИТ

В отличие от большинства других глав Tableau Server: Everybody’s Install Guide , где вы можете завершить настройку сервера с минимальной помощью ИТ-специалиста, мы написали эту главу для ИТ-специалистов.Мы попытались описать концепции способами, которым, как мы надеемся, смогут следовать все, но настройка прокси-серверов включает в себя управление сертификатами, настройку параметров прокси и шлюза, а также расширенную конфигурацию сети. Если вы не ИТ-специалист и до сих пор работали с этим руководством в одиночку, сейчас самое время обратиться к профессионалу.

Как Tableau взаимодействует с Интернетом

Tableau Server требует исходящего доступа к Интернету для следующих сценариев:

• Работа с картами.Tableau использует данные карты, размещенные на внешнем сервере. Серверу Tableau необходимо подключиться к местоположениям карт через порт 443. Если он не может установить это подключение, карты могут не загрузиться. По умолчанию Tableau использует OpenStreetMaps для картографических данных.

  Tableau Server должен подключаться к следующим Интернет-адресам для карт:

  • mapsconfig.tableau.com
  • api.mapbox.com

  Для версий 2019.1.x и более ранних Tableau Server должен подключаться к этому местоположению для карт:

• Подключение к серверу отправки журналов Tableau.

  Вы можете выгружать файлы журналов в Tableau при работе с Support. Для успешной загрузки файлов в Tableau ваш Tableau Server должен иметь возможность связываться с сервером журналов отправки через порт 443:

  .

  отчет-выпуск.tableau.com

• Лицензирование. Продукты Tableau подключаются к Интернету для активации ключей продукта. Если вы не активируете программное обеспечение Tableau с помощью Offline Activation Tool, все продукты Tableau должны иметь постоянный доступ к Интернету для проверки своих лицензий.

  Tableau Server должен быть подключен к следующим Интернет-адресам в целях лицензирования:

  • лицензирование.tableau.com:443

  • atr.licensing.tableau.com:443

  • s.ss2.us

  • ocsp.rootg2.amazontrust.com

  • ocsp.rootca1.amazontrust.com

  • ocsp.sca1b.amazontrust.com

  • crt.sca1b.amazontrust.com

  • crt.rootca1.amazontrust.com

  • ocsp.sca0a.amazontrust.com

  • crt.sca0a.amazontrust.com

  • ocsp.sca1a.amazontrust.com

  • crt.sca1a.amazontrust.com

  • ocsp.sca2a.amazontrust.com

  • crt.sca2a.amazontrust.com

  • ocsp.sca3a.amazontrust.com

  • crt.sca3a.amazontrust.com

  • ocsp.sca4a.amazontrust.com

  • crt.sca4a.amazontrust.com

  • crl.rootca1.amazontrust.com

  • crl.rootg2.amazontrust.com

  • крл.sca1b.amazontrust.com

  Запросы к указанным выше доменам могут поступать на порт 80 или 443. Порт 80 используется для проверки сертификата (отзыв, цепочка сертификатов и т. Д.). Порт 443 используется для SSL-соединений.

  Если Tableau Server не может установить соединение при попытке активировать свою лицензию, вам будет предложено выполнить автономную активацию.

• Работа с внешними или облачными данными.

Tableau Server может работать без доступа к Интернету, но в большинстве организаций сценарии в списке требуют, чтобы Tableau имел доступ к Интернету.

Сервер Tableau и прокси-серверы

Сервер

Tableau был разработан для работы внутри защищенной внутренней сети. Поэтому наша первая настоятельная рекомендация заключается в следующем: не настраивайте Tableau Server на компьютере, который выступает в качестве интернет-шлюза вашей организации.Как мы рекомендовали в начале, поместите Tableau Server на выделенный компьютер, на котором не выполняются никакие другие процессы, и в этом случае он не имеет прямого доступа к Интернету.

Вместо этого вам следует настроить прокси-сервер — компьютер, который передает трафик между локальной (внутренней) сетью и Интернетом. Перенаправляющие прокси-серверы служат посредником для трафика изнутри сети к целям в Интернете. Обратные прокси-серверы передают трафик из Интернета на цели внутри сети.

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

Важно : Как мы обсуждали в главе «Планирование развертывания», мы не рекомендуем устанавливать Tableau Server на компьютер, на котором работает IIS.Кроме того, если вы используете антивирусное программное обеспечение, вы должны следовать рекомендациям в базе знаний (ссылка открывается в новом окне), чтобы исключить каталоги Tableau Server. Процедуры в этой главе предполагают, что вы установили Tableau Server на чистый компьютер.

Прямой прокси-сервер

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

Многие организации используют прокси-сервер прямой пересылки в своей сети. В этих организациях компьютеры внутри сети должны быть настроены для отправки трафика на прокси-сервер пересылки. Обычно это необходимо, даже если пользователи сами не пытаются получить доступ к Интернету.Например, чтобы пользователи могли создавать книги, содержащие карты, Tableau Desktop и Tableau Server должны иметь доступ к серверам карт Tableau, размещенным в Интернете. Кроме того, по умолчанию компонент лицензирования продуктов Tableau подключается к Интернету для активации наших продуктов. Если вы не активируете программное обеспечение Tableau с помощью Offline Activation Tool (ссылка открывается в новом окне), все продукты Tableau должны иметь доступ к Интернету для проверки своих лицензий.

Если в вашей организации используется прямой прокси-сервер, необходимо убедиться, что рабочий стол и сервер Tableau настроены для использования этого прокси-сервера.Если ваш прокси-сервер аутентифицирует пользователей для исходящих подключений, вам необходимо настроить Windows Internet Options на Tableau Server для использования учетной записи Run As User в качестве контекста безопасности.

В разделе «Дополнительные ресурсы» далее будет ссылка на дополнительную информацию о том, как настроить прямой прокси-сервер.

Обратный прокси-сервер

Обратный прокси — это сервер, который получает запросы от внешних (интернет) клиентов и пересылает их на Tableau Server.Зачем использовать обратный прокси? В основной ответ — безопасность. Обратный прокси-сервер делает Tableau Server доступным для Интернета без необходимости раскрывать IP-адрес этого сервера в Интернете. Обратный прокси-сервер также действует как устройство аутентификации и сквозной передачи, поэтому данные не хранятся там, где люди за пределами компании могут получить к ним доступ (в DMZ, для тех, кто знает этот термин). Это требование может быть важным для организаций, подпадающих под действие различных правил конфиденциальности, таких как PCI, HIPAA или SOX.

Иллюстрация того, как обратный прокси работает с Tableau Server

На следующей диаграмме показан путь связи, когда клиент делает запрос к серверу Tableau, который настроен для работы с обратным прокси-сервером.

1. Внешний клиент инициирует соединение с Tableau Server. Клиент использует общедоступный URL-адрес, настроенный для обратного прокси-сервера, например https: // tableau.example.com . (Клиент не знает, что он обращается к обратному прокси.)

2. Обратный прокси передает запрос серверу Tableau. Обратный прокси-сервер может быть настроен для аутентификации клиента (с использованием SSL / TLS) в качестве предварительного условия для передачи запроса серверу Tableau.

3. Tableau Server получает запрос и отправляет свой ответ обратному прокси.

4. Обратный прокси-сервер отправляет контент обратно клиенту. Что касается клиента, он только что взаимодействовал с Tableau Server и не имеет возможности узнать, что связь была опосредована обратным прокси-сервером.

Прокси-серверы и SSL

Для большей безопасности вам следует настроить прокси-серверы на использование SSL для любого трафика, который является внешним по отношению к вашей сети.Это помогает обеспечить конфиденциальность, целостность контента и аутентификацию. Если вы не внедрили другие меры безопасности для защиты трафика между вашим интернет-шлюзом и Tableau Server, мы также рекомендуем настроить SSL между прокси-сервером шлюза и Tableau Server. Как отмечалось в предыдущей главе «Защита трафика между клиентами и вашим сервером», вы можете использовать внутренние или самозаверяющие сертификаты для шифрования трафика между серверами Tableau и другими внутренними компьютерами.

Мы действительно рекомендуем, чтобы трафик был защищен с помощью SSL на каждом переходе — от внешнего к обратному прокси-серверу и от обратного прокси к серверу Tableau.В этом сценарии мы рекомендуем настроить обратный прокси-сервер для отклонения подключений, которые не используют SSL (то есть не используют https: // в URL-адресе).

Если вы будете использовать аутентификацию Kerberos, вы должны настроить Tableau Server для своего прокси, прежде чем настраивать Tableau Server для Kerberos.

Дополнительные сведения см. В разделе Настройка Kerberos (ссылка открывается в новом окне). Кроме того, вы можете использовать SAML, OpenID Connect или Trusted Tickets с обратным прокси-сервером.

Настроить Tableau Server для работы с обратным прокси-сервером

Хорошо, мы уговорили вас использовать обратный прокси. Перед настройкой Tableau Server вам необходимо собрать следующую информацию о конфигурации прокси-сервера. Если вы не тот человек, который настраивал обратный прокси-сервер, вам необходимо запросить эту информацию у своего ИТ-специалиста.

Товар	Описание
IP-адрес или CNAME	Для этой опции вы можете ввести IP-адрес или CNAME. Общедоступный IP-адрес или адреса прокси-сервера. IP-адрес должен быть в формате IPv4, например 203.0.113.0 , и это должен быть статический IP-адрес. Если вы не можете предоставить статический IP-адрес или используете облачные прокси-серверы или внешние балансировщики нагрузки, вы можете указать значение DNS CNAME (каноническое имя), которое клиенты будут использовать для подключения к серверу Tableau. Это значение CNAME должно быть настроено в вашем решении обратного прокси для связи с Tableau Server.
FQDN	Полное доменное имя, которое люди используют для доступа к серверу Tableau, например tableau.example.com . Tableau Server не поддерживает полное доменное имя с информацией помимо имени домена, например example.com/tableau . (Ваш ИТ-специалист может понять, что это означает, что Tableau Server не поддерживает переключение контекста.)
Без полного доменного имени	Любые имена поддоменов для прокси-сервера.В примере tableau.example.com имя поддомена — tableau .
Псевдонимы	Любые общедоступные альтернативные имена прокси-сервера. В большинстве случаев псевдонимы обозначаются с помощью значений CNAME. Примером может служить прокси-сервер bigbox.example.com и записи CNAME для ftp.example.com и www.example.com .
Порты	Номера портов для трафика от клиента к обратному прокси-серверу и для трафика от прокси-сервера к серверу Tableau.

Для настройки Tableau Server используйте Tableau Services Manager (TSM). Tableau Services Manager — это набор инструментов управления, используемый для установки, настройки и управления службами Tableau.

1. Введите следующую команду, чтобы установить полное доменное имя, которое клиенты будут использовать для доступа к серверу Tableau через прокси-сервер, где имя — полное доменное имя:

   tsm configuration set -k gateway.public.host -v " имя "

   Например, если для доступа к серверу Tableau нужно ввести в браузере https://tableau.example.com , введите следующую команду:

   tsm configuration set -k gateway.public.host -v "tableau.example.com"

2. Введите следующую команду, чтобы установить адрес или CNAME прокси-сервера, где адрес_сервера адрес IPv4 или значение CNAME:

   tsm configuration set -k gateway.доверенный -v " ip_адрес_сервера "

   Если ваша организация использует несколько прокси-серверов, введите несколько адресов IPv4, разделяя их запятыми. Диапазоны IP-адресов не поддерживаются. Чтобы улучшить запуск и инициализацию Tableau Server, минимизируйте количество записей для шлюза . доверенный .

3. Введите следующую команду, чтобы указать альтернативные имена для прокси-сервера, например, его полный домен. имя, любые неполные доменные имена и псевдонимы.Если имеется более одного имени, разделите имена знаком запятая.

   tsm configuration set -k gateway.trusted_hosts -v " name1 , name2 , name3 "

   Например:

   tsm configuration set -k gateway.trusted_hosts -v "proxy1.example.com, proxy1, ftp.example.com, www.example.com "

4. Если прокси-сервер использует SSL для связи с Интернетом, выполните следующую команду, которая сообщает Tableau, что обратный прокси-сервер использует порт 443 вместо порта 80:

   tsm configuration set -k gateway.public.port -v 443

   Примечание : Если прокси-сервер использует SSL для связи с Tableau Server, SSL должен быть настроен и включен на Tableau Server.

5. Введите следующую команду, чтобы зафиксировать изменение конфигурации и перезапустить Tableau Server:

   tsm в ожидании изменений применяются

Настройте обратный прокси-сервер для работы с Tableau Server

Включение клиентского доступа из Интернета через обратный прокси-сервер требует, чтобы определенные заголовки сообщений сохранялись (или добавлялись) для Tableau Server.На следующем рисунке это показано.

Заголовки, которые требуются Tableau Server:

• REMOTE_ADDR и X-FORWARDED-FOR ( XFF ). Эти заголовки необходимы Tableau Server для определения IP-адреса отправителя запросов.

• HOST и X-FORWARDED HOST ( XFH ).Эти заголовки используются для создания абсолютных ссылок на Tableau Server, когда он отвечает клиенту.

• X-FORWARDED-PROTO ( XFP ). Этот заголовок требуется, если вы используете SSL на прокси, но не на сервере Tableau. Как уже отмечалось, мы рекомендуем использовать SSL на каждом переходе.

Устранение неполадок и примечания для обратных прокси

Поскольку существуют разные прокси-решения, мы не можем подробно описать шаги для настройки сквозной конфигурации.Тем не менее, мы собрали несколько советов и другую информацию, относящуюся к включению обратного прокси с Tableau Server.

• Заголовки X-FORWARDED-PROTO важны для сценариев, в которых HTTP или HTTPS не поддерживаются на каждом этапе маршрута сообщения. Например, если обратный прокси-сервер требует SSL для внешних запросов, но трафик между обратным прокси и сервером Tableau не настроен для использования SSL, требуются заголовки X-FORWARDED-PROTO .Некоторые прокси-решения добавляют заголовки X-FORWARDED-PROTO автоматически, а другие — нет. Наконец, в зависимости от вашего прокси-решения вам может потребоваться настроить переадресацию портов для перевода запроса с порта 443 на порт 80.

• Некоторым прокси-серверам требуется правило в дополнение к заголовку X-FORWARDED-PROTO . Например, прокси-устройство F5 требует, чтобы вы применили iRule к виртуальному серверу, на котором размещено пространство имен URL-адресов для сервера Tableau.

• Прокси-серверы и внешние балансировщики нагрузки могут быть смешаны и объединены в несколько структур. В случае, когда имеется несколько переходов, порядок заголовков, представленных серверу Tableau, должен соответствовать последовательности переходов, взятых трафиком для достижения сервера Tableau. Кроме того, чтобы включить доверенные билеты, все прокси-серверы в цепочке должны быть указаны в шлюзе . доверенный и доверенный.хостов настроек.

• Если у вас есть несколько IP-адресов в настройке gateway.trusted , вы должны разделить значения запятой и пробелом при вводе команды, например "203.0.113.0, 10.32.56.78" . Вся строка также должна быть заключена в двойные кавычки, как показано.

Аутентификация

• Если вы будете использовать аутентификацию Kerberos, вы должны настроить Tableau Server для своего прокси, прежде чем настраивать Tableau Server для Kerberos.

  Дополнительные сведения см. В разделе «Настройка Kerberos» (ссылка открывается в новом окне) в справке сервера Tableau.

• Обратные прокси-серверы Apache не поддерживаются, если Tableau Server использует SSPI (Active Directory с включением автоматического входа в систему) для аутентификации пользователей Tableau Server. Обратные прокси-серверы Apache поддерживаются , если Tableau Server аутентифицирует пользователей сервера только с помощью Active Directory (№ Включить автоматический вход в систему ).

• Настройте прокси-сервер для аутентификации с помощью SSL. Не настраивайте прокси-сервер так, чтобы он предлагал пользователям пройти аутентификацию.

Перейти к созданию пользователей.

Дополнительный ресурс

Зарегистрированный порт

— обзор

Основы исследования сети

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

Многие профессиональные инструменты и технологии существуют от крупных поставщиков, таких как McAfee, Symantec, IBM, Saint, Tenable и многих других. Однако глубокое понимание того, что они делают, как они это делают и является ли ценность расследования полной, может быть в некоторой степени загадкой. Существуют также бесплатные инструменты, такие как Wireshark, которые выполняют захват и анализ сетевых пакетов.

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

Что это за розетки?

При взаимодействии с сетью сокеты являются фундаментальным строительным блоком, позволяющим нам использовать возможности базовой операционной системы для взаимодействия с сетью.Сокеты предоставляют информационный канал для связи между конечными точками сети, например, между клиентом и сервером. Вы можете рассматривать сокеты как конечную точку соединения между клиентом и сервером. Приложения, разработанные на таких языках, как Python, Java, C ++ и C #, имеют интерфейс с сетевыми сокетами с использованием интерфейса прикладного программирования (API). API сокетов в большинстве современных систем основан на сокетах Беркли. Сокеты Berkeley изначально поставлялись с UNIX BSD версии 4.2 еще в 1983 году. Позже, примерно в 1990 году, Беркли выпустил безлицензионную версию, которая является основой современного API сокетов в большинстве операционных систем (Linux, Mac OS и Windows). Эта стандартизация обеспечивает единообразие реализации на разных платформах.

На рисунке 8.1 показан пример сети, в которой несколько хостов (конечных точек) подключены к сетевому концентратору. Каждый хост имеет уникальный IP-адрес, и для этой простой сети мы видим, что каждый хост имеет уникальный IP-адрес.

Рисунок 8.1. Простейшая локальная сеть.

Эти IP-адреса наиболее часто встречаются в настройках локальной сети. Эти конкретные адреса основаны на стандарте Интернет-протокола версии 4 (IPv4) и представляют собой сетевой адрес класса C. Адрес класса C обычно записывается пунктирной нотацией, например 192.168.0.1. Если разбить адрес на составные части, то первые три октета или первые 24 бита считаются сетевым адресом (также известным как сетевой идентификатор или NETID).Четвертый и последний октет или 8 битов считаются адресом локального хоста (также известным как идентификатор хоста или HOSTID).

В этом примере каждый хост, сетевое устройство, маршрутизатор, брандмауэр и т. Д. В локальной сети будет иметь ту же часть сетевого адреса IP-адреса (192.168.0), но каждый будет иметь уникальный диапазон адресов хоста от 0 до 255. Это позволяет использовать 256 уникальных IP-адресов в локальной среде. Таким образом, диапазон будет: 192.168.0.0-192.168.0.255. Однако можно использовать только 254 адреса, потому что 192.168.0.0 является сетевым адресом и не может быть назначен локальному узлу, а 192.168.0.255 выделен как широковещательный адрес.

Исходя из этого, я мог бы использовать несколько простых встроенных возможностей языка Python для создания списка IP-адресов, представляющих полный диапазон. Эти языковые возможности включают String, List, функцию диапазона и цикл for.

# Укажите базовый сетевой адрес (первые 3 октета)

ipBase = ‘192.168.0.’

# Далее Создайте пустой список, который будет содержать заполненный

# Список IP-адресов

ipList = []

# Наконец, прокрутите список возможных локальных хостов

# адресов 0-255, используя функцию диапазона

# Затем добавьте каждый полный адрес в ipList

# Обратите внимание, что я использую функцию str (ip) в порядке

# объединяю строку ipBase со списком номеров 0-255

для ip в диапазоне (0,256):

ipList.append (ipBase + str (ip))

print ipList.pop ()

Сокращенный вывод программы

192.168.0.0

192.168.0.1

192.168.0.2

192.168.0.3

… .. пропущенные элементы

192.168.0.252

192.168.0.253

192.168.0.254

192.168.0.255

Как видите, манипулировать IP-адресами с помощью стандартных элементов языка Python очень просто. Я воспользуюсь этой техникой в ​​разделе Ping Sweep позже в этой главе.

Простейшее соединение с сетевым клиентом и сервером с использованием сокетов

В качестве знакомства с API сокетов, предоставляемым Python, я создам простой сетевой сервер и клиент. Для этого я буду использовать один и тот же хост (другими словами, клиент и сервер будут использовать один и тот же IP-адрес, выполняющийся на одном компьютере), я специально буду использовать специальный и зарезервированный IP-адрес localhost loopback 127.0.0.1. Этот стандартный петлевой IP-адрес одинаков практически для всех систем и любых сообщений, отправляемых на 127.0.0.1 никогда не достигают внешнего мира, а вместо этого автоматически возвращаются на localhost . Когда вы начнете экспериментировать с сетевым программированием, используйте 127.0.0.1 в качестве предпочтительного IP-адреса, пока вы не усовершенствуете свой код и не будете готовы работать в реальной сети (рисунок 8.2).

Рисунок 8.2. Изолированный localhost loopback.

Для этого я фактически создам две программы Python: (1) server.py и (2) client.py. Чтобы это работало, два приложения должны согласовать порт, который будет использоваться для поддержки канала связи.(Мы уже решили использовать петлевой IP-адрес localhost 127.0.0.1.) Номера портов находятся в диапазоне от 0 до 65 535 (в основном, любое 16-разрядное целое число без знака). Вам следует держаться подальше от портов с меньшими номерами <1024, поскольку они назначены стандартным сетевым службам (на самом деле сейчас зарегистрированные порты достигают 49 500, но ни один из них не находится в моей текущей системе). Для этого приложения я буду использовать порт 5555, поскольку это легко запомнить. Теперь, когда я определил IP-адрес и номер порта, у меня есть вся информация, необходимая для подключения.

IP-адрес и порт: один из способов подумать об этом в более физических терминах. Подумайте об IP-адресе как об адресе почтового отделения, а о Порте как о конкретном почтовом ящике в почтовом отделении, к которому я хочу обратиться.

server.py code

#

# Задача сервера

# 1) Настроить простой прослушивающий сокет

# 2) Дождаться запроса на соединение

# 3) Принять соединение через порт 5555

# 4) После успешного подключения отправьте сообщение клиенту

#

import socket # Standard Library Socket Module

# Create Socket

myServerSocket = socket.socket ()

# Получить адрес моего локального хоста

localHost = socket.gethostname ()

# Указать локальный порт для приема соединений на

localPort = 5555

# Привязать myServerSocket к localHost и указанному порту

# Обратите внимание, что для вызова привязки требуется один параметр, но этот параметр

# является кортежем (обратите внимание на использование скобок)

myServerSocket.bind ((localHost, localPort))

# Начать прослушивание соединений

myServerSocket.listen (1)

# Ждать запроса на соединение

# Обратите внимание, что это синхронный вызов

#, означающий, что программа остановится до тех пор, пока

# не будет получено соединение.

# Как только соединение будет получено

# мы примем соединение и получим

# ipAddress коннектора

print ‘Python-Forensics …. Waiting for Connection Request’

conn, clientInfo = myServerSocket. accept ()

# Распечатать сообщение, чтобы указать, что мы получили соединение

print ‘Connection Received From:’, clientInfo

# Отправьте сообщение соединителю, используя объект подключения ‘conn’

#, который был возвращен из myServerSocket.accept () call

# Включить IP-адрес и порт клиента в ответ

conn.send (‘Connection Confirmed:’ + ‘IP:’ + clientInfo [0] + ‘Port:’ + str (clientInfo [1 ]))

client.py code

Затем код клиента, который установит соединение с сервером

#

# Client Objective

# 1) Установите клиентский сокет

# 2) Попытайтесь подключиться к сервер на порту 5555

# 3) Дождитесь ответа

# 4) Распечатайте сообщение, полученное от сервера

#

import socket # Standard Library Socket Module

MAX_BUFFER = 1024 # Установите максимальный размер на получить

# Создать сокет

myClientSocket = socket.socket ()

# Получить адрес моего локального хоста

localHost = socket.gethostname ()

# Указать локальный порт для попытки подключения

localPort = 5555

# Попытаться подключиться к моим localHost и localPort

myClientSocket .connect ((localHost, localPort))

# Ждать ответа

# Это синхронный вызов, то есть

# программа остановится, пока не будет получен ответ

# или программа не завершится

msg = myClientSocket.