Slide 1
Mapping Internet Sensors with Probe Response AttacksBy John
Bethencourt, Jason Franklin, and Mary VernonComputer Sciences
DepartmentUniversity of Wisconsin, Madison
Published in the Proceedings of the 14th USENIX Security
Symposium
Presented by: Peter Matthews
OutlineInternet Sensor NetworksProbe Response AttackCase Study:
Sans Internet Storm CenterSimulation ResultsGeneralizing the
attackCountermeasuresRelated WorkConclusionInternet Sensor
NetworksA collection of systems which monitor portions of the
Internet and produce statistics related to Internet traffic
patterns and anomalies.Log collection and analysis
centersCollaborative intrusion detection systemsHoneypots /
honeynetsNetwork telescopes / darknetsInternet Sensor
NetworksInternet sensors are useful for distributed intrusion
detection and monitoring such as:Quickly detecting worm outbreaks
and new attacks before a large number of vulnerable systems are
compromisedProviding useful aggregation of the occurrence of
relatively rare eventsDetermining the prevalence of malicious
activity like port scans, DoS attacks, and botnetsBlacklisting
hosts controlled by malicious usersSensor Privacy is CriticalThe
integrity of an Internet sensor network is based upon the
assumption that the IP addresses of systems that serve as sensors
are secret.If the addresses were known, information obtained by the
network could no longer be considered an accurate picture of
internet activity because attackers couldAvoid the addresses in
malicious activity like port scanning and worm spreading, allowing
it to go undetectedSkew sensor statistics to hide malicious
activityFlood the addresses with extraneous activity, causing valid
information to be lost in noiseDamage is permanentOrganizations
cannot easily change the IP addresses available to themInternet
sensor networks cannot arbitrarily pick who will participate5Probe
an IP address with activity that will be reported if the address is
monitoredWait for next report to be published, check for the
activity, and decide whether the address was monitoredRepeat for
every IP address
General Attack IdeaMaking the Problem TractableThere are simply
too many addresses to check sequentially~2.1 billion valid,
routable IP addressesMost logs only submitted to the ISC hourlySo,
check many in parallelVery small fraction of IP addresses are
monitored, so send same probe to many addressesIf no activity is
reported then can rule out all of themElse, report provides the
number of monitored addressesSince activity reported by port, send
probes with different ports to run many independent tests at the
same timeDivide and conquerPartition the IP space into search
intervals to manage this parallelismOnly one TCP packet necessary
for each probe
Probe Response AlgorithmThe basic probe response algorithm
operates in two stages.Stage I -- Probe the entire routable IP
space to count the number of sensors in each search interval, Si.
Drop empty search intervals.Stage II -- Iteratively probe each
remaining interval, Ri, discarding empty intervals until all
individual sensors are located.First StageBegin with list of 2.1
billion valid IP addresses and n low utilization portsDivide IP
range into n search intervals S1, S2, , SnSend TCP SYN packet on
port Pi to each address in SiWait time interval and retrieve port
reportRule out intervals corresponding to ports with no
activityPackets on port P1Packets on port P2Packets on port
P3Packets on port PnS1S2S3Sn9Distribute ports among k remaining
intervals R1, R2, , Rk, assigning n/k ports to eachFor each
RiDivide into n/k + 1 subintervalsSend a probe on port Pj to each
address in the jth subintervalNo need to probe last subinterval, as
can infer number of monitored addresses it contains from total for
parent intervalRepeat second stage with non-empty subintervals
until all addresses are marked as monitored or unmonitoredSecond
StageP1P2P3P410Sample Run11NoiseWhat if other activity is present
in port reports? For a large number of ports, there is a very low
average level of activityUse only ports that consistently have less
than k reports per time intervalSend k packets in each probeDivide
the number of reports by k and round downPortsReports of
Activity561 519,364 10
41,357 15
51,959 20
56,305 25
12Case Study:To evaluate the threat of probe response attacks,
paper analyzes the feasibility of mapping the SANS Internet Storm
CenterOne of the most important examples of systems which collect,
analyze, and report data from Internet sensorsA challenging network
to mapOver 680,000 IP addresses monitoredThese are broadly
scattered across the IP address space
ISC SensorsCurrently, the ISC collects packet filter logsLogs
primarily contain failed connection attemptsMore than 2,000
organizations and individuals participateLogs are typically
uploaded on an hourly basis
ISC Reports
The ISC publishes a number of reports and statisticsAttack uses
port reportsLists the amount of activity on each destination
portSimulation ScenariosT1 attacker 1.544 Mbps of upload
bandwidthFractional T3 attacker 38.4 Mbps of upload bandwidthOC6
attacker 384 Mbps of upload bandwidthMonitored locations based on
accurate, if obfuscated, representation of the IP addresses
monitored by the ISC
ResultsBandwidthSet of AddressesData SentTime to MapOC6ISC1300
GB2 days, 22 hoursFractional T3ISC687 GB4 days, 16 hoursT1ISC440
GB33 days, 17 hoursFractional T3Average cluster size 10~600 GB~2
daysFractional T3Totally Random-- No Clustering~860 GB~9
days19Supersets and SubsetsSuperset of the monitored addressesE.g.,
only interested in simply avoiding detectionIf a T1 attacker allows
.001 false negative rate Runtime reduced from 33 days and 17 hrs to
15 days and 18 hrsMisses 26 percent of the sensorsSubset of the
monitored addressesE.g., only interested in flooding the monitored
addresses with noiseIf a T3 attacker allows a .94 false positive
rateRuntime reduced from 112 to 78 hrsReturns 3.5 million false
positivesKey Simulation ResultsProbe response attacks are feasible
and thus pose a real threatBoth a real set of monitored IP
addresses and various synthetic sets can be mapped in reasonable
timeMapping is possible even with very limited resourcesAn attacker
with only a DSL line could do it in ~4 monthsTime to complete only
depends on upload bandwidthDoes not require significant state or
complete TCP handshakesThus, botnet utilization would not pose a
problem
Generalizing the AttackIn our attack, an attacker gains
information by:Sending probes with different destination ports to
different ranges of IP addressesNoting for which ports activity is
reportedUsing this information to determine the set of IP addresses
that could have received probesThe destination port appearing in
the probe sent out and later in the port reports is used by the
attacker as a covert channel in a message to themselvesCovert
ChannelsMany possible fields typically appearing in ISN reports are
suitable for use by attackers as covert channels in a message to
themselvesUsing one or more of these covert channels, an attacker
can encode information about a destination IP address in a
packetTime / dateSource IPSource networkSource portDestination
networkDestination portProtocol (TCP or UDP)Packet lengthCaptured
payload signatureCountermeasuresExisting approaches to hide
sensitive report dataHashing, Encryption, and PermutationsHash
report fields such as source address to hide data but allow test
for matchingPrefix-preserving permutations obscure source /
destination host addresses while still allowing useful analysis of
relationships between hostsBloom FiltersData structure allows for a
space efficient set membership tests with a configurable false
positive rateVulnerable to iterative probe response attacksThese do
not prevent probe attacks, as sufficient covert channels
remainIPv6Increases IP addresses from 32 bits to 128 bits2^128 =
3.4 1038Makes TCP/UDP scanning impracticalEffective countermeasure
if widely adoptedHowever, accounts for a tiny fraction of the used
addresses and the traffic in the public InternetLike egress
filtering, widespread adoption is difficult to achieveLimiting
InformationRestrict the information provided in public reports in
some wayKeep reports privateEliminate all public access to
reportsLimits the usefulness of the sensor networkOnly publish most
significant eventsStill provides some useful information, but not a
complete depiction of Internet conditionsAttackers may be able to
avoid detection by keeping their levels of activity below
thresholdsQuery limitingRequire payment, computational tasks, or
CAPTCHA to perform queryOnly slows mapping attacksDelayed
ReportingRetain the reports for a specified period of time before
their releaseFor example, release last week's dataForces attacker
to either wait a long period between iterations of attack or use a
non-adaptive algorithmDelaying reports greatly reduces the
usefulness of the sensor network in providing real-time
notification of new attacks and other phenomenaRandom Input
SamplingUse a random sample of the logs received in a time interval
order to generate reportsE.g., suppose an analysis center has a 80%
likelihood of discarding a log it receivesTo reduce the false
negative rate, the attacker would have to send multiple probesTo
reduce the false negative rate of 80% to 1%, an attacker would need
to a twenty-fold increase in bandwidthConclusion Paper
StrengthsPresents a simple, clear, and feasible attackPresents a
good survey of existing and proposed countermeasures to attacks on
sensor anonymityWell written
Conclusion Paper WeaknessesCountermeasures are not explored to
same depth as attackNo simulation-based examination of
countermeasure effectivenessSimulation may be overly
simplisticUnfortunate real-world effects like packet loss might
have a fairly significant effect given that each step of iterative
algorithm builds on results of the lastFuture WorkNon-adaptive
algorithmsMentioned in paper, do not require an iterative
approachEffective countermeasuresCombining random sampling, query
limiting, and minimal level of randomly delayed log reporting?Is
there simply some inevitable trade-off between utility and
anonymity?How to quantifyPublic-private approaches significant
events made public, the rest requiring privileged accessAn
opposite, if idealistic, approach make sensors so pervasive that
anonymity is no longer required