Комментарии 21
Вы раскрыли остатки тайных знаний сетевиков и теперь они стали окончательно не нужны.
Спасибо вам!

Вижу вас не в первом посте, и каждый раз – удивительно токсичные комментарии.

Если бы IP 93.184.216.34 указывал не на example.com, а на иной хост, то и это было бы ошибкой. Только тождество результат двустороннего разрешения имен гарантирует отсутствие ошибок настройки.

Спорно. Очень спорно, особенно в случае shared хостинга. Если у меня на сервере 300 сайтов на одном ип — это правило сработает ровно для одного домена. А извне невозможно определить hostname сервера…

Думаю, всё проще. У вас может быть много доменов с А-записями, указывающими на одни IP, но только одна PTR указывающая на один домен. И вот этот домен должен разрешаться в IP, PTR которого разрешается в этот домен. Если это условие соблюдено(оно для почтовых сервисов важно, к примеру), то проверки некоторых сервисов, проверяющие подобное соответствие, завершаются удачно, если нет – фейлятся. Поэтому всегда соблюдаем простое правило, когда основной домен смотрит на IP, а IP указывает в PTR на этот же домен, и проверка на соответствие PTR у IP, и А-записи у домена будет проходить успешно. Это и есть двустороннее разрешение имён. Другие ваши домены могут смотреть на этот же IP, и их может быть тысячи, это не проблема. Главное не забывать, что есть домен, что должен быть указан в PTR.

На мой взгляд, в статье потребность в сетевиках не раскрыта. Почти все описанное в статье делается и траблшутится типовым админом обслуживающим ОС. Посмотреть слушающие порты, проверить правила фаерволла ОС или антивируса — обыденная рутина при траблшутинге. Что бы поднять условный bind и прописать записи в зоне — знание сетевых протоколов совсем не обязательно. И модель OSI про которую все сетевики говорят, что она не нужна, но всегда про нее спрашивают соискателей, знать не нужно. Даже прописать в микротике вланы, что бы отдельно принять каналы на цифровую телефонию и интернет — это близко, но все еще не сетевик, как и замена электрической розетки дома не делает вас электриком.

Сетевики там где много каналов связи, телефонии, ВКС. Где много L2/L3 VPN в рамках B2B. Когда ты траблшутишь корявую покраску трафика со стороны оператора или почему посреди ВКС кто то начинает роботизированным голосом общаться. Маршрутизация трафика, ограничения на уровне сетевого доступа по портам и протоколам это обыденность в работе сетевика. Принять телефонию от оператора, прогнать через CUCM, выплюнуть в Астериск, что бы хоть как то заработала сказочная облачная телефония от Битрикса. Вот это все сетевики. И без них в таких ситуациях никак.
Зашел сюда ради этого комментария. Теперь тема точно раскрыта.
Бытует мнение, что на Windows нет альтернативы telnet, однако это неверно. Существует штатная утилита Test-NetConnection, которую можно запустить из PowerShell.

Да, но она не очень удобная если мне надо проеврять много серверов\компьютеров. Если устройства нет в сети, то процесс затянется очень надолго.

А еще штатный telnet, тоже когда не может подключиться, то консоль застревает и CTRL + C или CTRL + ] не обрывает команду.

Поэтому учитвая все это, я написал небольшую утилиту для себя на PowerShell, а за тем конвретировал PS1 скрипт в EXE с помощью утилиты PS2EXE, и поместил исполняемый файл в папку C:\Users\%USER_PROFILE%\AppData\Local\Microsoft\WindowsApps под названием tel.EXE, чтобы можно было вызывать ее из CMD сразу. Плюс к тому же писать telnet дольше чем tel ;).

Утилита обладает следующими качествами:
  1. Если в течение 500 милисекунд не может подключиться, то проверка обрывается
  2. Есть возможность оборвать процесс Ctrl + C
  3. Есть возможность поставить -t в конце команды, для бесконечной проверки заданного порта. Пример: tel server01 443 -t. Анологичен аргументу -t в ping.
  4. Есть функция игнорирования https:// и http:// в начале адреса сервера. Иногда бывает что копируешь ссылку с бразуера для проверки адреса, и в командную строку добавляется с https:// или http://, приходится еще это стирать. С этой функцией не надо запариваться стирать префиксы https:// или http://, она сама их уберет. Пример: tel httрs://server01 8443


Ниже в под спойлером исходный код:
исходный код
function TestServerPort {
    param(
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] [string]$ComputerName, #Server DNS name or IP address
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] $Port, #Server Port
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] $Timeout #Timeout
    )
 
    try {
        $tcpclient = New-Object -TypeName system.Net.Sockets.TcpClient
        $iar = $tcpclient.BeginConnect($ComputerName, $port, $null, $null)
        $wait = $iar.AsyncWaitHandle.WaitOne($timeout, $false)
        if (!$wait) {
            $tcpclient.Close()
            return $false
        }
        else {
            $null = $tcpclient.EndConnect($iar)
            $tcpclient.Close()
            return $true
        }
    }
    catch {
        $false 
    }
}

if ($args.Count -eq 1) {
    $value = $args[0]
    if (($value -eq "/?") -or ($value -eq "?") -or ($value -eq "-?") -or ($value -eq "-h") -or ($value -eq "h") -or ($value -eq "/h")) {
        Write-Host ""
        Write-Host "    ********************************"
        Write-Host "    **                            **"
        Write-Host "    **Created by Akshin Mustafayev**"
        Write-Host "    **                            **"
        Write-Host "    ********************************"
        Write-Host ""
        Write-Host "    This tool tests connection between your computer and the remote server using specified port."
        Write-Host "    List of arguments available for this tool: "
        Write-Host "        -? , /? , ? : Shows help information"
        Write-Host "        -h , /h , h : Shows help information"
        Write-Host ""
        Write-Host "        -t , /t , t : Loops port check. Similar to `"ping your_server -t`" command"
        Write-Host ""
        Write-Host ""
        Write-Host "    Usage examples:"
        Write-Host "        tel -?"
        Write-Host "        tel srv 443"
        Write-Host "        tel srv 443 -t"
        Write-Host ""
        Write-Host ""
        Write-Host "    Press `"Control + C`" to terminate execution of the program."
        Write-Host ""
    }
    break
}

if ($args.Count -ge 2) {
    $server = $args[0]
    $port = $args[1]

    $server = $server.ToString().Replace("https://", "")
    $server = $server.ToString().Replace("http://", "")

    $loop = $null
    if (($null -ne $args[2]) -and ($args[2] -ne "")) {
        $loop = $args[2]
    }
    Write-Host ""
    if (($null -ne $loop) -and (($loop -eq "-t") -or ($loop -eq "/t") -or ($loop -eq "t"))) {
        while ($true) {
            $result = TestServerPort -ComputerName $server -Port $port -Timeout 500

            if ($result) {
                Write-Host "    Connection success $($server):$($port)"
            }
            else {
                Write-Host "    Connection error $($server):$($port)"
            }
            Start-Sleep -Seconds 1
        }
    }
    else {
        $result = TestServerPort -ComputerName $server -Port $port -Timeout 500

        if ($result) {
            Write-Host "    Connection success $($server):$($port)"
        }
        else {
            Write-Host "    Connection error $($server):$($port)"
        }
    }
}
else {
    Write-Host ""
    Write-Host "    Error. Provide required arguments. Example: tel server1 443"
    Write-Host "    Write -? or -h to get help. Example: tel -h"
}

Не тянет это все на сетевика. Обыкновенные навыки обыкновенного админа в обыкновенном малом / среднем бизнесе. Сетевик это обычно все же Энтерпрайз/ провайдер / оператор связи.

С точки зрения админа и безопасника устанавливать netcat без особой необходимости на хостах наверное не надо, чтобы не облегчать задачу тому кто захочет каким нибудь 'reverse shell' баловаться.


Eще есть такой аспект что рвать коннект для теста не всегда хорошо для приложения (могут появляться нежелательные ошибки в логах) и утилиты типа tcping более мягко обходятся с сервером. Хотя tcping вроде тоже не может отличить дропнутый фаерволом пакет от не слушающего сервера.


А есть что то менее мощное чем nc чтобы такое диагностировало?

чтобы не облегчать задачу тому кто захочет каким нибудь 'reverse shell' баловаться.

Тот, кто получит доступ к хосту для целей reverse shell, разве не сможет залить на сервер свой собственный netcat?


Eще есть такой аспект что рвать коннект для теста не всегда хорошо для приложения (могут появляться нежелательные ошибки в логах)

Ну, хорошо, мы так делать не будем. Это остановит злоумышленника?


не может отличить дропнутый фаерволом пакет от не слушающего сервера.

А как технически это отличать?

Тот, кто получит доступ к хосту для целей reverse shell, разве не сможет залить на сервер свой собственный netcat?

Может но не так просто чем если nc уже там. Можно и однострочник на питоне сделать
Как и вся другая ИБ эта мера чтобы уменьшить вероятность и усложнить эксплуатацию уязвимости а не исключить ее полностью

Ну, хорошо, мы так делать не будем. Это остановит злоумышленника?

Ну как раз появление странных логов от неаккуратных сканеров может быть хорошим звоночком

А как технически это отличать?

См в статье. Мое скромное понимание в том что фаервол можно сконфигурять 2 варианта ответа

1) REJECT — в этом случае мы говогрим всему миру что тут есть Фаервол и он посылает тебя подальше с явным сообщением что сюда не ходи. Соответсвует как правило 'Connection closed'
2) DROP — тогда ответ не отличим от отсутствующего сервиса. Ответ не посылается и клиента просто игнорят — нас тут нет. Как правило это скорее показывается как 'Timeout'

Внутри сети обычно хорошие админы и сетевики ставят REJECT чтобы облегчить дебаг и вовне DROP чтобы не облегчать (см выше)

Дислкожа — я не сетевик так что поправляйте если что
1) REJECT — в этом случае мы говогрим всему миру что тут есть Фаервол и он посылает тебя подальше с явным сообщением что сюда не ходи. Соответсвует как правило 'Connection closed'
2) DROP — тогда ответ не отличим от отсутствующего сервиса. Ответ не посылается и клиента просто игнорят — нас тут нет. Как правило это скорее показывается как 'Timeout'

Ох...

Не всегда на нужном сервере есть права на установку, да и телнет клиент на некоторых системах не установлен по умлочанию. Еще про проверку TCP и UDP портов через devfs в линуксе можно упомянуть:
cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_8.3
^C
или так:
< /dev/udp/8.8.8.8/53 || echo "Not OK" && echo "OK"
OK
Это не «в линуксе», это в bash — причем конкретной версии и конкретной сборки.
«Ncat: Connection refused» — скорее скажет о том, что порт не слушается на сервере.
Очень редко FW настраивают на отправку RST в запрос на соединение.
А диагностика сети с использованием strace и анализом трассировки стека — это конечно круто, но больно и сложно.
getnameinfo(getaddrinfo(HOSTNAME)) = HOSTMANE


Условие так себе, как мне кажется. ;)
Сетевики, может, где-то и нужны, но SDNы жмут по всем фронтам, кровавые энтерпрайзы уходят в облака и рынок для таких специалистов сужается просто драматическими темпами.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

27 августа 2015

Местоположение

Россия

Сайт

ruvds.com

Численность

11–30 человек

Дата регистрации

18 марта 2016

Блог на Хабре