7 ANALYSIS OF REMEDIATION EFFORTS
If we receive packets with spoofed source addresses from a client at
a given attachment point, but do not in subsequent tests from the
same attachment point, then we infer an operator has performed
remediation. Ideally, one could undertake A/B testing to measure
the efect of various interventions on remediation. However, we
cannot do follow-up tests ourselves; we must rely on our crowdsourced volunteers to re-test the same network.
We have had three distinct remediation phases in the project. In
May 2016, we began contacting networks where we had at least onetest showing that the network did not flter packets with spoofed
source addresses. We contacted the network abuse contact address
registered in WHOIS, falling back to the technical contact if there
was no abuse contact, or the technical contact registered in PeeringDB. We provide an example private notifcation email in appendix A. Then in April 2018, we began publishing geographically
scoped reports of remediated and still-spoofng-capable networks
to regional network operator group (NOG) email lists on a monthly
basis, while continuing to privately notify networks. We provide
an example public notifcation email in appendix B. Table 3 lists the
full set we cover as of August 2019; we sent our NOG notifcations
using an appropriate translation for the country. Finally, we ceased
sending private notifcations in December 2018.
In total, we inferred 587 instances where a network hosting a
Spoofer client transitioned from forwarding spoofed packets to
our system, to not doing so. Figure 13 shows that 24.0% of the remediations blocking outbound spoofng occurred within a day of
the frst test and 35.4% within a week, indicating that an operator
used our system to check for and deploy SAV. 48.2% of the remediation events we inferred took at least 1 month from the time we
received the spoofed packet to when we inferred an operator had
deployed SAV. Prior work observed remediation to vulnerabilities
such as Heartbleed [16] occurring within a shorter period of time,consistent with the self-defense, i.e., incentive-aligned, motive for
such remediation. It is difcult to separate the efect of a private
notifcation from other forces we do not observe in the 50% of cases
that took more than a month to remedy; in line with prior work,
we rarely received any response to our notifcations.
Figure 14a shows the cumulative private notifcations we sent
over time; we sent bursts of private notifcations at diferent times
(November 2016, October 2017, January 2018, and September 2018).
Figure 14b shows the cumulative deployment of SAV for outbound
spoofed packets over time; there were no corresponding bursts
of remediation observed in fgure 14b, leading us to believe the
private notifcations had limited impact. Further, the number of
remediations we infer per month doubles from 10.6 remediationsper month to 21.5 beginning April 2018 when we started publishing reports to NOG email lists, implying that public notifcation is
more efective in promoting deployment of SAV. Figure 14c shows
the cumulative deployment of SAV on inbound spoofed packets
over time. We do not publicly reveal the SAV policy of individual
networks on inbound packets for ethics reasons, as these represent
a vulnerability to the network itself. Private notifcations apparently had an impact on deploying SAV on inbound packets: when
we stopped them in December 2018, the number of remediations
reduced to one per month until April 2019. However, the burst of
inbound remediation beginning April 2019 is not connected to any
activity by the project.
Of the 587 remediation events we inferred between May 2016
and August 2019, 25.2% occurred in the U.S., and 23.5% occurred in
Brazil. Figure 15 shows that nearly 90% of the remediation events
in Brazil occurred after we began sending monthly emails to GTER.
We calculate the remediation rate by dividing the number of ASes
for which we inferred a remediation event by the total number of
ASes that sent a spoofed packet during the same interval. For the
year prior to commencing the GTER emails to Brazilian network
operators, 14 of 67 ASes (21%) remediated; in the year after, 52 of 168
ASes (31%) remediated. This improvement is supported by NIC.br’s
“Program for a Safer Internet” [45], which ofers training courses
and lectures to support network operators to deploy security best
practices in Brazil. The rate of remediation in the U.S. is lower; prior
to sending the NANOG emails to U.S. network operators, 21 of 132
(16%) of ASes remediated; in the year after, 35 of 147 (24%) of ASes
remediated. While the rate of remediation is lower in the U.S. than
Brazil, the relative improvement in both is equivalent – ≈50%.
Figure 16 shows two metrics that refect the efectiveness of our
system at reducing the spoofed address attack surface in the Internet. The purple line is the cumulative distribution of the widest IPv4
prefx a client can spoof after remediation. Half of the remediations
resulted in the client being unable to use any address apart from
their single assigned address; the remainder are covered by flters
that defned a range of valid addresses at the attachment point. This
class of remediation represents a total of 0.13% of the total routed
IPv4 address space. Because this statistic is dominated by clients
only able to use their assigned address, and it is unlikely that an
operator deployed SAV on a single network port, we also plot the
distribution of the longest matching prefx in BGP correspondingto the client’s IPv4 address, which sums to 3.01% of the total routed
IPv4 address space.
While we inferred remediation in 352 IPv4/24, we found 4,480
IPv4/24 with no evidence of remediation – 12.7 times as many
IPv4/24. Figure 17 shows the corresponding network sizes for the
unremediated networks. Relative to fgure 16, the sizes of the longest
matching prefxes are similar, suggesting that the size of a prefx is
not a limiting factor in the operators’ ability to deploy SAV. This
space sums to 8.14% of the total routed IPv4 address space. Finally,
fgure 18 shows that of the /24 prefxes where we had multiple tests
showing SAV had not been deployed, 21.0% had been unremediated
for at least six months
7 치료 노력 분석특정 첨부 지점에서 클라이언트로부터 스푸핑된 소스 주소가 포함된 패킷을 수신했지만 이후 테스트에서클라이언트로부터 스푸핑된 소스 주소가 포함된 패킷을 수신했지만 이후 테스트에서 동일한 첨부 지점에서동일한 첨부 지점에서 패킷을 받지 못하면 운영자가 수정 작업을추론합니다. 이상적으로는 A/B 테스트를 수행하여 다양한 개입의 효과를 측정할 수 있습니다.측정하기 위해 A/B 테스트를 수행할 수 있습니다. 하지만후속 테스트를 직접 수행할 수 없으므로 동일한 네트워크를 다시 테스트하기 위해 크라우드소싱된 자원 봉사자에게 의존해야 합니다.이 프로젝트에는 세 가지 개선 단계가 있었습니다. 1단계2016년 5월, 네트워크가 스푸핑된 소스 주소로 패킷을 전송하지 않는다는 것을 적어도 한 번 이상 확인한 네트워크에 연락을 취하기 시작했습니다.소스 주소. WHOIS에 등록된 네트워크 악용 연락처 주소에 연락하여 어뷰징 연락처가 없는 경우 기술 연락처로 돌아가거나어뷰징 연락처가 없거나 PeeringDB에 등록된 기술 연락처로 연락했습니다. 부록 A에 비공개 알림 이메일 예시를 제공합니다. 그리고 2018년 4월, 트위터는 지역적으로 한정된수정되었지만 여전히 스푸핑이 가능한 네트워크에 대한 지역적 범위의 보고서를지역 네트워크 사업자 그룹(NOG) 이메일 목록에 매월 게시하기 시작했습니다.네트워크에 비공개로 계속 통지하고 있습니다. 트위터는 다음을 제공합니다.부록 B에 공개 알림 이메일 예시를 제공합니다. 표 3에는 2019년 8월 기준2019년 8월 현재 트위터에서 다루는 전체 목록이 나와 있습니다.를 해당 국가에 맞게 번역하여 보냈습니다. 마지막으로, 트위터는2018년 12월에 비공개 알림 전송을 중단했습니다.총 587건의 사례를 추론한 결과, 스파우퍼 클라이언트를 호스팅하는 네트워크가스푸퍼 클라이언트를 호스팅하는 네트워크가 스푸핑된 패킷을 전달하던 방식에서우리 시스템으로 전환한 587건을 추론했습니다. 그림 13은 아웃바운드 스푸핑을 차단하는 치료의 24.0%가 첫 테스트 후 하루 이내에 발생했음을 보여줍니다.24.0%, 35.4%는 1주일 이내에 발생했으며, 이는 운영자가 시스템을 사용하여시스템을 사용하여 SAV를 확인하고 배포했음을 나타냅니다. 48.2%의 복구 이벤트는 스푸핑된 패킷을 수신한 시점부터 최소 1개월이 걸렸습니다.스푸핑된 패킷을 수신한 시점부터 운영자가 SAV를 배포했다고 추론한 시점까지최소 한 달이 걸렸습니다. 이전 연구에서는 하트블리드[16]와 같은 취약점에 대한 치료가 관찰되었습니다.하트블리드[16]와 같은 취약점이 더 짧은 기간 내에 수정되는 것을 관찰했는데, 이는 자기 방어, 즉 인센티브에 따른 수정 동기와 일치합니다.그러한 치료. 개인 통지의 효과를 분리하기는 어렵습니다.50%의 사례에서 관찰되지 않은 다른 세력으로부터의 통지를 분리하는 것은 어렵습니다.한 달 이상 걸렸으며, 이전 작업과 마찬가지로알림에 대한 응답을 거의 받지 못했습니다.그림 14a는 트위터에서 보낸 비공개 알림의 누적 건수를 보여줍니다.시간 경과에 따른 누적 비공개 알림을 보여줍니다.(2016년 11월, 2017년 10월, 2018년 1월, 2018년 9월).그림 14b는 시간 경과에 따른 아웃바운드 스푸핑 패킷에 대한시간 경과에 따른 스푸핑 패킷의 누적 배포를 보여줍니다.그림 14b에서 관찰된 치료 효과는 다음과 같습니다.개인 알림이 제한적인 영향을 미쳤다고 생각합니다. 또한개선 건수는 매월 10.6건에서 NOG 이메일 목록에 보고서를 게시하기 시작한 2018년 4월부터 21.5건으로 두 배로 증가했으며, 이는 공개 알림이SAV 배포를 촉진하는 데 더 효과적이라는 것을 의미합니다. 그림 14c는인바운드 스푸핑 패킷에 대한 SAV의 누적 배포 수누적 배포를 보여줍니다. 당사는 윤리적인 인바운드 패킷에 대한 개별 네트워크의 SAV 정책을윤리적인 이유로 인바운드 패킷에 대한 네트워크의 SAV 정책을 공개하지 않습니다.윤리적 이유로 공개하지 않습니다. 비공개 알림은 인바운드 패킷에 SAV를 배포하는 데 영향을 미친 것으로 보입니다.2018년 12월에 이를 중단한 후, 2019년 4월까지 수정 건수가2019년 4월까지 한 달에 한 건으로 감소했습니다. 하지만 2019년 4월부터 급증한2019년 4월부터 급증한 인바운드 수정은 프로젝트의 어떤 활동과도활동과 관련이 없습니다.2016년 5월부터 2019년 8월까지 추론한 587건의 문제 해결 이벤트 중587건 중 25.2%가 미국에서 발생했으며 23.5%는브라질에서 발생했습니다. 그림 15는 브라질에서 발생한 개선 이벤트의 거의 90%가의 거의 90%가 GTER에 매월 이메일을 보내기 시작한 이후에 발생했음을 보여줍니다.문제 해결 비율은 문제 해결을 유추할 수 있는 AS 수를의 수를 스푸핑을 전송한 총 AS 수로스푸핑된 패킷을 전송한 AS의 총 수로 나누어 계산합니다. GTER를 시작하기 전브라질 네트워크 사업자에게 GTER 이메일을 발송하기 전 1년간67개 AS 중 14개(21%)가 수정되었고, 그 다음 해에는 168개 중 52개(31%)가 수정되었습니다.AS 중 52개(31%)가 수정되었습니다. 이러한 개선은 NIC.br의"더 안전한 인터넷을 위한 프로그램"[45], 네트워크 운영자를 지원하기 위한 교육 과정과네트워크 운영자가 보안 모범 사례를 배포할 수 있도록 지원하는 강의와교육 과정과 강의를 제공합니다. 미국에서는 해결 비율이 더 낮습니다.미국 네트워크 사업자에게 NANOG 이메일을 보내기 전에 132명 중 21명(16%)이(16%), 그 후 1년 동안에는 147개 중 35개(24%)의 AS가 해결되었습니다.치료되었습니다. 미국은 브라질에 비해 개선 비율이 낮지만브라질보다 낮지만, 두 나라의 상대적 개선율은 ≈50%로 비슷합니다.그림 16은 스푸핑을 줄이는 데 있어 트위터 시스템의 효율성을 반영하는 두 가지 지표를 보여줍니다.인터넷에서 스푸핑된 주소 공격 표면을 줄이는 시스템의 효율성을 반영하는 두 가지 지표를 보여줍니다. 보라색 선은 클라이언트가 스푸핑할 수 있는 가장 광범위한 IPv4클라이언트가 수정 후 스푸핑할 수 있는 가장 넓은 IPv4 프리픽스의 누적 분포입니다.