The Big Programming Thread - Page 653

This will be my fifth year at defcon, anyone else going?

Web Security
The earliest distributed denial of service (DDoS) attacks reach back to the year 2000 when the internet was still in its infancy and even multinational organisations were unfamiliar with ways to protect themselves. A young Canadian nicknamed “mafiaboy” was able to disrupt the services of Amazon and Ebay causing an estimated over $1B in damages and bringing “cybercrime” to the forefront of attention (Michael Dennis, n.d.).
Fourteen years later systems still remain vulnerable to attacks, with Sony’s Playstation Network suffering a 48 hour downtime last year when an organised botnet group saturated login servers with fake traffic.
A common method of mitigating attacks is “blackholing” incoming requests when suspicious network activity is detected, but events like Sony are evident of an increasing sophistication in DDoS methods and a need for new techniques for companies to stay ahead of the game (Jason Schreier, 2014).
Although home users are far more capable these days at protecting themselves from becoming effected by Trojans and having their machines turned remotely into malicious bots, the “explosive” growth of internet speeds across the globe has lent to a huge increase in the power and prevalence of “brute force” DDoSing.
Fortunately this growth has benefitted DDoS protection services also, allowing companies to utilise the vast scale of cloud services to dampen and filter incoming requests during attacks and maintain normal operations. The cost of this protection and the expertise to install it does however take a toll.
More advanced DDoS protection comes in the form of application layer defences which rely on the ability to “accurately profile incoming traffic – to distinguish between humans, human-like bots and hijacked web browsers”. Incapsula, a web security service, describe how they utilise a multi-tier system that scans various attributes such as HTTP headers in order to filter human users and “good bots” (e.g. search engines) from suspicious traffic that fails to pass what they refer to as a “set of transparent challenges” (Eldad Chai, 2013).
Ultimately it looks as though DDoS is something here to stay and continues to be a cost – or a risk – that all online services have to put up with.


REFERENCES
Eldad Chai. (2013). Incapsula's Five-Ring Approach to Application Layer Protection. Available: https://www.incapsula.com/blog/application-layer-7-ddos-protection.html. Last accessed 27th June 2015.
Jason Schreier. (2014). How DDoS Attacks Work, And Why They're So Hard To Stop. Available: http://kotaku.com/how-ddos-attacks-work-and-why-theyre-so-hard-to-stop-1676445620. Last accessed 27th June 2015.
Michael Dennis. (n.d.). Denial of service attack. Available: http://www.britannica.com/topic/denial-of-service-attack. Last accessed June 27th 2015.

Comparing MQTT with a competing protocol
RESTful HTTP is inarguably one of the foremost web service architectures to date, utilising stateless client-server communication to pass HTTP messages between countless network devices ranging from mobile applications to your everyday desktop computer. Robust and logical, REST is known for being the leading standard that all developers are familiar with and hence is a go-to architecture for application development. However, with the modern proliferation of lightweight network devices and the need for faster, better technology we are seeing a rapid emergence of competitors to RESTful HTTP.
MQTT (Message Queuing Telemetry Transport) is one such competitor. Describing itself as “simple and lightweight”, MQTT began development in the 1990s and lately found its way into the limelight as the protocol for Facebook’s personal messaging system, subsequently being commended by a review by Verizon Wireless with “5 stars for security, 5 stars for battery and 4 stars for bandwidth” (Mobilebit, 2013).
Whereas HTTP was created as a request-response service through which devices communicate by exchanging messages directly, MQTT was designed with fragile, low latency networks in mind using a technique called publish/subscribe which allows communication between subscriber groups rather than individuals and has a focus on performance and scalability at the cost of being able to directly access members of the group (Wikipedia, n.d.).
In real-world terms, a publish-subscribe device is able to very quickly broadcast a message to its subscribers. It needn’t confirm the existence of its subscribers, nor does it need to handshake with them as we would see in a slower, conventional HTTP connection; it simply broadcasts its message and the recipients will access the broadcast as soon as they are able to.
Some disadvantages of this style of protocol do exist. Firstly, it may not be immediately clear to the publisher of a message when or if his message has been received. Secondly, a fast publisher of messages may overwhelm a slow subscriber (for example, imagine turning your phone on and getting 20 text messages in a row). Thirdly, and especially in the case where there are many subscribers, there is no control over the order in which messages are received by the subscribers. If message order is important then some additional service may have to exist in order to establish some degree of control (c2.com, n.d.).
Nevertheless, the advantages provided by MQTT over HTTP with regards to lightweight mobile devices are substantial. “In a mobile environment, response times, throughput, lower battery use and lower bandwidth” are all critical concerns and MQTT “uses less power to maintain an open connection, to receive messages and to send them and does these more quickly and more reliably” (Kathleen Holm, 2012).
Further advantages of MQTT are in development, with a non-TCP protocol being released in the form of MQTT-SN for the super-small network devices that cannot afford TCP/IP capabilities (Stefan Roth, 2014). Zigbee, a “wireless language that everyday devices use to connect to one another” is another such possibility of marriage between existing systems to bring MQTT out ahead of HTTP (Karl Miller, 2013).
It isn’t quite the end for HTTP yet however. In early 2015 the specification of HTTP/2 was published and debate has already begun as to how it will be compete in the market sector with MQTT. A recent blogger explained that although MQTT is smaller “on the wire”, extremely reliable and easier to implement, the new features of HTTP/2 could eventually catch up and prove better still (Tim Kellogg, 2015).

REFERENCES
c2.com. (2009). Publish Subscribe Model. Available: http://c2.com/cgi/wiki?PublishSubscribeModel. Last accessed 27th June 2015.
Mobilebit. (2013). REST is for sleeping. MQTT is for mobile. Available: https://mobilebit.wordpress.com/2013/05/03/rest-is-for-sleeping-mqtt-is-for-mobile/. Last accessed 27th June 2015.
Karl Miller. (2013). What about Zigbee?. Available: https://github.com/knolleary/pubsubclient/issues/26. Last accessed 27th June 2015.
Kathleen Holm. (2012). Using MQTT Protocol Advantages Over HTTP in Mobile Application Development. Available: https://www.ibm.com/developerworks/community/blogs/sowhatfordevs/entry/using_mqtt_protocol_advantages_over_http_in_mobile_application_development5?lang=en. Last accessed 27th June 2015.
Stefan Roth. (2014). IoT for tiny devices: Let’s talk MQTT-SN.Available: http://blog.zuehlke.com/en/iot-for-tiny-devices-lets-talk-mqtt-sn/. Last accessed 27th June 2015.
Tim Kellogg. (2015). Can HTTP/2 Replace MQTT?. Available: http://timkellogg.me/blog/2015/02/20/can-http2-replace-mqtt/. Last accessed 27th June 2015.
Wikipedia. (n.d.). Publish–subscribe pattern. Available: https://en.wikipedia.org/wiki/Publish–subscribe_pattern. Last accessed 27th June 2015.