Comments 30
Ну вот и первый минус. Жаль, что автор не решился его прокомментировать. А ведь, можно было бы учесть его пожелания и в дальнейшем избегать ошибок, которые он посчитал критическими для публикации.
Москва ведь тоже не сразу строилась.
Москва ведь тоже не сразу строилась.
Извиняюсь за лишнюю запятую между «ведь» и «можно».
Скорее всего, тонкая душевная организация минусующего была расстроена, когда автор увидел в названии статьи «1С». Не обращайте внимания.
Я теперь тоже склоняюсь к этому мнению. Судя по всему, большинство тут не использует этот_продукт, а сидит на чем-то другом: крутом, дорогом.
Но дело ведь не в том, что я обожаю продукты фирмы_котрую_тут_оказывается_нельзя_упоминать, а в том, что кто-то один купил, поставил, настроил это хозяйство, а кто-то другой, не имевший к этому процессу отношения, теперь должен думать о безопасности.
Но дело ведь не в том, что я обожаю продукты фирмы_котрую_тут_оказывается_нельзя_упоминать, а в том, что кто-то один купил, поставил, настроил это хозяйство, а кто-то другой, не имевший к этому процессу отношения, теперь должен думать о безопасности.
Мелочи жизни. За комментарии в карму я получал минусы в карму и от яблочников и от вендузятников… А недавно даже от Убунтоидов парочку получил, несмотря на то, что сам системой пользуюсь как минимум не один месяц, если уже не год.
> Прячем 1С за огненную стену
К вашему сведению, Firewall (он же брандмауэр, [нем. Brandmauer]) — это не огненная стена, а противопожарная (огнестойкая) стена.
В изначальном значении это слово означает глухую огнестойкую стену, разделяющую смежные строения или части строения в противопожарных целях, чтобы огонь не распространялся и не перекидвался от одного здания к другому. Только потом из инженерно-строительной терминологии это слово перекочевало в компьютерную терминологию.
К вашему сведению, Firewall (он же брандмауэр, [нем. Brandmauer]) — это не огненная стена, а противопожарная (огнестойкая) стена.
В изначальном значении это слово означает глухую огнестойкую стену, разделяющую смежные строения или части строения в противопожарных целях, чтобы огонь не распространялся и не перекидвался от одного здания к другому. Только потом из инженерно-строительной терминологии это слово перекочевало в компьютерную терминологию.
То есть это слово нельзя использовать в публикациях на компьютерную тематику?
А еще нельзя немного иронизировать? И даже если специально для обозначения иронии прямо под заголовок вставлено соответствующее изображение?
А еще нельзя немного иронизировать? И даже если специально для обозначения иронии прямо под заголовок вставлено соответствующее изображение?
Извиняюсь за резкость, был немного возбужден :) Спасибо за информацию, впоследствии буду учитывать это :)
Хорошая статья, спасибо. Таки интересно, в процессе изменения рисунка 1 на рисунок 3 уменьшилась ли нагрузка на сеть? Спрашиваю из праздного любопытства ради общего развития.
UFO just landed and posted this here
Как-то у вас очень коряво обозначены сетевые соединения (что на схеме, что в таблице сетевого доступа). У каждого соединения есть источник/инициатор соединения (source) и целевая cторона (target или destination), принимающая эти соединения. На схеме это обозначается стрелочкой (двусторонней в случае двунаправленного доступа), а в таблице доступа дополнительными колонками source/target. Это важно для понимания направления сетевых подключений и корректной настройки межсетевых экранов.
По поводу набора протоколов/портов у меня тоже есть немалые замечания.
По направлению от клиентов (рабочих станций и рядовых серверов) к контроллеру домена нужно открывать:
1) Port 88 TCP/UDP — для Kerberos. По умолчанию Kerberos, конечно, инициируется по UDP 88, но при некоторых условиях может переходить и на TCP 88. Лучше заранее это учесть в правилах сетевого доступа.
2) Port 389 TCP/UDP — для LDAP (UDP 389 — LDAP ping, TCP 389 — LDAP connection).
Если у вас настроен LDAP SSL, то дополнительно нужно ещё открывать 636 TCP.
3) Port 3268 TCP — если у вас на контроллере поднят и используется Global Catalog (если у вас в организации всего один AD-домен и нет Exchange-серверов, то Global Catalog может и не быть).
Если у вас настроен доступ к Global Catalog с использованием SSL, то нужно дополнительно открывать ещё и 3269 TCP.
4) Port 53 TCP/UDP — для DNS, если у вас DNS поднят на контроллере домена. Клиенты используют запросы к DNS-серверу по UDP 53 (DNS Lookup), поэтому от клиентов до DNS-сервера достаточно будет UDP 53. TCP 53 используется для общения между DNS-серверами, для трансфера DNS-зон и прочих AXFR-запросов.
5) Port 445 TCP — для SMB (windows file sharing). Иногда для работы SMB кроме TCP 445 рекомендуют ещё открывать UDP 445, но я лично не встречал в этом потребности, всегда было достаточно TCP 445.
6) Port 123 UDP — для NTP (для синхронизации времени с контроллером).
7) Port 135 TCP — для RPC endpoint mapper.
8) Port range: 1024-65535 TCP (для Win2003), 49152-65535 TCP (для Win2008/2008-R2) — широкий динамический диапазон TCP-портов для назначения их клиентским RPC-подключениям к сервисам Netlogon, LSA (NTDS), NTFRS.
В действительности клиенты по RPC подключаются к нескольким различным AD-сервисам на контроллере домена, а именно: Netlogon, LSA (NTDS), плюс для репликации файлов между Win2000/2003-контроллерами ещё используется сервис NTFRS (тоже по RPC). Для подключения клиентов к сервисам, работающим по RPC, используются динамически выдаваемые TCP-порты из широкого диапазона TCP-портов (в Win2003 порты выше 1024 до 65535, в Win2008/2008-R2 порты выше 49152 до 65535). При этом клиент сначала подключается к контроллеру домена по TCP 135, RPC endpoint mapper назначает клиенту конкретные порты из широкого диапазона, по которым ему следует подключаться к конкретным RPC-сервисам данного контроллера. А дальше клиент уже подключается к службам Netlogon и LSA (NTDS) по указанным ему TCP-портам. Разным клиентам для одних и тех же RPC-сервисов контроллер может выдать разные порты (из указанного широкого диапазона), т.е. одному клиенту сказал подключаться к Netlogon на порт TCP 1025, другому назначил для того же RPC-сервиса порт TCP 1026 и т.д. По умолчанию заранее неизвестно, какой именно порт и кому назначит RPC endpoint mapper. И это усложняет настройку правил сетевого доступа на файрволе.
Поскольку по умолчанию порты для RPC-подключений клиенту выдаются динамически случайным образом из очень широкого диапазона, то открывать такой огромный жиапазон сразу на файрволе — это совсем не вариант. Поэтому для открытия портов для данных RPC-сервисов на межсетевом экране нужно:
а) Либо, чтобы firewall (например, на стороне самого контроллера домена) слушал общение клиента с RPC endpoint mapper'ом и автоматически понимал, какие TCP-порты тот назначил для RPC-подключений конкретному клиенту, чтобы динамически менять правила и разрешать эти назначенные порты для подключений конкретного клиента.
б) Либо на стороне контроллеров домена заранее биндить все RPC-сервисы на конкретные TCP-порты (без динамического диапазона). А потом в статических правилах на файрволе добавлять разрешения на подключения клиентских машин к контроллерам домена на эти конкретные жёстко заранее назначенные TCP-порты.
Конкретный TCP-порт для каждого RPC-сервиса назначается в параметрах системного реестра на контроллерах домена, например, так (значения можно дать любые незанятые):
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
«TCP/IP Port» = 50001
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
«DCTcpipPort» = 50002
HKLM\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
«RPC TCP/IP Port Assignment» = 50003
После этого RPC endpoint mapper будет выдавать всем клиентам без исключения именно эти значения TCP-портов для подключения к соответствующим своим RPC-сервисам. Соответственно в правилах на файрволе нужно будет разрешить TCP-подключения от клиентов к контроллерам домена именно на эти фиксированные порты (50001 и 50002), а если есть межсетевые экраны между контроллерами домена, то в оба направления разрешить подключения между контроллерами на фиксированные порты 50001, 50002 и 50003.
9) Port 3389 TCP — для подключений по протоколу RDP (можно открывать не со всей сети, а только с отдельных администраторских машин).
10) ICMP Echo Request/Reply — для обмена пингами, для диагностики, для поиска ближайшего контроллера перед применением групповых политик.
Вот этого джентльменского набора портов/протоколов будет достаточно для настройки в правилах межсетевого экрана разрешений на клиентские сетевые подключения к контроллерам домена. При наличии на контроллерах домена дополнительных сервисов (DHCP, DFS, SMTP и др.) в эти правила могут добавиться какие-то дополнительные наборы TCP/UDP-портов.
Если у вас в сети нет машин с Win9x/NT4, то клиентские подключения к контроллерам на TCP/UPD-порты 137, 138, 139 — не нужны. Забудьте о NBT (NetBIOS over TCP/IP) и прочее убогое наследие NetBIOS, сейчас вместо него везде достаточно только SMB (TCP 445).
По поводу набора протоколов/портов у меня тоже есть немалые замечания.
По направлению от клиентов (рабочих станций и рядовых серверов) к контроллеру домена нужно открывать:
1) Port 88 TCP/UDP — для Kerberos. По умолчанию Kerberos, конечно, инициируется по UDP 88, но при некоторых условиях может переходить и на TCP 88. Лучше заранее это учесть в правилах сетевого доступа.
2) Port 389 TCP/UDP — для LDAP (UDP 389 — LDAP ping, TCP 389 — LDAP connection).
Если у вас настроен LDAP SSL, то дополнительно нужно ещё открывать 636 TCP.
3) Port 3268 TCP — если у вас на контроллере поднят и используется Global Catalog (если у вас в организации всего один AD-домен и нет Exchange-серверов, то Global Catalog может и не быть).
Если у вас настроен доступ к Global Catalog с использованием SSL, то нужно дополнительно открывать ещё и 3269 TCP.
4) Port 53 TCP/UDP — для DNS, если у вас DNS поднят на контроллере домена. Клиенты используют запросы к DNS-серверу по UDP 53 (DNS Lookup), поэтому от клиентов до DNS-сервера достаточно будет UDP 53. TCP 53 используется для общения между DNS-серверами, для трансфера DNS-зон и прочих AXFR-запросов.
5) Port 445 TCP — для SMB (windows file sharing). Иногда для работы SMB кроме TCP 445 рекомендуют ещё открывать UDP 445, но я лично не встречал в этом потребности, всегда было достаточно TCP 445.
6) Port 123 UDP — для NTP (для синхронизации времени с контроллером).
7) Port 135 TCP — для RPC endpoint mapper.
8) Port range: 1024-65535 TCP (для Win2003), 49152-65535 TCP (для Win2008/2008-R2) — широкий динамический диапазон TCP-портов для назначения их клиентским RPC-подключениям к сервисам Netlogon, LSA (NTDS), NTFRS.
В действительности клиенты по RPC подключаются к нескольким различным AD-сервисам на контроллере домена, а именно: Netlogon, LSA (NTDS), плюс для репликации файлов между Win2000/2003-контроллерами ещё используется сервис NTFRS (тоже по RPC). Для подключения клиентов к сервисам, работающим по RPC, используются динамически выдаваемые TCP-порты из широкого диапазона TCP-портов (в Win2003 порты выше 1024 до 65535, в Win2008/2008-R2 порты выше 49152 до 65535). При этом клиент сначала подключается к контроллеру домена по TCP 135, RPC endpoint mapper назначает клиенту конкретные порты из широкого диапазона, по которым ему следует подключаться к конкретным RPC-сервисам данного контроллера. А дальше клиент уже подключается к службам Netlogon и LSA (NTDS) по указанным ему TCP-портам. Разным клиентам для одних и тех же RPC-сервисов контроллер может выдать разные порты (из указанного широкого диапазона), т.е. одному клиенту сказал подключаться к Netlogon на порт TCP 1025, другому назначил для того же RPC-сервиса порт TCP 1026 и т.д. По умолчанию заранее неизвестно, какой именно порт и кому назначит RPC endpoint mapper. И это усложняет настройку правил сетевого доступа на файрволе.
Поскольку по умолчанию порты для RPC-подключений клиенту выдаются динамически случайным образом из очень широкого диапазона, то открывать такой огромный жиапазон сразу на файрволе — это совсем не вариант. Поэтому для открытия портов для данных RPC-сервисов на межсетевом экране нужно:
а) Либо, чтобы firewall (например, на стороне самого контроллера домена) слушал общение клиента с RPC endpoint mapper'ом и автоматически понимал, какие TCP-порты тот назначил для RPC-подключений конкретному клиенту, чтобы динамически менять правила и разрешать эти назначенные порты для подключений конкретного клиента.
б) Либо на стороне контроллеров домена заранее биндить все RPC-сервисы на конкретные TCP-порты (без динамического диапазона). А потом в статических правилах на файрволе добавлять разрешения на подключения клиентских машин к контроллерам домена на эти конкретные жёстко заранее назначенные TCP-порты.
Конкретный TCP-порт для каждого RPC-сервиса назначается в параметрах системного реестра на контроллерах домена, например, так (значения можно дать любые незанятые):
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
«TCP/IP Port» = 50001
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
«DCTcpipPort» = 50002
HKLM\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
«RPC TCP/IP Port Assignment» = 50003
После этого RPC endpoint mapper будет выдавать всем клиентам без исключения именно эти значения TCP-портов для подключения к соответствующим своим RPC-сервисам. Соответственно в правилах на файрволе нужно будет разрешить TCP-подключения от клиентов к контроллерам домена именно на эти фиксированные порты (50001 и 50002), а если есть межсетевые экраны между контроллерами домена, то в оба направления разрешить подключения между контроллерами на фиксированные порты 50001, 50002 и 50003.
9) Port 3389 TCP — для подключений по протоколу RDP (можно открывать не со всей сети, а только с отдельных администраторских машин).
10) ICMP Echo Request/Reply — для обмена пингами, для диагностики, для поиска ближайшего контроллера перед применением групповых политик.
Вот этого джентльменского набора портов/протоколов будет достаточно для настройки в правилах межсетевого экрана разрешений на клиентские сетевые подключения к контроллерам домена. При наличии на контроллерах домена дополнительных сервисов (DHCP, DFS, SMTP и др.) в эти правила могут добавиться какие-то дополнительные наборы TCP/UDP-портов.
Если у вас в сети нет машин с Win9x/NT4, то клиентские подключения к контроллерам на TCP/UPD-порты 137, 138, 139 — не нужны. Забудьте о NBT (NetBIOS over TCP/IP) и прочее убогое наследие NetBIOS, сейчас вместо него везде достаточно только SMB (TCP 445).
Спасибо за развернутый комментарий.
Собственно, я и ожидал от хабра в первую очередь общения с более знающими людьми и обмена опытом.
Обязательно учту и переработаю в соответствии с вашими замечаниями. К сожалению, котелок в данный момент уже не очень варит :)
Собственно, я и ожидал от хабра в первую очередь общения с более знающими людьми и обмена опытом.
Обязательно учту и переработаю в соответствии с вашими замечаниями. К сожалению, котелок в данный момент уже не очень варит :)
все верно, только забыли маленькую весч: печать с терминальных серверов:
1) через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо
2) screw driver (и прочие продукты) — это уже не MS + кому интересно — посмотрите на стоимость
3) печать на машины к которым подключены принтеры (обычная печать) — нужно открывание smb портов, что нивелирует безопасность
4) печать на принт-серверы — нужно открывание порта + не все принтеры работают
5) удешевление варианта 4 — печать на машины к которым подключены принтеры (через lpd) — нужно открывание порта + не все принтеры работают
6) аналогично 5, только через дополнительный эмулятор PS принтера, чтобы работало с большим количеством принтеров — костыли, но, бывает, единственный рабочий вариант.
7) идеал — все принтеры с поддержкой сети/с принтсерверами — нужно открывание 1го порта
Все вышеперечисленное написано с учетом реального опыта и работающих (поддерживаемых) систем. К сожалению, если есть ЗООпарк принтеров (+где есть win-принтеры и нет денег на их замену/приобретение screwdriver) с- пасает 6й вариант.
1) через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо
2) screw driver (и прочие продукты) — это уже не MS + кому интересно — посмотрите на стоимость
3) печать на машины к которым подключены принтеры (обычная печать) — нужно открывание smb портов, что нивелирует безопасность
4) печать на принт-серверы — нужно открывание порта + не все принтеры работают
5) удешевление варианта 4 — печать на машины к которым подключены принтеры (через lpd) — нужно открывание порта + не все принтеры работают
6) аналогично 5, только через дополнительный эмулятор PS принтера, чтобы работало с большим количеством принтеров — костыли, но, бывает, единственный рабочий вариант.
7) идеал — все принтеры с поддержкой сети/с принтсерверами — нужно открывание 1го порта
Все вышеперечисленное написано с учетом реального опыта и работающих (поддерживаемых) систем. К сожалению, если есть ЗООпарк принтеров (+где есть win-принтеры и нет денег на их замену/приобретение screwdriver) с- пасает 6й вариант.
> все верно, только забыли маленькую весч: печать с терминальных серверов:
Каким образом печать связана с открытием сетевого доступа между клиентскими машинами и контроллерами домена? Я писал только об этом. А печать — это отдельный вопрос.
Каким образом печать связана с открытием сетевого доступа между клиентскими машинами и контроллерами домена? Я писал только об этом. А печать — это отдельный вопрос.
>доступ пользователей к 1С осуществляется через терминальные сервера, развернутые на базе Windows Server 2003
доступ к 1с без возможности печатать, это, извините, не для работы. Можно придумать много СпециальноПридуманыхСлучаев, но не для обычных ситуаций.
а печать с темой связана очень просто — необходимостью открытия портов для печати. Их количество и пр. связано с архитектурой печати, которая, к сожалению часто диктуется финансами — то что есть, на том и печатай.
PS просто мы несколько подобных схем реализовывали (по подходу практически аналогично) и натыкались на многочисленные грабли при внедрении, когда вся схема работы вдруг рушится из-за забывчивости заказчика (вот еще надо ЭТО делать — например копировать файл). И тут начинаются или костыли или переделка схемы
доступ к 1с без возможности печатать, это, извините, не для работы. Можно придумать много СпециальноПридуманыхСлучаев, но не для обычных ситуаций.
а печать с темой связана очень просто — необходимостью открытия портов для печати. Их количество и пр. связано с архитектурой печати, которая, к сожалению часто диктуется финансами — то что есть, на том и печатай.
PS просто мы несколько подобных схем реализовывали (по подходу практически аналогично) и натыкались на многочисленные грабли при внедрении, когда вся схема работы вдруг рушится из-за забывчивости заказчика (вот еще надо ЭТО делать — например копировать файл). И тут начинаются или костыли или переделка схемы
> вот еще надо ЭТО делать — например копировать файл
Задача создания схемы — как раз исключить такую возможность. Может, раньше бы на это и не пошли, но после случая слива информации прислушиваются. Ну, и в конце концов, никто не мешает нам в случае необходимости открыть порт для передачи файла в нужном направлении на необходимый промежуток времени. Можно даже сделать так, чтобы можно было ее выдать на некоторое время, по прошествии которого эта возможность автоматически закроется.
P.S. Из моих собственных наблюдений: как только пользователям говорят, что для выполнения какой-то опциональной процедуры ему придется обращаться в Службу Безопасности за разрешением (а некоторые вопросы будут проходить через руководство компании), да еще и с обоснованием, сначала начинается вой, а потом привыкают, и количество запросов становится настолько разумным, что их даже не особо влом и обработать.
Задача создания схемы — как раз исключить такую возможность. Может, раньше бы на это и не пошли, но после случая слива информации прислушиваются. Ну, и в конце концов, никто не мешает нам в случае необходимости открыть порт для передачи файла в нужном направлении на необходимый промежуток времени. Можно даже сделать так, чтобы можно было ее выдать на некоторое время, по прошествии которого эта возможность автоматически закроется.
P.S. Из моих собственных наблюдений: как только пользователям говорят, что для выполнения какой-то опциональной процедуры ему придется обращаться в Службу Безопасности за разрешением (а некоторые вопросы будут проходить через руководство компании), да еще и с обоснованием, сначала начинается вой, а потом привыкают, и количество запросов становится настолько разумным, что их даже не особо влом и обработать.
Вы вообще смотрите, на что именно вы отвечаете?
В моём комментарии не было ни слова ни по 1С, ни про терминальные серверы, ни про печать. Я написал лишь об одном аспекте: сетевом доступе между рабочими станциями и контроллером домена. В ответ на это вы зачем-то мне написали, что в этой схеме я забыл про печать.
В моём комментарии не было ни слова ни по 1С, ни про терминальные серверы, ни про печать. Я написал лишь об одном аспекте: сетевом доступе между рабочими станциями и контроллером домена. В ответ на это вы зачем-то мне написали, что в этой схеме я забыл про печать.
> через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо
Честно говоря, в данный момент тормозов печати в этом варианте не наблюдается. Это при обширной географии размещения клиентов и режиме работы приблизительно 14/6. Глюки, конечно, бывают. Но их количество настолько мало, что рассмотрение пунктов 2-7 в данный момент не требуется.
Честно говоря, в данный момент тормозов печати в этом варианте не наблюдается. Это при обширной географии размещения клиентов и режиме работы приблизительно 14/6. Глюки, конечно, бывают. Но их количество настолько мало, что рассмотрение пунктов 2-7 в данный момент не требуется.
Слово «сервер» во множественном числе будет «серверы», а не «сервера».
А можно пояснить?
Первые две ссылки, которые я нашел говорят об обратном:
dic.academic.ru/dic.nsf/rus_orthography/94077/%D1%84%D0%B0%D0%B9%D0%BB-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80
www.gramota.ru/slovari/dic/?all=x&word=%25F1%25E5%25F0%25E2%25E5%25F0
Первые две ссылки, которые я нашел говорят об обратном:
dic.academic.ru/dic.nsf/rus_orthography/94077/%D1%84%D0%B0%D0%B9%D0%BB-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80
www.gramota.ru/slovari/dic/?all=x&word=%25F1%25E5%25F0%25E2%25E5%25F0
Они не говорят об обратном.
Если вы не в курсе, то в орфографических словарях приводится окончание существительных в родительном падеже ед.числа (нет чего? сервера). Это никак не говорит о том, что во множественном числе окончание должно быть -а.
Тракторы, компьютеры, серверы — именно такое правильное окончание во множественном числе.
Если вы не в курсе, то в орфографических словарях приводится окончание существительных в родительном падеже ед.числа (нет чего? сервера). Это никак не говорит о том, что во множественном числе окончание должно быть -а.
Тракторы, компьютеры, серверы — именно такое правильное окончание во множественном числе.
По-моему это профессиональный жаргонизм, как компАс (вместо кОмпас) у моряков. :)
По всему рунету ходит копипаста с указанием открывать UDP порты 1560-1591 для удалённой отладки? Это действительно нужно или неверная трактовка фразы про "TCP/IP порты" из ИТС, а UDP используется только для проверки доступности в кластере?
Sign up to leave a comment.
Прячем 1С за огнеупорную стену