每次黑客攻击事件进行追溯的时候,根据日志分析后,我们往往发现基本都是系统、Web、 弱口令、配置这四个方面中的其中一个出现的安全问题导致黑客可以轻松入侵的。
有这种类似一个服务器式的漏扫机器,比如华为的“VSCAN”:
也有集成到笔记本的那种漏扫机器,比如启明星辰的“镜脆弱性扫描与管理系统”:
盒子部署形态一般是串在客户内网中,对客户的内网资产以及暴露的服务面进行主机+Web扫描。
目前硬件盒子这种漏扫设备一般都集成很多扩展功能,比如有大屏展示,防病毒、自动基线检查、入侵检测等功能,以及漏洞管理、漏洞识别与自动修复,不管是后期的复核、处置,确实是要更方便些的。
在线漏扫的话,一般难以对内网进行检测。大多数的操作是,在验证外网某站的所有权后,再签协议授权扫描。不过由于成本较盒子更加低廉,容易受到中小厂商的追捧。
比如virustotal可以对公网的web服务进行扫描:
比如manageengine对主机扫描需要依赖客户下载一个agent:
离线漏扫是指那些漏洞库已经集成到本地的漏扫软件中,比如开源漏扫攻击Nmap,它通常会检测以下信息:网络上有哪些主机可用,主机在运行什么服务,主机在运行哪些操作系统版本,使用哪种类型的数据包过滤器和防火墙,以及发动攻击之前需要的其他有用情报:
再比如有一些破解的漏扫软件,AWVS和Burpsuite Scanner都十分优秀:
比较轻量级别的漏扫,一般是通过浏览器流量代理进行分析,或者通过浏览器本身提供扩展插件功能,直接对页面进行即时钩子探测。比如说burpsuite插件wyproxy的衍生扫描器,ysrc的GourdScan:
启明星辰和绿盟是漏扫界的扛把子:
近日,赛迪顾问发布《中国漏洞评估与管理产品市场研究报告(2023)》(以下简称《报告》),报告显示:2022年,启明星辰集团“天镜脆弱性扫描与管理系统” 以18.8%的份额占据市场第一。至此,启明星辰集团已连续六年领跑漏洞评估与管理市场。 近期,国际数据咨询公司IDC正式发布《中国IT安全软件市场跟踪报告,2023H2》。在2023年中国响应和编排软件市场,绿盟科技凭借其卓越的漏洞扫描技术,以20.1%的市场份额位列第一,实现漏洞管理市场“十三连冠”。
让我们看看他们的技术指标:
自主研发的基于网络的脆弱性分析、评估与管理系统
以vulnerability management future关键字google了一番,将一些大佬们的文章翻译汇总如下:
直到最近,组织的大部分强制性漏洞管理计划主要依赖于扫描工具。团队将执行强制性的月度或季度配置审计和网络扫描,这将产生任何团队都无法完全涵盖的冗长报告。这意味着组织投入了大量时间来尝试验证和解决所有报告的威胁,但从未完全成功地解决所有威胁。
不断发展的开发生态系统、快节奏的开发需求以及已知安全漏洞数量的增加,都需要一种新的漏洞识别方法,以及适用于各种系统和平台的自动扫描工具。检测、优先级排序、补救和报告,自动化起来。
开源软件因其成本效益和灵活性而被广泛使用。但是,它也容易受到漏洞的影响,使其成为网络犯罪分子的主要目标。随着组织努力保护其开源应用程序,像 Vuelt 这样专注于开源软件的在线漏洞扫描程序将变得更加普遍。
随着越来越多的企业将其运营迁移到云,漏洞扫描程序将不断发展,以满足基于云的应用程序和基础设施的独特安全需求。这些工具将与各种云提供商无缝集成,从而跨不同的云环境提供全面的漏洞扫描。
漏洞评估工具未来的一个令人兴奋的前景是可能开发无代理流程或将代理直接集成到平台中。这意味着,内置代理将在平台正常运行期间向监控系统报告,而不是安装额外的软件。这类似于将防病毒软件直接内置到设备的 CPU 中,从而简化整个过程并提高漏洞管理效率。
人工智能通过识别模式和预测潜在漏洞,正在彻底改变漏洞管理。机器学习模型可以分析大量数据以更快地检测弱点,使企业能够在攻击者利用其系统之前主动保护其系统。
现代漏洞管理工具正在整合实时威胁情报,以提供更好的决策能力。通过集成已知的威胁数据,组织可以优先考虑构成最高风险的漏洞,将精力集中在最重要的领域。
Nmap (“Network Mapper(网络映射器)”) 是一款开放源代码的 网络探测和安全审核的工具。它的设计目标是快速地扫描大型网络,当然用它扫描单个 主机也没有问题。Nmap以新颖的方式使用原始IP报文来发现网络上有哪些主机,那些 主机提供什么服务(应用程序名和版本),那些服务运行在什么操作系统(包括版本信息), 它们使用什么类型的报文过滤器/防火墙,以及一堆其它功能。
nmap -v -A 192.168.134.35
Nmap scan report for 192.168.134.35
Host is up (0.00019s latency).
Not shown: 999 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4 (protocol 2.0)
MAC Address: EE:C2:83:7E:E0:28 (Unknown)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.14
Uptime guess: 10.478 days (since Mon Dec 9 07:28:14 2024)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
TRACEROUTE
HOP RTT ADDRESS
1 0.19 ms 192.168.134.35
. .
\`-"'"-'/
} 6 6 {
==. Y ,==
/^^^\ .
/ \ ) Ncat: A modern interpretation of classic Netcat
( )-( )/
-""---""--- /
/ Ncat \_/
( ____
\_.=|____E
nmap源码还很大,nmap共有10个扫描阶段:脚本预扫描 > 目标枚举 > 主机发现(ping扫描) > 反向DNS解析 > 端口扫描 > 版本检测 > 操作系统检测 > Traceroute > 脚本扫描 > 输出> 编写后扫描脚本,我们就挑核心功能瞄瞄。
任何网络探测任务的最初几个步骤之一就是把一组IP范围(有时该范围是巨大的)缩小为 一列活动的或者您感兴趣的主机。扫描每个IP的每个端口很慢,通常也没必要。在许多网络上,在给定的时间,往往只有小部分的IP地址是活动的。 这种情况在基于RFC1918的私有地址空间如10.0.0.0/8尤其普遍。 那个网络有16,000,000个IP,但我见过一些使用它的公司连1000台机器都没有。 主机发现能够找到零星分布于IP地址海洋上的那些机器。
Nmap一般会有以下几种方式进行主机发现:
nmap.h
) 文件中的DEFAULT-TCP-PROBE-PORT值进行配置--data-length
UDP报文到给定的端口,大部分是一个不可能被使用的端口31338,原因是如果到达一个开放的端口,大部分服务仅仅忽略这个 空报文而不做任何回应。核心代码如下:
/* Sends a ping probe to the host. Assumes that caller has already
checked that sending is OK w/congestion control and that pingprobe is
available */
static void sendPingProbe(UltraScanInfo *USI, HostScanStats *hss) {
tryno_t tryno = {0};
tryno.fields.isPing = 1;
tryno.fields.seqnum = hss->nextPingSeq();
probespec *pingprobe = &hss->target->pingprobe;
switch (pingprobe->type) {
case PS_CONNECTTCP:
sendConnectScanProbe(USI, hss, pingprobe->pd.tcp.dport, tryno);
break;
case PS_TCP:
case PS_UDP:
case PS_SCTP:
case PS_PROTO:
case PS_ICMP:
sendIPScanProbe(USI, hss, pingprobe, tryno);
break;
case PS_ARP:
sendArpScanProbe(USI, hss, tryno);
break;
case PS_ND:
sendNDScanProbe(USI, hss, tryno);
break;
default:
assert(0);
}
if (o.debugging > 1) {
char tmpbuf[64];
log_write(LOG_PLAIN, "Ultrascan PING SENT to %s [%s]\n", hss->target->targetipstr(),
probespec2ascii(pingprobe, tmpbuf, sizeof(tmpbuf)));
}
USI->gstats->probes_sent++;
}
许多传统的端口扫描器只列出所有端口是开放还是关闭的, Nmap的信息粒度比它们要细得多。 它把端口分成六个状态:
应用程序正在该端口接收TCP 连接或者UDP报文。
关闭的端口对于Nmap也是可访问的(它接受Nmap的探测报文并作出响应), 但没有应用程序在其上监听。
由于包过滤阻止探测报文到达端口, Nmap无法确定该端口是否开放。过滤可能来自专业的防火墙设备,路 由器规则 或者主机上的软件防火墙。这样的端口让攻击者感觉很挫折,因为它们几乎不提供 任何信息。有时候它们响应ICMP错误消息如类型3代码13 (无法到达目标: 通信被管理员禁止),但更普遍的是过滤器只是丢弃探测帧, 不做任何响应。 这迫使Nmap重试若干次以访万一探测包是由于网络阻塞丢弃的。 这使得扫描速度明显变慢。
未被过滤状态意味着端口可访问,但Nmap不能确定它是开放还是关闭。 只有用于映射防火墙规则集的ACK扫描才会把端口分类到这种状态。 用其它类型的扫描如窗口扫描,SYN扫描,或者FIN扫描来扫描未被过滤的端口可以帮助确定 端口是否开放。
当无法确定端口是开放还是被过滤的,Nmap就把该端口划分成 这种状态。开放的端口不响应就是一个例子。没有响应也可能意味着报文过滤器丢弃 了探测报文或者它引发的任何响应。
该状态用于Nmap不能确定端口是关闭的还是被过滤的。 它只可能出现在IPID Idle扫描中。
这几种扫描状态看的人一头雾水,但是不要慌,我们结合端口扫描的源码一一分析以下:
/* 3rd generation Nmap scanning function. Handles most Nmap port scan types.
The parameter to gives group timing information, and if it is not NULL,
changed timing information will be stored in it when the function returns. It
exists so timing can be shared across invocations of this function. If to is
NULL (its default value), a default timeout_info will be used. */
void ultra_scan(std::vector<Target *> &Targets, const struct scan_lists *ports,
stype scantype, struct timeout_info *to)
// Ultra_scan sets o.scantype for us so we don't have to worry
if (o.synscan)
ultra_scan(Targets, &ports, SYN_SCAN);
if (o.ackscan)
ultra_scan(Targets, &ports, ACK_SCAN);
if (o.windowscan)
ultra_scan(Targets, &ports, WINDOW_SCAN);
if (o.finscan)
ultra_scan(Targets, &ports, FIN_SCAN);
if (o.xmasscan)
ultra_scan(Targets, &ports, XMAS_SCAN);
if (o.nullscan)
ultra_scan(Targets, &ports, NULL_SCAN);
if (o.maimonscan)
ultra_scan(Targets, &ports, MAIMON_SCAN);
if (o.udpscan)
ultra_scan(Targets, &ports, UDP_SCAN);
if (o.connectscan)
ultra_scan(Targets, &ports, CONNECT_SCAN);
if (o.sctpinitscan)
ultra_scan(Targets, &ports, SCTP_INIT_SCAN);
if (o.sctpcookieechoscan)
ultra_scan(Targets, &ports, SCTP_COOKIE_ECHO_SCAN);
if (o.ipprotscan)
ultra_scan(Targets, &ports, IPPROT_SCAN);
它常常被称为半开放扫描, 因为它不打开一个完全的TCP连接。它发送一个SYN报文, 就像您真的要打开一个连接,然后等待响应。 SYN/ACK表示端口在监听 (开放),而 RST (复位)表示没有监听者(close)。如果数次重发后仍没响应, 该端口就被标记为被过滤。如果收到ICMP不可到达错误 (类型3,代码1,2,3,9,10,或者13),该端口也被标记为被过滤。
调用完全连接到开放的目标端口而不是像SYN扫描进行半开放的复位。
缺点是统上的服务会在syslog留下记录,IDS(入侵检测系统)可以捕获两者,甚至告警
扫描到的状态同上
UDP扫描发送空的(没有数据)UDP报头到每个目标端口。 如果返回ICMP端口不可到达错误(类型3,代码3), 该端口是closed
(关闭的)。 其它ICMP不可到达错误(类型3, 代码1,2,9,10,或者13)表明该端口是filtered
(被过滤的)。 偶尔地,某服务会响应一个UDP报文,证明该端口是open
(开放的)。 如果几次重试后还没有响应,该端口就被认为是 open|filtered
(开放|被过滤的)。 这意味着该端口可能是开放的,也可能包过滤器正在封锁通信。
速率是瓶颈,Linux式的一秒钟一个报文的限制使65,536个端口的扫描要花18小时以上
Null扫描 (-sN
)
不设置任何标志位(tcp标志头是0)
FIN扫描 (-sF
)
只设置TCP FIN标志位。
Xmas扫描 (-sX
)
设置FIN,PSH,和URG标志位,就像点亮圣诞树上所有的灯一样。
除了探测报文的标志位不同,这三种扫描在行为上完全一致。 如果收到一个RST报文,该端口被认为是 closed
(关闭的),而没有响应则意味着 端口是open|filtered(开放或者被过滤的)
。 如果收到ICMP不可到达错误(类型 3,代号 1,2,3,9,10,或者13),该端口就被标记为 被过滤的
。
这些扫描的关键优势是它们能躲过一些无状态防火墙和报文过滤路由器。 另一个优势是这些扫描类型甚至比SYN扫描还要隐秘一些。
探测报文是FIN/ACK。 根据RFC 793 (TCP),无论端口开放或者关闭,都应该对这样的探测响应RST报文。 然而,Uriel注意到如果端口开放,许多基于BSD的系统只是丢弃该探测报文。
在用某种其它类型的扫描方法发现TCP 和/或者UDP端口后, 版本探测会询问这些端口,确定到底什么服务正在运行。 nmap-service-probes
数据库包含查询不同服务的探测报文 和解析识别响应的匹配表达式。 Nmap试图确定服务协议 (如 ftp,ssh,telnet,http),应用程序名(如ISC Bind,Apache httpd,Solaris telnetd),版本号, 主机名,设备类型(如 打印机,路由器),操作系统家族 (如Windows,Linux)以及其它的细节,如是否可以连接X server,SSH协议版本 ,或者KaZaA用户名)。
当然,并非所有服务都提供所有这些信息。
当Nmap从某个服务收到响应,但不能在数据库中找到匹配时, 它就打印一个特殊的fingerprint和一个URL给您提交,如果您确实知道什么服务运行在端口。 请花两分钟提交您的发现,让每个人受益。由于这些提交, Nmap有350种以上协议如smtp,ftp,http等的大约3,000条模式匹配。
核心思想是:利用已探测好的端口,向其法术Banner信息(欢迎语),在服务端回应Banner信息中可以的到软件开发商、软件名称、版本、服务类型等信息,这些信息是存在nmap数据库中的,如下:
##############################NEXT PROBE##############################
MQTT v3.1.1 CONNECT
Probe TCP mqtt q|\x10\x10\x00\x04MQTT\x04\x02\x00\x1e\x00\x04nmap|
rarity 9
ports 1883
sslports 8883
match mqtt m|^\x20\x02\x00.$|
这是一个脚本语言,解析后的意思如下:
向 1883 和 8883端口发送 MQTT 连接请求 ,报文内容如下:
\x10
:表示消息类型(CONNECT)。\x10
:剩余长度(2 字节)。\x00\x04MQTT
:协议名称(MQTT)。\x04
:协议版本(v3.1.1)。\x02
:连接标志。\x00\x1e
:保持活动时间。\x00\x04nmap
:客户端标识符(Client ID)。收到的报文中 匹配响应的模式 ,以\x20\x02\x00开头就是链接成功了, 它匹配一个以 CONNACK
消息开始,后跟成功返回码(02
)和一个字节的响应。
AP = AllProbes::service_scan_init();
// 创建一个新的 ServiceGroup 对象 SG,它包含了目标和探测信息。
SG = new ServiceGroup(Targets, AP);
... ...
// 启动探测服务
launchSomeServiceProbes(nsp, SG);
... ...
// 处理回报消息,其实就是匹配
looprc = nsock_loop(nsp, timeout);launchSomeServiceProbes(nsp, SG);
... ...
// This holds the service information for a group of Targets being service scanned.
class ServiceGroup {
public:
ServiceGroup(std::vector<Target *> &Targets, AllProbes *AP);
~ServiceGroup();
std::list<ServiceNFO *> services_finished; // Services finished (discovered or not)
std::list<ServiceNFO *> services_in_progress; // Services currently being probed
std::list<ServiceNFO *> services_remaining; // Probes not started yet
unsigned int ideal_parallelism; // Max (and desired) number of probes out at once.
ScanProgressMeter *SPM;
int num_hosts_timedout; // # of hosts timed out during (or before) scan
};
ServiceNFO负责管理特定的服务的探测细节。上述的ServiceGroup中就是管理ServiceNFO对象组成的列表。
ServiceNFO类包含以下信息:
服务指纹的管理(提供添加与获取等操作)
服务扫描对应的主机(Target *target)
服务探测匹配的信息(是否匹配、是否softmatch、ssl配置、产品、版本、CPE等信息)
管理探测包(服务扫描过程可能需要发送多个探测包,在此对当前探测包、下一个探测包进行管理)
管理回复包(提供添加与获取等操作)。
服务扫描所需的全部探测包AllProbes *AP;
和服务版本检测差不多,nmap把结果和数据库nmap-os-fingerprints
中超过 1500个已知的操作系统的fingerprints进行比较,如果有匹配,就打印出操作系统的详细信息。 每个fingerprint包括一个自由格式的关于OS的描述文本, 和一个分类信息,它提供供应商名称(如Sun),下面的操作系统(如Solaris),OS版本(如10), 和设备类型(通用设备,路由器,switch,游戏控制台,等)。
数据库如下:
# Linux CentOS5 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Fingerprint Linux 2.6.18
Class Linux | Linux || general purpose
CPE cpe:/o:linux:linux_kernel:2.6.18
SEQ(SP=F-CF%GCD=FA|1F4|2EE|3E8|4E2%ISR=8A-C2%TI=I%TS=U)
OPS(O1=M218%O2=M218%O3=M218%O4=M218%O5=M218%O6=M218)
WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF)
ECN(R=Y%DF=N%T=FA-104%TG=FF%W=FFFF%O=M218%CC=N%Q=)
T1(R=Y%DF=N%T=FA-104%TG=FF%S=O%A=O|S+%F=AS%RD=0%Q=)
T2(R=Y%DF=N%T=FA-104%TG=FF%W=0%S=Z%A=O|S%F=AR%O=%RD=0%Q=)
T3(R=Y%DF=N%T=FA-104%TG=FF%W=FFFF%S=O%A=O|S+%F=AS%O=M218%RD=0%Q=)
T4(R=Y%DF=N%T=FA-104%TG=FF%W=0%S=A|O%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=N%T=FA-104%TG=FF%W=0%S=Z%A=O|S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=N%T=FA-104%TG=FF%W=0%S=A|O%A=Z%F=R%O=%RD=0%Q=)
T7(R=Y%DF=N%T=FA-104%TG=FF%W=0%S=Z%A=O|S+%F=AR%O=%RD=0%Q=)
U1(DF=N%T=FA-104%TG=FF%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
IE(DFI=N%T=FA-104%TG=FF%CD=S)
SEQ描述顺序产生方式;OPS描述TCP包中可选字段的值;WIN描述TCP包的初始窗口大小;ECN(Explicit Congestion Notification)描述TCP明确指定拥塞通知时的特征;T1-T7描述TCP回复包的字段特征;U1描述向关闭的UDP发包产生的回复的特征;IE描述向目标机发送ICMP包产生的特征。
1. SEQ
SEQ(SP=F-CF%GCD=FA|1F4|2EE|3E8|4E2%ISR=8A-C2%TI=I%TS=U):
SP=F-CF:这是 TCP 序列号的生成模式,表示发送的包序列号。
GCD=FA|1F4|2EE|3E8|4E2:GCD(通用连接数据)可能表示不同的序列号生成策略。
ISR=8A-C2:ISR(初始序列号)可能用于 TCP 连接的初始状态。
TI=I:可能指示 TCP 选项的存在。
TS=U:表示时间戳选项的使用。
2. OPS
OPS(O1=M218%O2=M218%O3=M218%O4=M218%O5=M218%O6=M218):
这些字段表示 Nmap 发送的 TCP 操作类型。M218 表示发送的 TCP 包在不同条件下的响应情况,可能是 SYN、ACK、FIN 等。
3. WIN
WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF):
表示接收到的窗口大小,FFFF 表示窗口大小为最大值,可能用于检测操作系统的窗口大小策略。
4. ECN
ECN(R=Y%DF=N%T=FA-104%TG=FF%W=FFFF%O=M218%CC=N%Q=):
表示网络拥塞通知的支持情况。
R=Y:表示支持 ECN。
DF=N:表示不支持不分段标志。
T=FA-104:可能表示 TCP 的传输协议状态。
W=FFFF:窗口大小。
O=M218:表示操作系统支持特定的选项。
5. T1 到 T7
T1(R=Y%DF=N%T=FA-104%TG=FF%S=O%A=O|S+%F=AS%RD=0%Q=):
每个 T 字段代表不同的 TCP 探测类型(SYN、ACK 等)。
R=Y:表示响应成功。
DF=N:表示不分段。
T=FA-104:传输状态。
S=O、A=O:表示在特定条件下的发送和接收状态。
6. U1
U1(DF=N%T=FA-104%TG=FF%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G):
这个字段表示 UDP 探测的响应情况。
DF=N:表示不分段。
IPL=38:表示 IP 层的某些特性。
UN=0、RIPL=G 等表示 UDP 探测的响应特征。
7. IE
IE(DFI=N%T=FA-104%TG=FF%CD=S):
表示某些特定的 IP 选项和响应特征。
这些载荷通常包括 SYN、ACK、FIN 等不同的 TCP 标志,结合不同的窗口大小、序列号和选项,从而形成独特的指纹模式。
https://mp.weixin.qq.com/s/FL0Cl2W58u8br7VYaxsYwg
https://blog.csdn.net/2302_82189125/article/details/135961736
https://blog.csdn.net/huangxuzhi/article/details/109493388
https://www.venustech.com.cn/u/cms/www/202302/281656496119.pdf
https://www.nsfocus.com.cn/uploadfile/2019/1128/20191128110052291.pdf
https://nsfocusglobal.com/wp-content/uploads/2023/12/RSAS-Datasheet-231215.pdf
https://xz.aliyun.com/t/13023?time__1311=GqmhBKYKAKY5GKDsD7%2BEq7I50Ig7X6j07oD
https://blog.csdn.net/weixin_53801131/article/details/120256963
https://nmap.org/man/zh/man-host-discovery.html
https://cybersainik.com/predictive-prioritization-the-future-of-vulnerability-management/
https://uvm.zscaler.com/post/in-data-we-trust-the-next-gen-of-vulnerability-management
https://www.linkedin.com/pulse/embracing-future-vulnerability-management-robert-kelsall-1dyne
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。