Blackhawk95/Heimdall.md

## Heimdall.md

      
    Raw
  

              Heimdall.md
            
          
    Heimdall : Mitigating the Internet of Insecure Things


IoT - {define}

Architecture [from background]
uses cloud API’s - gateway is required


Applications of IoT - {examples}
Growth of IoT

2025 - 6 trillion $ ( Mckinsey & Company : Economic growth)
2020 - 20.8 billion devices ( Gartner : Sales)


Threats

data Privacy breaches
cyber security breaches
Statistics

25 vulnerabilities per device on avg

80% easily crack-able password
70% dont encrypt traffic
60% vulnerable UI or Firmware


Biggest threats - Botnet - {define}

Attack Model
eg: Mirai - a novel botnet

600Gb/s DDoS attack on krebsonsecurity.com
1.1 - 1.5Tb/s   DDoS attack on OVH (french webhost )


Current Defense against conventional botnets

honey pots - {define}

IoT devices’ lack of UI, prevents obtaining much info


anomaly detection - {define}

Complex to design, tune


Why Heimdall ?

blanket defense is unachievable

fragmenatation
one device vulnerable - undermines the entire defense


Solution - securing the connecting point of all device - router


What is Heimdall ?

All seeing and all hearing guardian sentry of a ficitonal world “Asgard”
lightweight
whitelist-based policy mechanism
dynamic profile learning capabilities  [ for routers ]


Threat Model - [ major ones ]

passive eavesdropping
already comprimised joining the network
comprimising of remote destination , earlier benign
DNS poisoning attack
malicious remote login


VirusTotal - {define properly, investigate}

A 3rd party service which validates IP and DNS queries using RESTful API calls


Commercial IoT devices - {Image and classification based on specificity and processing speed}
Overview of Heimdall

creates profiles for every device in network
profile consist of statistical data and regular traffic pattern

no of packts per min

by types like UDP TCP DNS ARP


whitelist for both incoming and outgoing traffic

incoming - prevents malicious logins
outgoing - prevents illegitimate communication


creating whitelist

tracks all DNS req n reply
related hostnames and initially resolved IPs


Any traffic outside whitelist is blocked
Burst of traffic and deviation from normal volume - attack
Defense is of 2 phases - but performed concurrently

profile learning
profile enforcement


Challenges

consumer IoT have backend that uses load balancing, so IP changes - disrupt normal functioning
DNS poisoning attack - {define}


Advantages

Low Overhead {define why its good for IoT devices and not for PC’s}
Scalablility - new devices of same manufacturer can be accommodated easily [ compensation for load balancing helped here ]
Centralized Architecture - Most of devices use Cloud API’s for interoperability which is safeguarded by Heimdall.


Implementation Details

Linksys WRT1900AC router - {define}
OpenWRT - {define}
Python SOCKS proxy - {define}
Hashmaps as DS for Whitelist Managing, Destination Cache and global Blacklist


Architecture


[use image from paper]


Whitelist Manager

Identifies and validates destinations for each device
Have device specific and global whitelist and a global blacklist
Helper thread - for identifying a whitelisted destination turning malicious

if malicious - removes from global and device whitelist & add to G blacklist
search blacklist also to prevent earlier false positives

if found - adds to whitelist, removes from blacklist


Traffic Manager - Analysis packets sent and its destination -{flow chart}


Multilayered Policy Enforcement - Each device have different set of requirement ( 2 validation modes )

Maximum Throughput - {define} global blacklist only

Checks global blacklist and adds to devices white/blacklist accordingly


Real time Validation - {define} VT validation always


Protection against Malicious Remote Access

Maintains a list of remote login IP from which connection is allowed


Evaluation - {pics come here}

How they tested and Validation of Profile Completeness

5 IoT devices - 1 week
Modified gateway with Heimdall
Snapshot captured at different interval
Training phase

Did not dropped any service


Testing phase

Pi 2 with spoofed MAC acted as comprimised dev
Pinged random IPs and URLs and they were blocked automatically


DNS lookup Overhead - DNS query performed for every new connection - overhead {pic}
Heimdall Network Overhead - HTTPing to measure latency

RTV vs MT - {pic} {pic}
general overhead - usage of SOCKS proxy


Security Analysis - {goal}

All ready compromised device joins the network and attacker exploiting local device to device communication

IP may be blacklisted earlier

device will be blocked from communicating


New malicious IP

Heimdall carries out verification with VirusTotal on given IP and if found insecure , blacklist IP and does case 1


Reliability of destination over time

Auditing process is carried out by Heimdall periodically
This finds out if any legitimate site became mallicious and blocks them
limiting the attack window for short period


legitimate Firmware update

range of valid address might change
Heimdall learns new destination after verification


Attacker carrying out DNS poisoning attack

since the IP obtained is verified with local DNS server, and if found difference, the new IP is blocked obtained IP is used


A malicious device communicates with hardcoded IP , without DNS queries.

If IP is not previously blocked

the destination is allowed until next assessment where it evaluates the pattern of communication changing, limiting the attack possibilities


Attacker tries to remote log into device and then take over

If in coming packets are not from whitelisted IP, then they are blocked.


{for all these above scenarios , heimdall functions well }


Conclusion

Defense mechanism aganist botnet
Validated Heimdall’s approach in real world scenarios
Whitelist based anomaly detection is practical and valid for IoT
For future implementations, Cloud support can also be used to provide better security.
No results found