介绍
为您的基础设施设置防火墙是为您的服务提供一些基本安全性的好方法。 一旦您制定了一个您感到满意的策略,下一步就是测试您的防火墙规则。 重要的是要了解你的防火墙规则是否正在做你认为他们正在做的事情,并得到你的基础设施看起来像外部世界的印象。
在本指南中,我们将介绍一些可用于验证防火墙规则的简单工具和技术。 这些是恶意用户可能使用的一些工具,因此您可以查看他们通过请求您的服务器可以找到什么信息。
先决条件
在本指南中,我们假设您在至少一台服务器上配置了防火墙。 您可以通过以下一个或多个指南来开始构建防火墙策略:
- Iptables
- UFW
- 防火墙
在本指南中,我们将调用包含要测试目标的防火墙策略服务器。 除了目标之外,您还需要访问服务器以进行测试,位于防火墙保护的网络外部。 在本指南中,我们将使用Ubuntu 14.04服务器作为审计机。
一旦您有一个服务器来测试和您想要评估的目标,您可以继续本指南。
我们将使用的工具测试防火墙策略
有很多不同的工具,我们可以用来测试我们的防火墙策略。 其中一些具有重叠的功能。 我们不会涵盖一切可能的工具。 相反,我们将涵盖一些一般类别的审核工具,并将讨论我们将在本指南中使用的工具。
数据包分析器
分组分析器可用于非常详细地观察经过接口的所有网络流量。 大多数分组分析器具有实时操作,在发送或接收分组时显示分组,或者将分组信息写入文件并在稍后处理它的选项。 分组分析使我们能够在粒度级别上看到目标机器发送回开放网络上的主机的什么类型的响应。
对于我们的指南的目的,我们将使用tcpdump
工具。 这是一个很好的选择,因为它在Linux系统上是强大,灵活,而且无所不在。 我们将使用它来捕获原始数据包,因为我们运行我们的测试,以防万一我们需要抄本供以后分析。 其他一些流行的选项是Wireshark的(或tshark
,它的命令行表弟),并tcpflow
可以在一个有组织的方式完整的TCP会话拼凑。
端口扫描器
为了生成流量和响应我们的数据包分析器捕获,我们将使用端口扫描器。 端口扫描器可用于制作和发送各种类型的数据包到远程主机,以发现服务器接受的流量类型。 恶意用户经常使用它作为发现工具来尝试找到易受攻击的服务(首先使用防火墙的部分原因),因此我们将使用它来尝试查看攻击者可以发现什么。
对于本指南中,我们将使用nmap
网络映射和端口扫描工具。 我们可以用nmap
发送不同类型的数据包,试图弄清楚哪些服务是我们的目标机器,什么防火墙规则保护它。
设置审核机
在我们开始之前,我们应该确保我们有上面讨论的工具。 我们可以得到tcpdump
从Ubuntu的存储库。 我们还可以得到nmap
使用这种方法,但库中的版本可能过时。 相反,我们将安装一些软件包以帮助我们进行软件编译,然后从源代码自行构建。
更新本地软件包索引并安装软件(如果尚不可用)。 我们也将清除nmap
从我们的系统是否已经安装,以避免冲突:
sudo apt-get update
sudo apt-get purge nmap
sudo apt-get install tcpdump build-essential libssl-dev
现在,我们有我们的编译工具和SSL开发库,我们可以得到最新版本nmap
对从下载页面官方网站 。 在Web浏览器中打开该页面。
向下滚动到“源代码分发”部分。 在底部,你会看到一个链接到源代码的最新版本nmap
。 在写这篇文章的时候,它看起来像这样:
右键单击链接并复制链接地址。
回到您的审核机器上,移动到你的主目录,并使用wget
下载你所粘贴的链接。 请务必更新以下链接,以反映您从网站复制的最新版本:
cd ~
wget https://nmap.org/dist/nmap-6.49BETA4.tar.bz2
解压缩您下载的文件,并通过键入以下内容移动到生成的目录:
tar xjvf nmap*
cd nmap*
通过键入以下命令配置和编译源代码:
./configure
make
编译完成后,您可以通过键入以下内容在系统上安装生成的可执行文件和支持文件:
sudo make install
键入以下内容确认安装:
nmap -V
输出应该与您从下载的版本nmap
网站:
OutputNmap version 6.49BETA4 ( https://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.1f nmap-libpcre-7.6 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select
接下来,我们将创建一个目录,我们可以存储我们的扫描结果:
mkdir ~/scan_results
为了确保获得干净的结果,请退出您可能在审计系统和目标系统之间打开的任何会话。 这包括SSH会话,您可能已在Web浏览器中建立的任何HTTP(S)连接等。
扫描目标以打开TCP端口
现在我们已经准备好了我们的服务器和文件,我们将开始通过扫描我们的目标主机来打开TCP端口。
其实有这几个TCP扫描nmap
知道该怎么办。 最好的一个通常开始是一个SYN扫描,也被称为“半开放扫描”,因为它从来没有真正协商一个完整的TCP连接。 这通常被攻击者使用,因为它无法在某些入侵检测系统上注册,因为它从不完成完整的握手。
设置数据包捕获
我们扫描之前,我们将设立tcpdump
捕捉由测试所产生的流量。 这将帮助我们分析发送和接收更深入的数据包,如果我们需要。 让我们创建的一个目录~/scan_results
这样我们就可以保持与我们的SYN扫描在一起的文件:
mkdir ~/scan_results/syn_scan
我们可以开始一个tcpdump
捕捉,结果在我们的文件~/scan_results/syn_scan
使用下面的命令目录:
sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets
默认情况下, tcpdump
将在前台运行。 为了运行我们的nmap
在同一窗口扫描,我们需要暂停tcpdump
过程,然后在后台重新启动它。
我们可以通过点击暂停运行的进程CTRL-Z
CTRL-Z
这将暂停正在运行的进程:
Output^Z
[1]+ Stopped sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets
现在,您可以重新启动通过键入后台工作bg
:
bg
您应该看到类似的输出行,这一次没有“停止”标签,并在末尾带有&符,表示该过程将在后台运行:
Output[1]+ sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets &
该命令现在在后台运行,监视在我们的审计和目标机器之间的任何数据包。 我们现在可以运行我们的SYN扫描。
运行SYN扫描
随着tcpdump
记录我们的流量到目标机器上,我们已经准备好运行nmap
。 我们将使用下面的选项来获得nmap
来执行我们要求的操作:
-
-sS
:这将启动一个SYN扫描。 这在技术上是默认的扫描nmap
,如果没有扫描类型给出将执行,但我们会包括在这里被明确。 -
-Pn
:这告诉nmap
跳过主机发现步骤,这将早期中止测试,如果主机不响应ping。 由于我们知道目标是在线,我们可以跳过这一点。 -
-p-
:默认情况下,SYN扫描将只尝试了1000个最常用的端口。 这告诉nmap
检查每一个可用的端口。 -
-T4
:设置一个定时信息为nmap
,告诉它加快在稍微较不准确的结果的风险的测试。 0是最慢的,5是最快的。 由于我们正在扫描每个端口,我们可以使用它作为我们的基线,并重新检查以后可能已报告不正确的任何端口。 -
-vv
:这增加了输出的详细程度。 -
--reason
:这告诉nmap
提供一个端口的状态报以某种方式的原因。 -
-oN
:这将结果写入,我们可以使用供以后分析的文件。
-6
标志你的命令。
由于大多数必备教程不接受IPv6流量,因此我们将跳过本指南的IPv6。
如果您的防火墙接受IPv6流量,请添加此标志。
在一起,命令将看起来像这样:
sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results target_ip_addr
即使定时模板设置为4,扫描可能需要相当长的时间,因为它运行65,535端口(我的测试运行持续约40分钟)。 你会看到结果开始打印,看起来像这样:
OutputStarting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-26 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数据包捕获
一旦扫描完成后,我们可以把我们的tcpdump
进程重新进入前台并停止它。
通过键入以下内容将其带出背景:
fg
按住控制键并点击“c”停止进程:
CTRL-C
分析结果
现在你应该在你的两个文件~/scan_results/syn_scan
目录。 一个叫packets
,通过所产生的tcpdump
运行,一个所产生nmap
称为nmap.results
。
让我们来看看nmap.results
文件中的第一:
less ~/scan_results/syn_scan/nmap.results
# Nmap 6.49BETA4 scan initiated Wed Aug 26 17:05:13 2015 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 2015-08-26 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 Wed Aug 26 17:44:10 2015 -- 1 IP address (1 host up) scanned in 2336.85 seconds
上面突出显示的区域包含扫描的主要结果。 我们可以看到端口22和端口80在扫描的主机上是打开的,以便允许SSH和HTTP流量。 我们还可以看到65,533个港口关闭。 另一个可能的结果是“过滤”。 过滤意味着这些端口被识别为由沿着网络路径的某些东西停止。 它可以是目标上的防火墙,但也可以是在审计和目标机器之间的任何中间主机上过滤规则。
如果我们要看到,被送往并收到来自目标的实际数据包流量,我们可以读出packets
文件恢复到tcpdump
,就像这样:
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less
此文件包含在两个主机之间发生的整个会话。 您可以通过多种方式进行过滤。
例如,只查看发送到目标的流量,你可以输入:
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less
同样,要仅查看响应流量,您可以将“dst”更改为“src”:
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr' | less
打开TCP端口将使用SYN数据包响应这些请求。 我们可以直接搜索这种类型的响应,使用这样的过滤器:
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less
这将显示只有成功的SYN反应,并应与您在看到端口nmap
运行:
Outputreading 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端口。
设置数据包捕获
再次,让我们创建一个目录来保存我们的结果:
mkdir ~/scan_results/udp_scan
启动tcpdump
再次捕获。 这一次,将文件写入到新的~/scan_results/udp_scan
目录:
sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets
暂停进程并将其放入后台:
CTRL-Z
bg
运行UDP扫描
现在,我们准备运行UDP扫描。 由于UDP协议的性质,这种扫描通常显著更长的时间比所述SYN扫描。 事实上,如果您扫描系统上的每个端口,它可能需要一天的时间。 UDP是无连接协议,因此接收无响应可能意味着目标的端口被阻止,它被接受,或者数据包丢失。 要尝试这些区分, nmap
必须重新传输数据包的附加尝试得到回应。
大多数标志将与我们用于SYN扫描的标志相同。 事实上,唯一的新标志是:
-
-sU
:这告诉nmap
执行UDP扫描。
加快UDP测试
如果您担心此测试需要的时间量,您可能只想首先测试一部分UDP端口。 你可以离开了测试只有1000最常见的端口-p-
标志。 这可以大大缩短您的扫描时间。 如果你想要一个完整的图片,你将不得不回来以后扫描整个端口范围。
由于您正在扫描自己的基础架构,因此加速UDP扫描的最佳选择是暂时禁用目标系统上的ICMP速率限制。 通常,Linux主机将ICMP响应限制为每秒1次(这通常是好事,但不是我们的审核),这意味着完整的UDP扫描将需要18个小时。 您可以通过键入以下内容在目标计算机上检查此设置:
sudo sysctl net.ipv4.icmp_ratelimit
Outputnet.ipv4.icmp_ratelimit = 1000
“1000”是响应之间的毫秒数。 我们可以通过键入以下内容临时禁用目标系统上的此速率限制:
sudo sysctl -w net.ipv4.icmp_ratelimit=0
在你的测试之后恢复这个值是非常重要的。
运行测试
请务必将结果写入到~/scan_results/udp_scan
目录。 所有在一起,命令应该看起来像这样:
sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr
即使禁用目标上的ICMP速率限制,此扫描在我们的测试运行期间花费了大约2小时45分钟。 扫描完成后,您应该还原目标计算机上的ICMP速率限制(如果您已修改它):
sudo sysctl -w net.ipv4.icmp_ratelimit=1000
停止tcpdump数据包捕获
把tcpdump
过程中回通过键入您的审核机器上的前景:
fg
通过保持控制和击中“c”停止数据包捕获:
CTRL-c
分析结果
现在,我们可以看看生成的文件。
由此产生的nmap.results
文件应该看起来非常相似,我们以前看到的一个:
less ~/scan_results/udp_scan/nmap.results
# Nmap 6.49BETA4 scan initiated Thu Aug 27 12:42:42 2015 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 2015-08-27 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 Thu Aug 27 15:28:39 2015 -- 1 IP address (1 host up) scanned in 9956.97 seconds
这个结果和SYN结果前面的一个关键区别很可能是端口的数量标志着open|filtered
。 这意味着它们nmap
无法确定缺乏响应是否意味着一个服务接受通信或是否它是由沿着输送路径一些防火墙或过滤机制丢弃。
分析tcpdump
输出也显著更加困难,因为没有连接标志和因为我们必须ICMP响应UDP请求匹配。
我们可以看到如何nmap
有很多数据包发送出去的报道,由于口岸open|filtered
通过询问,看UDP流量所报告的端口之一:
sudo tcpdump -nn -P out -r ~/scan_results/udp_scan/packets 'udp and port 22'
你可能会看到这样的东西:
Outputreading 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
将此与我们从一个已标记为“已关闭”的已扫描端口中看到的结果进行比较:
sudo tcpdump -nn -P out -r ~/scan_results/udp_scan/packets 'udp and port 53'
Outputreading 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数据包,使用像这样的端口列表经历:
sudo tcpdump -nn -P out -r ~/scan_results/udp_scan/packets "udp" | awk '{print $5;}' | awk 'BEGIN { FS = "." } ; { print $5 +0}' | sort -u | tee outgoing
然后,我们可以看到我们收到哪些ICMP数据包说端口不可达:
sudo tcpdump -nn -P in -r ~/scan_results/udp_scan/packets "icmp" | awk '{print $10,$11}' | grep unreachable | awk '{print $1}' | sort -u | tee response
我们可以看到,然后采取这两个响应,并看到哪些UDP数据包从来没有收到一个ICMP响应通过键入:
comm -3 outgoing response
这应该主要是匹配的端口列表nmap
报道(它可能包含丢失返回数据包的一些误判)。
主机和服务发现
我们可以在我们的目标运行一些额外的测试,看它是否是可能的nmap
识别操作系统运行或任何服务版本。
让我们创建一个目录来保存我们的版本化结果:
mkdir ~/scan_results/versions
发现服务器上的服务版本
我们可以尝试通过称为指纹识别的过程来猜测在目标上运行的服务的版本。 我们从服务器检索信息,并将其与我们的数据库中的已知版本进行比较。
一个tcpdump
不会在这种情况下太有用了,所以我们可以跳过它。 如果你想捕获它,无论如何,按照我们上次使用的过程。
该nmap
扫描,我们需要使用由触发-sV
标志。 既然我们已经做了SYN和UDP扫描,我们可以在我们想要看的确切端口通过-p
标志。 这里,我们将看看22和80(在我们的SYN扫描中显示的端口):
sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr
如果您查看结果的文件,您可以获得有关服务运行的信息,具体取决于“聊天”或甚至服务的响应独特性:
less ~/scan_results/versions/service_versions.nmap
# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:46:12 2015 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 2015-08-27 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 Thu Aug 27 15:46:21 2015 -- 1 IP address (1 host up) scanned in 8.81 seconds
在这里,您可以看到测试能够识别SSH服务器版本和打包它的Linux发行版以及接受的SSH协议版本。 它还认可了Nginx的版本,并再次将其标识为与Ubuntu包匹配。
发现主机操作系统
我们可以尝试有nmap
猜测基于其软件的特点和反应,以及主机操作系统。 这与服务版本控制的工作方式大致相同。 再次,我们将省略tcpdump
从这个测试运行,但您可以执行它,如果你愿意的话。
我们需要以执行操作系统检测标志是-O
(大写字母“O”)。 完整命令可能如下所示:
sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr
如果查看输出文件,您可能会看到如下所示的内容:
less ~/scan_results/versions/os_version.nmap
# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:53:54 2015 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 2015-08-27 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 Wed Aug 26 14:32:23 2015)
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 Thu Aug 27 15:54:24 2015 -- 1 IP address (1 host up) scanned in 30.94 seconds
我们可以看到,在这种情况下, nmap
具有用于基于它看到签名操作系统没有猜测。 如果它收到更多的信息,它可能会显示各种百分比,表明目标机器的签名如何匹配其数据库中的操作系统签名。 你可以看到,指纹签名nmap
从下面的目标接收TCP/IP fingerprint:
行。
操作系统识别可以帮助攻击者确定哪些漏洞可能对系统有用。 配置防火墙以响应较少的查询可能会妨碍某些检测方法的准确性。
结论
测试防火墙并建立内部网络对外部攻击者的外观的意识可以帮助最小化您的风险。 您在探测自己的基础架构时发现的信息可能会引发一场对话,讨论您的任何政策决策是否需要重新访问以提高安全性。 它还可以照亮您的安全中可能由于不正确的规则排序或忘记的测试策略而发生的任何差距。 建议您使用最新的扫描数据库测试策略,以便改进或至少维护当前的安全级别。
要获得为您的防火墙策略的一些改进的想法,请查看本指南 。