Как да тествате конфигурацията на вашата защитна стена с Nmap и Tcpdump

Въведение

Настройването на защитна стена за вашата инфраструктура е чудесен начин да осигурите сигурност за вашите услуги. След като разработите политика, от която сте доволни, следващата стъпка е да тествате правилата на вашата защитна стена. Важно е да добиете добра представа дали правилата на вашата защитна стена правят това, което смятате, че правят, и да добиете представа как изглежда вашата инфраструктура за външния свят.

В това ръководство ще разгледаме някои инструменти и техники, които можете да използвате, за да потвърдите правилата на вашата защитна стена. Това са някои от същите инструменти, които злонамерените потребители могат да използват, така че ще можете да видите каква информация могат да намерят, като отправят заявки към вашите сървъри.

Предпоставки

В това ръководство ще приемем, че сте конфигурирали защитна стена на поне един сървър. Можете да започнете да изграждате своята политика за защитна стена, като следвате едно или повече от тези ръководства:

  • Iptables
    • Iptables Essentials: Общи правила и команди на защитната стена

    • Как да настроите защитна стена с UFW на Ubuntu 22.04
    • UFW Essentials: Общи правила и команди на защитната стена

    • Как да настроите защитна стена с помощта на FirewallD на Rocky Linux 9

    Можете също така да конфигурирате облачните защитни стени на DigitalOcean, които работят като допълнителен външен слой към вашите сървъри в инфраструктурата на DigitalOcean. По този начин не е необходимо да конфигурирате защитна стена на вашите сървъри.

    В това ръководство ще извикаме сървъра, съдържащ политиките на защитната стена, които искате да тествате на целта. В допълнение към вашата цел, вие също ще трябва да имате достъп до сървър, от който да тествате, разположен извън мрежата, която вашата защитна стена защитава. В това ръководство ще използвате сървър на Ubuntu 22.04 като ваша машина за одит.

    След като имате сървър, от който да тествате, и целите, които искате да оцените, можете да продължите с това ръководство.

    Трябва да извършвате дейностите, посочени в това ръководство, само върху инфраструктурата, която контролирате, за целите на одита на сигурността. Законите около сканирането на портове са несигурни в много юрисдикции. Известно е, че доставчиците на интернет услуги и други доставчици забраняват потребители, за които е установено, че сканират портове.

    Инструментите, които ще използваме за тестване на политиките на защитната стена

    Има доста различни инструменти, които можете да използвате, за да тествате нашите правила за защитна стена. Някои от тях имат припокриваща се функционалност. Няма да обхванем всеки възможен инструмент. Вместо това ще разгледаме някои общи категории инструменти за одит и ще разгледаме инструментите, които ще използваме в това ръководство.

    Пакетни анализатори

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

    За целите на това ръководство ще използваме инструмента tcpdump. Това е добър вариант, защото е мощен, гъвкав и повсеместен в Linux системи. Ще го използвате за заснемане на необработените пакети, докато изпълняваме нашите тестове, в случай че се нуждаем от преписа за по-късен анализ. Някои други популярни опции са Wireshark (или tshark, братовчед му от командния ред) и tcpflow, които могат да сглобяват цели TCP разговори по организиран начин.

    Порт скенери

    За да генерирате трафика и отговорите, които вашият анализатор на пакети да улови, ще използвате скенер за портове. Порт скенерите могат да се използват за създаване и изпращане на различни типове пакети до отдалечени хостове, за да се открие типа трафик, който сървърът приема. Злонамерените потребители често използват това като инструмент за откриване, за да се опитат да намерят уязвими услуги, които да експлоатират (част от причината да използвате защитна стена на първо място), така че ще използвате това, за да се опитате да видите какво може да открие нападателят.

    За това ръководство ще използвате инструмента за мрежово картографиране и сканиране на портове nmap. Можете да използвате nmap, за да изпращате пакети от различни типове, за да се опитате да разберете кои услуги са на целевата ви машина и какви правила на защитната стена я защитават.

    Настройка на машината за одит

    Преди да започнете, трябва да се уверите, че имаме инсталирани необходимите инструменти. Можете да получите tcpdump и nmap от хранилищата на Ubuntu. Стартирайте apt update, за да актуализирате вашите локални списъци с пакети, след което ги инсталирайте с apt install:

    1. sudo apt update

    2. sudo apt install tcpdump nmap

    След това създайте директория, където можете да съхранявате резултатите от сканирането:

    1. mkdir ~/scan_results

    За да сте сигурни, че получавате чисти резултати, излезте от всички сесии, които може да имате отворени между вашата система за одит и целевата система. Това включва SSH сесии, всякакви HTTP(S) връзки, които може да сте установили в уеб браузър и др.

    Сканирайте вашата цел за отворени TCP портове

    След като имаме готов сървър и файлове, ще започнете със сканиране на вашия целеви хост за отворени TCP портове.

    Всъщност има няколко TCP сканирания, които nmap знае как да прави. Най-доброто, с което обикновено започвате, е SYN сканиране, известно още като \полуотворено сканиране, тъй като всъщност никога не се договаря пълна TCP връзка. Това често се използва от нападателите, тъй като не се регистрира при откриване на проникване системи, защото никога не завършва пълно ръкостискане.

    Настройка на улавянето на пакети

    Преди да сканирате, ще настроите tcpdump за улавяне на трафика, генериран от теста. Това ще ви помогне да анализирате по-задълбочено изпратените и получените пакети по-късно, ако е необходимо. Създайте директория в ~/scan_results, за да можете да съхранявате заедно файловете, свързани с вашето SYN сканиране:

    1. mkdir ~/scan_results/syn_scan

    Можете да стартирате прихващане на tcpdump и да запишете резултатите във файл във вашата директория ~/scan_results/syn_scan със следната команда:

    1. sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

    По подразбиране tcpdump ще работи на преден план. За да стартирате вашето nmap сканиране в същия прозорец, ще трябва да поставите на пауза процеса tcpdump и след това да го рестартирате във фонов режим.

    Можем да поставим на пауза работещ процес, като натиснем CTRL-Z:

    Output
    ^Z
[1]+  Stopped                 sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

    Сега можете да рестартирате заданието във фонов режим, като напишете bg:

    1. bg

    Трябва да получите подобен ред на изход, този път без етикета \Stopped и с амперсанд в края, за да посочите, че процесът ще се изпълнява във фонов режим (т.е. вече няма да блокира вашия терминал):

    Output
    [1]+ sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets &

    Командата вече се изпълнява във фонов режим, следейки за всякакви пакети, преминаващи между вашите одитни и целевите машини. Вече можем да стартираме нашето SYN сканиране.

    Стартирайте SYN Scan

    С tcpdump, записващ вашия трафик към целевата машина, вие сте готови да стартирате nmap. Можете да стартирате nmap с тези флагове:

    • -sS: Това стартира SYN сканиране. Технически това е сканирането по подразбиране, което nmap ще извърши, ако не е даден тип сканиране, но ние ще го включим тук, за да бъде изрично.
    • -Pn: Това казва на nmap да пропусне стъпката за откриване на хост, което ще прекрати теста по-рано, ако хостът не отговори на ping. Тъй като знаете, че целта е онлайн, можете да пропуснете това.
    • -p-: По подразбиране SYN сканирането ще пробва само 1000-те най-често използвани порта. Това казва на nmap да провери всеки наличен порт.
    • -T4: Това задава времеви профил за nmap, като му казва да ускори теста с риск от малко по-малко точни резултати. 0 е най-бавният, а 5 е най-бързият. Тъй като сканирате всеки порт, можете да използвате това като базова линия и да проверите отново всички портове по-късно, които може да са докладвани неправилно.
    • -vv: Това увеличава подробността на изхода.
    • --reason: Това указва на nmap да предостави причината, поради която състоянието на порт е докладвано по определен начин.
    • -oN: Това записва резултатите във файл, който можете да използвате за по-късен анализ.

    Забележка: За да проверите IPv6, ще трябва да добавите флага -6 към вашите команди...

    Заедно командата ще изглежда така:

    1. sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results target_ip_addr

    Дори с шаблона за време, зададен на 4, сканирането вероятно ще отнеме доста време, тъй като преминава през 65 535 порта. Ще започнат да се отпечатват резултати, които изглеждат така:

    Output
    Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2022-12-19 16:54 EDT
Initiating Parallel DNS resolution of 1 host. at 16:54
Completed Parallel DNS resolution of 1 host. at 16:54, 0.12s elapsed
Initiating SYN Stealth Scan at 16:54
Scanning 198.51.100.15 [65535 ports]
Discovered open port 22/tcp on 198.51.100.15
Discovered open port 80/tcp on 198.51.100.15
SYN Stealth Scan Timing: About 6.16% done; ETC: 17:02 (0:07:52 remaining)
SYN Stealth Scan Timing: About 8.60% done; ETC: 17:06 (0:10:48 remaining)

. . .

    Спрете tcpdump Packet Capture

    След като сканирането приключи, можете да върнете нашия процес tcpdump обратно на преден план и да го спрете.

    Премахнете го от фона, като изпълните fg, за \foreground:

    1. fg

    Спрете изпълняващия се процес, като натиснете Ctrl+C.

    Анализиране на резултатите

    Сега трябва да имате два файла във вашата директория ~/scan_results/syn_scan. Един, наречен packets, генериран от изпълнението на tcpdump, и един, генериран от nmap, наречен nmap.results.

    Нека първо да разгледаме файла nmap.results:

    1. less ~/scan_results/syn_scan/nmap.results

    

    # Nmap 6.49BETA4 scan initiated Mon Dec 19 17:05:13 2022 as: nmap -sS -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/syn_scan/nmap.results 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 5 due to 9226 out of 23064 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 5 to 10 due to 14 out of 34 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.00097s latency).
Scanned at 2022-12-19 17:05:13 EDT for 2337s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
80/tcp open  http    syn-ack ttl 63

Read data files from: /usr/local/bin/../share/nmap
# Nmap done at Mon Dec 19 17:44:10 2022 -- 1 IP address (1 host up) scanned in 2336.85 seconds

    Маркираната област по-горе съдържа основните резултати от сканирането. Можете да заключите, че порт 22 и порт 80 са отворени на сканирания хост, за да се позволи SSH и HTTP трафик. Можете също така да видите, че 65 533 порта са затворени. Друг възможен резултат би бил \филтриран. Филтриран означава, че тези портове са били идентифицирани като спрени от нещо по мрежовия път. Може да е защитна стена на целта, но може също да са правила за филтриране на всеки от междинните хостове между одитните и целевите машини.

    За да видите действителния пакетен трафик, който е бил изпратен и получен от целта, можете да прочетете файла packets обратно в tcpdump, по следния начин:

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less

    Този файл съдържа целия разговор, проведен между двамата хостове. Можете да филтрирате по няколко начина.

    Например, за да видите само трафика, изпратен към целта, можете да въведете:

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less

    По същия начин, за да видите само трафика на отговорите, можете да промените dst на src:

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr' | less

    Отворените TCP портове биха отговорили на тези заявки със SYN пакет. Можем да търсим директно отговори за този тип с филтър като този:

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less

    Това ще ви покаже само успешните SYN отговори и трябва да съответства на портовете, които сте видели при изпълнението на nmap:

    Output
    reading from file packets, link-type EN10MB (Ethernet)
17:05:13.557597 IP 198.51.100.15.22 > 198.51.100.2.63872: Flags [S.], seq 2144564104, ack 4206039348, win 29200, options [mss 1460], length 0
17:05:13.558085 IP 198.51.100.15.80 > 198.51.100.2.63872: Flags [S.], seq 3550723926, ack 4206039348, win 29200, options [mss 1460], length 0

    Можете да направите повече анализи на данните, както сметнете за добре. Всичко е уловено за асинхронна обработка и анализ.

    Сканирайте вашата цел за отворени UDP портове

    Сега, след като вече знаете как да изпълнявате тези тестове, можете да завършите подобен процес, за да сканирате за отворени UDP портове.

    Настройка на улавянето на пакети

    Още веднъж създайте директория, в която да съхранявате вашите резултати:

    1. mkdir ~/scan_results/udp_scan

    Стартирайте отново запис на tcpdump. Този път запишете файла в новата директория ~/scan_results/udp_scan:

    1. sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets

    Поставете процеса на пауза и го поставете на заден план, като въведете Ctrl+Z и след това стартирате bg:

    1. bg

    Стартирайте UDP сканирането

    Сега сте готови да стартирате UDP сканирането. Поради естеството на UDP протокола, това сканиране обикновено отнема значително повече време от SYN сканирането. Всъщност може да отнеме повече от ден, ако сканирате всеки порт на системата. UDP е протокол без връзка, така че получаването на отговор може да означава, че портът на целта е блокиран, че е приет или че пакетът е загубен. За да се опита да направи разлика между тях, nmap трябва да препредаде допълнителни пакети, за да се опита да получи отговор.

    Повечето от флаговете ще бъдат същите, които сте използвали за SYN сканирането. Всъщност единственият нов флаг е:

    • -sU: Това казва на nmap да извърши UDP сканиране.

    Ускоряване на UDP теста

    Ако се притеснявате за времето, което отнема този тест, може първо да искате да тествате само част от вашите UDP портове. Можете да тествате само 1000-те най-често срещани порта, като оставите флага -p-. Това може значително да съкрати времето за сканиране. Ако обаче искате пълна картина, ще трябва да се върнете по-късно и да сканирате целия си диапазон от портове.

    Тъй като сканирате собствената си инфраструктура, може би най-добрият вариант за ускоряване на UDP сканирането е временно да деактивирате ограничаването на скоростта на ICMP в целевата система. Обикновено Linux хостовете ограничават ICMP отговорите до 1 в секунда (това обикновено е нещо добро, но не и за нашия одит), което означава, че пълното UDP сканиране ще отнеме над 18 часа. Можете да проверите тази настройка на вашата целева машина, като напишете:

    1. sudo sysctl net.ipv4.icmp_ratelimit

    

    Output
    net.ipv4.icmp_ratelimit = 1000

    \1000 е броят милисекунди между отговорите. Можете временно да деактивирате това ограничаване на честотата на целевата система, като напишете:

    1. sudo sysctl -w net.ipv4.icmp_ratelimit=0

    Много е важно да върнете тази стойност след теста.

    Изпълнение на теста

    Не забравяйте да запишете резултатите в директорията ~/scan_results/udp_scan. Всичко заедно, командата трябва да изглежда така:

    1. sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr

    След като сканирането приключи, трябва да върнете ограничението на скоростта на ICMP (ако сте го променили) на целевата машина:

    1. sudo sysctl -w net.ipv4.icmp_ratelimit=1000

    Спрете tcpdump Packet Capture

    Върнете процеса tcpdump обратно на преден план на вашата машина за проверка, като изпълните fg:

    1. fg

    След това спрете улавянето на пакета с Ctrl+C.

    Анализиране на резултатите

    Сега можете да разгледате генерираните файлове.

    Полученият файл nmap.results трябва да бъде подобен на последния резултат:

    1. less ~/scan_results/udp_scan/nmap.results

    

    # Nmap 6.49BETA4 scan initiated Mon Dec 19 12:42:42 2022 as: nmap -sU -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/udp_scan/nmap.results 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 50 due to 10445 out of 26111 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 50 to 100 due to 11 out of 23 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 100 to 200 due to 3427 out of 8567 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0010s latency).
Scanned at 2022-12-19 12:42:42 EDT for 9956s
Not shown: 65532 closed ports
Reason: 65532 port-unreaches
PORT    STATE         SERVICE REASON
22/udp  open|filtered ssh     no-response
80/udp  open|filtered http    no-response
443/udp open|filtered https   no-response

Read data files from: /usr/local/bin/../share/nmap
# Nmap done at Mon Dec 19 15:28:39 2022 -- 1 IP address (1 host up) scanned in 9956.97 seconds

    Ключова разлика между този резултат и резултата от SYN по-рано вероятно ще бъде количеството портове, маркирани с отворени|филтрирани. Това означава, че nmap не може да определи дали липсата на отговор означава, че дадена услуга е приела трафика или той е бил отхвърлен от някаква защитна стена или механизъм за филтриране по пътя на доставка.

    Анализирането на изхода на tcpdump също е значително по-трудно, защото няма флагове за връзка и защото трябва да съпоставите ICMP отговорите с UDP заявките.

    Можете да видите колко пакета е трябвало да изпрати nmap до портовете, които са докладвани като open|filtered, като поискате да видите UDP трафика към един от докладваните портове:

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 22'

    

    Output
    reading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet)
14:57:40.801956 IP 198.51.100.2.60181 > 198.51.100.15.22: UDP, length 0
14:57:41.002364 IP 198.51.100.2.60182 > 198.51.100.15.22: UDP, length 0
14:57:41.202702 IP 198.51.100.2.60183 > 198.51.100.15.22: UDP, length 0
14:57:41.403099 IP 198.51.100.2.60184 > 198.51.100.15.22: UDP, length 0
14:57:41.603431 IP 198.51.100.2.60185 > 198.51.100.15.22: UDP, length 0
14:57:41.803885 IP 198.51.100.2.60186 > 198.51.100.15.22: UDP, length 0

    Сравнете това с резултатите от един от сканираните портове, който е маркиран като \затворен:

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 53'

    

    Output
    reading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet)
13:37:24.219270 IP 198.51.100.2.60181 > 198.51.100.15.53: 0 stat [0q] (12)

    Можете да опитате ръчно да реконструирате процеса, през който преминава nmap, като първо съставите списък на всички портове, към които изпращаме UDP пакети, като използвате нещо подобно:

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets "udp" | awk '{print $5;}' | awk 'BEGIN { FS = "." } ; { print $5 +0}' | sort -u | tee outgoing

    След това можете да видите кои ICMP пакети получихме обратно, че портът е недостъпен:

    1. sudo tcpdump -nn -Q in -r ~/scan_results/udp_scan/packets "icmp" |  awk '{print $10,$11}' | grep unreachable | awk '{print $1}' | sort -u | tee response

    След това можете да вземете тези два отговора и да видите кои UDP пакети никога не са получили обратно ICMP отговор:

    1. comm -3 outgoing response

    Това трябва да съответства най-вече на списъка с портове, които nmap докладва (може да съдържа някои фалшиви положителни резултати от изгубени върнати пакети).

    Откриване на хост и услуга

    Можете да изпълните някои допълнителни тестове на вашата цел, за да видите дали е възможно nmap да идентифицира работещата операционна система или някоя от версиите на услугата. Създайте директория, в която да съхранявате вашите резултати от версията:

    1. mkdir ~/scan_results/versions

    Откриване на версиите на услугите на сървъра

    Можете да опитате да отгатнете версиите на услугите, изпълнявани на целта, чрез процес, известен като пръстов отпечатък. Вие извличате информация от сървъра и я сравнявате с известни версии в нашата база данни.

    tcpdump не би бил много полезен в този сценарий, така че можете да го пропуснете. Ако все пак искате да го заснемете, следвайте процеса, който сте използвали последния път.

    Сканирането nmap, което трябва да използвате, се задейства от флага -sV. Тъй като вече сте направили SYN и UDP сканирания, можете да подадете точните портове, които трябва да разгледате с флага -p. Тук ще разгледате 22 и 80 (портовете, които бяха показани в нашето SYN сканиране):

    1. sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr

    Ако прегледате резултатния файл, може да получите информация за работещата услуга, в зависимост от това колко \бъбрив е отговорът на услугата:

    1. less ~/scan_results/versions/service_versions.nmap

    

    # Nmap 6.49BETA4 scan initiated Mon Dec 19 15:46:12 2022 as: nmap -sV -Pn -p 22,80 -vv --reason -oN /home/user/scan_results/versions/service_versions.nmap 198.51.100.15
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0011s latency).
Scanned at 2022-12-19 15:46:13 EDT for 8s
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    syn-ack ttl 63 nginx 1.4.6 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/local/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Dec 19 15:46:21 2022 -- 1 IP address (1 host up) scanned in 8.81 seconds

    Тук можете да видите, че тестът успя да идентифицира версията на SSH сървъра и дистрибуцията на Linux, която го пакетира, както и приетата версия на SSH протокола. Той също така разпозна версията на Nginx и отново я идентифицира като съответстваща на пакет Ubuntu.

    Откриване на хост операционната система

    Можете да опитате да накарате nmap да познае хост операционната система въз основа на характеристиките на нейния софтуер и отговорите също. Това работи по същия начин като версията на услугата. Още веднъж ще пропуснем изпълнението на tcpdump от този тест, но можете да го изпълните, ако желаете.

    Флагът, от който се нуждаете, за да извършите откриване на операционна система, е -O (главната буква \O). Пълната команда може да изглежда по следния начин:

    1. sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr

    Ако прегледате изходния файл, може да видите нещо подобно:

    1. less ~/scan_results/versions/os_version.nmap

    

    # Nmap 6.49BETA4 scan initiated Mon Dec 19 15:53:54 2022 as: nmap -O -Pn -vv --reason -oN /home/user/scan_results/versions/os_version.nmap 198.51.100.15
Increasing send delay for 198.51.100.15 from 0 to 5 due to 65 out of 215 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 5 to 10 due to 11 out of 36 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 10 to 20 due to 11 out of 35 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 20 to 40 due to 11 out of 29 dropped probes since last increase.
Increasing send delay for 198.51.100.15 from 40 to 80 due to 11 out of 31 dropped probes since last increase.
Nmap scan report for 198.51.100.15
Host is up, received user-set (0.0012s latency).
Scanned at 2022-12-19 15:53:54 EDT for 30s
Not shown: 998 closed ports
Reason: 998 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
80/tcp open  http    syn-ack ttl 63
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=6.49BETA4%E=4%D=8/27%OT=22%CT=1%CU=40800%PV=N%DS=2%DC=I%G=Y%TM=55
OS:DF6AF0%P=x86_64-unknown-linux-gnu)SEQ(SP=F5%GCD=1%ISR=106%TI=Z%CI=Z%TS=8
OS:)OPS(O1=M5B4ST11NW8%O2=M5B4ST11NW8%O3=M5B4NNT11NW8%O4=M5B4ST11NW8%O5=M5B
OS:4ST11NW8%O6=M5B4ST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120
OS:)ECN(R=Y%DF=Y%T=40%W=7210%O=M5B4NNSNW8%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+
OS:%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
OS:T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A
OS:=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPC
OS:K=G%RUCK=G%RUD=G)U1(R=N)IE(R=N)

Uptime guess: 1.057 days (since Mon Dec 12 14:32:23 2022)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=245 (Good luck!)
IP ID Sequence Generation: All zeros

Read data files from: /usr/local/bin/../share/nmap
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Dec 12 15:54:24 2022 -- 1 IP address (1 host up) scanned in 30.94 seconds

    Виждаме, че в този случай nmap няма предположения за операционната система въз основа на подписа, който е видял. Ако беше получил повече информация, вероятно щеше да покаже различни проценти, които показват как подписът на целевата машина съответства на подписите на операционната система в нейните бази данни. Можете да видите подписа на пръстов отпечатък, който nmap получи от целта под реда TCP/IP fingerprint:.

    Идентификацията на операционната система може да помогне на атакуващия да определи кои експлойти могат да бъдат полезни в системата. Конфигурирането на вашата защитна стена да отговаря на по-малко запитвания може да попречи на точността на някои от тези методи за откриване.

    Заключение

    Тестването на вашата защитна стена и изграждането на информираност за това как изглежда вашата вътрешна мрежа за външен нападател може да помогне за минимизиране на риска. Информацията, която намирате от сондирането на собствената си инфраструктура, може да доведе до дискусия за това дали някое от вашите политически решения трябва да бъде преразгледано, за да се повиши сигурността. Може също така да осветли всички пропуски във вашата сигурност, които може да са възникнали поради неправилно подреждане на правила или забравени тестови политики. Препоръчително е редовно да тествате политиките си с най-новите бази данни за сканиране, за да подобрите или поне да поддържате текущото си ниво на сигурност.

    За да получите представа за някои подобрения в правилата за вашата защитна стена, вижте това ръководство.