这是一个创建于 477 天前的主题，其中的信息可能已经有所发展或是发生改变。
解决办法根据底下的的相关文章是禁止公网访问本机 LDAP
LDAP 规则为：
Active Directory Domain Controller - LDAP (TCP-In)
Active Directory Domain Controller - LDAP (UDP-In)
Active Directory Domain Controller - Searcure LDAP (TCP-In)
第一个问题，借这个机会想问问大家有没有还原欺骗性 IP 地址的方法，很好奇究竟是哪个 IP 发起的攻击(C&C)。而抓包我这边能看到的就是伪装过的 IP 了，经过半小时的查看发现被伪装的 IP(受害者)来自(由于猜测是受害者所以不发出 IP)以下机构：
Google Cloud Platform AS19527
Amazon Cloud Service AS16509
Japan Network Information Center(nic.ad.jp) AS9357
TELENOR-NEXTEL Telenor Norge AS (NO) AS119
RIALCOM-AS (RU) AS34456
CLOUDFLARENET (US) AS13335
DIGITALOCEAN-ASN (US) AS14061
SHAW (CA) AS6327
SCZN-AS (DE) AS34086
MICROSOFT-CORP-MSN-AS-BLOCK (US) AS8075
UUNET (US) AS701
OVH (FR) AS16276
值得注意的是在 Censys 上以上大部分可能为被伪装 IP 的受害者均没有任何端口开放
除了：
OVH 1 IP 是 OVH 分销商 搞高频游戏服务器的
DigitalOcean 1 IP 有 Web 服务器(我打开它运行的网站发现已经被打死了，很明显这个在 7 年前就发现的漏洞在 7 年后的 2023 年，CLDAP 仍在放大攻击中扮演着相当的角色)
AS34086 1 IP 是德国电信官网的源站
AS6327 1 IP 是加拿大运营商 SHAW 的互联网核心交换机(管理界面)
第二个问题，受害者均没有任何端口开放，为什么？ NAT 家宽出口 IP ？那打 NIC.AD.JP 的那个又是啥目的。。
遇到本次案例部分原因是该公司的 IP 是备案了的自治段，没有端口限制，并且发现该公司上游交换机没有启用 uRPF(Unicast Reverse Path Forwarding)，虽然与本次案例无关，但依旧提一下，这意味着该公司的 IP 也可以发起 IP 欺骗，利用互联网上有放大攻击漏洞的机器对受害者发起放大攻击。该公司的 IP 可能已经纳入某个个人或组织的 Server farm pool ，因为我一直收到新的请求，文章不能写这么长，大家有兴趣而且我也发现有更有意思的 IP 我可能会发出来，但是，我还是比较想知道上面两个问题的答案先~
https://support.steadfast.net/Knowledgebase/Article/View/preventing-ldap-amplification-attacks
https://www.alibabacloud.com/help/zh/ddos-protection/latest/api-ddoscoo-2020-01-01-describeddoseventattacktype
https://www.cnbeta.com.tw/articles/tech/1331447.htm
https://www.freebuf.com/articles/network/181884.html
https://www.exploit-db.com/exploits/40703
LDAP 规则为：
Active Directory Domain Controller - LDAP (TCP-In)
Active Directory Domain Controller - LDAP (UDP-In)
Active Directory Domain Controller - Searcure LDAP (TCP-In)
第一个问题，借这个机会想问问大家有没有还原欺骗性 IP 地址的方法，很好奇究竟是哪个 IP 发起的攻击(C&C)。而抓包我这边能看到的就是伪装过的 IP 了，经过半小时的查看发现被伪装的 IP(受害者)来自(由于猜测是受害者所以不发出 IP)以下机构：
Google Cloud Platform AS19527
Amazon Cloud Service AS16509
Japan Network Information Center(nic.ad.jp) AS9357
TELENOR-NEXTEL Telenor Norge AS (NO) AS119
RIALCOM-AS (RU) AS34456
CLOUDFLARENET (US) AS13335
DIGITALOCEAN-ASN (US) AS14061
SHAW (CA) AS6327
SCZN-AS (DE) AS34086
MICROSOFT-CORP-MSN-AS-BLOCK (US) AS8075
UUNET (US) AS701
OVH (FR) AS16276
值得注意的是在 Censys 上以上大部分可能为被伪装 IP 的受害者均没有任何端口开放
除了：
OVH 1 IP 是 OVH 分销商 搞高频游戏服务器的
DigitalOcean 1 IP 有 Web 服务器(我打开它运行的网站发现已经被打死了，很明显这个在 7 年前就发现的漏洞在 7 年后的 2023 年，CLDAP 仍在放大攻击中扮演着相当的角色)
AS34086 1 IP 是德国电信官网的源站
AS6327 1 IP 是加拿大运营商 SHAW 的互联网核心交换机(管理界面)
第二个问题，受害者均没有任何端口开放，为什么？ NAT 家宽出口 IP ？那打 NIC.AD.JP 的那个又是啥目的。。
遇到本次案例部分原因是该公司的 IP 是备案了的自治段，没有端口限制，并且发现该公司上游交换机没有启用 uRPF(Unicast Reverse Path Forwarding)，虽然与本次案例无关，但依旧提一下，这意味着该公司的 IP 也可以发起 IP 欺骗，利用互联网上有放大攻击漏洞的机器对受害者发起放大攻击。该公司的 IP 可能已经纳入某个个人或组织的 Server farm pool ，因为我一直收到新的请求，文章不能写这么长，大家有兴趣而且我也发现有更有意思的 IP 我可能会发出来，但是，我还是比较想知道上面两个问题的答案先~
https://support.steadfast.net/Knowledgebase/Article/View/preventing-ldap-amplification-attacks
https://www.alibabacloud.com/help/zh/ddos-protection/latest/api-ddoscoo-2020-01-01-describeddoseventattacktype
https://www.cnbeta.com.tw/articles/tech/1331447.htm
https://www.freebuf.com/articles/network/181884.html
https://www.exploit-db.com/exploits/40703
目前尚无回复
Select Language