介绍
为您的基础设施设置防火墙是为您的服务提供一些基本安全性的好方法。 一旦您制定了您满意的策略,下一步就是测试您的防火墙规则。 了解您的防火墙规则是否在做您认为他们正在做的事情并了解您的基础设施在外界看来是什么样子的,这一点很重要。
在本指南中,我们将介绍一些可用于验证防火墙规则的简单工具和技术。 这些是恶意用户可能使用的一些相同工具,因此您将能够通过向您的服务器发出请求来查看他们可以找到哪些信息。
先决条件
在本指南中,我们假设您至少在一台服务器上配置了防火墙。 您可以按照以下一项或多项指南开始构建防火墙策略:
- Iptables
- UFW
- FirewallD
在本指南中,我们将调用包含您希望测试 目标 的防火墙策略的服务器。 除了您的目标之外,您还需要访问位于防火墙保护的网络之外的服务器进行测试。 在本指南中,我们将使用 Ubuntu 14.04 服务器作为我们的审计机器。
一旦您有了要测试的服务器和要评估的目标,您就可以继续阅读本指南。
警告
出于安全审计的目的,您只应在您控制的基础架构上执行本指南中概述的活动。 在许多司法管辖区,有关端口扫描的法律都不确定。 众所周知,ISP 和其他提供商会禁止发现端口扫描的用户。
我们将用于测试防火墙策略的工具
我们可以使用很多不同的工具来测试我们的防火墙策略。 其中一些具有重叠的功能。 我们不会涵盖所有可能的工具。 相反,我们将介绍一些一般类别的审计工具,并回顾我们将在本指南中使用的工具。
数据包分析器
数据包分析器可用于非常详细地观察通过接口的所有网络流量。 大多数数据包分析器可以选择实时操作,在数据包发送或接收时显示数据包,或者将数据包信息写入文件并稍后处理。 数据包分析使我们能够在粒度级别查看目标机器向开放网络上的主机发送回哪些类型的响应。
出于我们指南的目的,我们将使用 tcpdump
工具。 这是一个不错的选择,因为它功能强大、灵活且在 Linux 系统上无处不在。 我们将在运行测试时使用它来捕获原始数据包,以防我们需要脚本以供以后分析。 其他一些流行的选项是 Wireshark(或 tshark
,它的命令行表亲)和 tcpflow
,它们可以以有组织的方式拼凑整个 TCP 对话。
端口扫描仪
为了生成数据包分析器捕获的流量和响应,我们将使用端口扫描器。 端口扫描器可用于制作各种类型的数据包并将其发送到远程主机,以发现服务器接受的流量类型。 恶意用户经常使用它作为发现工具来尝试发现易受攻击的服务(首先使用防火墙的部分原因),因此我们将使用它来尝试查看攻击者可以发现什么。
对于本指南,我们将使用 nmap
网络映射和端口扫描工具。 我们可以使用 nmap
发送不同类型的数据包,以尝试找出目标机器上有哪些服务以及哪些防火墙规则保护它。
设置审计机
在开始之前,我们应该确保我们拥有上面讨论的工具。 我们可以从 Ubuntu 的存储库中获取 tcpdump
。 我们也可以用这个方法得到nmap
,但是仓库版本可能已经过时了。 相反,我们将安装一些软件包来帮助我们进行软件编译,然后自己从源代码构建它。
如果软件不可用,请更新本地软件包索引并安装软件。 如果已经安装了 nmap
,我们还将从我们的系统中清除它以避免冲突:
sudo apt-get update sudo apt-get purge nmap sudo apt-get install tcpdump build-essential libssl-dev
现在我们有了编译工具和SSL开发库,我们可以从官网的下载页面获取最新版本的nmap
。 在您的网络浏览器中打开该页面。
向下滚动到“源代码分发”部分。 在底部,您将看到 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 端口。
实际上有一些 nmap
知道如何进行的 TCP 扫描。 最好的开始通常是 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
您应该会看到类似的输出行,这次没有“Stopped”标签,末尾带有 & 符号,表示该进程将在后台运行:
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:这会将结果写入一个文件,我们可以将其用于以后的分析。
笔记
要记住的一件事是,为了检查 IPv6,您需要在命令中添加 -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
~/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 端口的一个子集。 通过省略 -p-
标志,您只能测试 1000 个最常用的端口。 这可以大大缩短您的扫描时间。 但是,如果您想要完整的图片,则必须稍后返回并扫描整个端口范围。
因为您正在扫描自己的基础架构,所以加快 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
~/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
如何通过要求查看到报告的端口之一的 UDP 流量来向报告为 open|filtered
的端口发送许多数据包:
sudo tcpdump -nn -Q 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 -Q 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 -Q 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 -Q 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
~/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
~/scan_results/versions/os_versions.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
没有根据它看到的签名猜测操作系统。 如果它收到更多信息,它可能会显示各种百分比,这些百分比表明目标机器的签名如何匹配其数据库中的操作系统签名。 您可以在 TCP/IP fingerprint:
行下方看到 nmap
从目标接收到的指纹签名。
操作系统识别可以帮助攻击者确定哪些漏洞可能对系统有用。 将防火墙配置为响应较少的查询可能有助于阻碍其中一些检测方法的准确性。
结论
测试您的防火墙并了解外部攻击者对您的内部网络的了解可以帮助您将风险降至最低。 您从探索自己的基础架构中发现的信息可能会引发关于是否需要重新审视您的任何策略决策以提高安全性的对话。 它还可以说明由于不正确的规则顺序或忘记的测试策略而可能导致的任何安全漏洞。 建议您使用最新的扫描数据库定期测试您的策略,以提高或至少保持您当前的安全级别。
要了解防火墙的一些策略改进,请查看 本指南 。