And to think the original design of the internet was to ensure that connectivity could be routed away from a bomb blasted section, inherent resiliency in design needs to be a core design consideration into the future.
It was and still is. That's why there isn't a single, centralized name server. There are thirteen and they're spread across the globe. And thousands of next-level servers underneath them. And thousands more another layer down.
DNS does have a lot of resiliency, which is why it's still working despite the attacks.
I'm fairly certain it was malware installed on Samsung Internet connected refrigerators launching a coordinated, distributed attack to take down appleinsider.com. The other minor players were just collateral damage. Notify the BBB and .... Is there a Federal Agency overseeing home appliances? There should be regulation! The conversation has begun.
Is there a Federal Agency overseeing home appliances? There should be regulation! The conversation has begun.
I think there needs to be a new IP naming scheme. Right now, managing a firewall is really difficult because all you see are numbers:
Region locations are only defined by ranges and no direct platform info. You'd have to analyse every packet for identifying info but a flood of data would overload the system. It could be formatted region string:identifier string:IP:platform class string and the regulations would cover the string identifiers like an FQDN. This allows countries to control their own IP allocation. Companies can register their company name as the identifier. When it comes to DNS, there would be a predefined range of company server addresses. When looking up twitter.com, the hardware can directly translate this to *:twitter:0.0.0.0-0.0.0.255:* so no need for a central 3rd party DNS translation (which improves privacy) because the hardware would all know where that address was.
The way it knows where these addresses are is due to the central internet authorities:
Instead of having preallocated IP numbers sent downwards through the chain, strings would be requested upwards. The central root authority only has to assign region codes and then every country has authority over their own internet space. Each country would have identifier strings and have their own authority. I would expect this authority to deal with organization strings so companies and ISPs.
In consumer equipment, the network hardware would define part of the platform string based on the regulations. This can include a device class code. A home IP might then look like:
US:AT&T:88.83.23.33:IOT
Localhost IPs would allow user defined strings on the end and they can optionally be attached to the external IP. If someone was using proxy servers, the identifier code might show up as 'server'. This allows firewalls to much more easily block incoming data quickly. If they suddenly get a whole load of traffic from IOT class devices, they just put *:*:*:IOT in the firewall and route everything through a separate filter. The regulation for the latter part could also include more specific product identifiers so that product manufacturers can be notified of a vulnerability.
In order to lookup the location of twitter.com from a computer using this scheme, the network would do what it does now. If you open a command-line and type traceroute apple.com, it shows the path that the network checks in order to reach the destination (Apple owns all the 17.x.x.x space) hopping through your own local router first to your ISP to national/international servers down to data centers down to the location. Every one of those hops checks the request to see where to go next, so it can do the exact same thing using string identifiers. International companies would register their company name with every country's central organizational authority.
A request for twitter.com would go out to some external server. This would still be a DNS server but not a central one. It can lookup organizations so by default *:twitter:0.0.0.0-0.0.0.255:*. It would find twitter to be a valid organization name and proceed through the routing to the destination. There wouldn't need to be large global routing tables:
The major routing tables (multiple routers updated from central authority) would only deal with organizations and those organizations would have to deal with routing down the IPs. If someone took out a DNS service, it wouldn't matter because routers can go directly to twitter's data center to a default IP range 0.0.0.0-0.0.0.254 and those machines can determine which servers to use. Domain names can be mapped to organizations rather than IPs and they determine what to do when someone reaches them using that domain. If you had a small company, your domain would be mapped to a domain service or your hosting provider and every router outside of the provider only has to remember where to reach the organization, not your server, that's up to the provider to figure out.
Also protocol-level packet encryption would be enabled by default and SSL would be reduced to an authority checking the encryption quality and company validity.
Also protocol-level packet encryption would be enabled by default and SSL would be reduced to an authority checking the encryption quality and company validity.
Interesting comments but mostly irrelevant. In the case of DNS flood attacks it is not resolution of IP addresses that is the issue, it is malformed packets that the server tries to parse but can't because they are bogus.The server spends all its resources trying to comply with a fake request until the cache fills up and it crashes. IP address naming schemes has nothing to do with it. Remember that 90% of current network traffic is either to or from an unnamed, un-routable. proxy IP addresses such as 10. , 172. or 192. that still need to go through a firewall. All of your speculation based on identifying strings would be a huge mess especially since everything related to IoT is going to be IPV6.
Also protocol-level packet encryption would be enabled by default and SSL would be reduced to an authority checking the encryption quality and company validity.
Interesting comments but mostly irrelevant. In the case of DNS flood attacks it is not resolution of IP addresses that is the issue, it is malformed packets that the server tries to parse but can't because they are bogus.The server spends all its resources trying to comply with a fake request until the cache fills up and it crashes. IP address naming schemes has nothing to do with it. Remember that 90% of current network traffic is either to or from an unnamed, un-routable. proxy IP addresses such as 10. , 172. or 192. that still need to go through a firewall. All of your speculation based on identifying strings would be a huge mess especially since everything related to IoT is going to be IPV6.
"In HTTP flood DDoS attack the attacker exploits seemingly-legitimate HTTP GET or POST requests to attack a web server or application. HTTP floods do not use malformed packets, spoofing or reflection techniques"
It's just a high volume of packets that causes the problem. If the network hardware that generated them was better regulated then they'd be more easily identified in the packet headers to separate legitimate traffic from malicious. Filters would be able to quickly identify region, network and device class, this scheme has to replace IPv6. The packets have to pass through other hardware but the regulations would require network hardware to maintain important information. Then firewalls at the target can filter packets very quickly, they'd use the information to filter/drop suspicious packets instead of trying to do anything with them. Things like proxy/VPN would identify as Server so would hide the source but servers can be considered suspicious traffic and malicious traffic wouldn't funnel through a proxy or it would defeat the purpose of the DDOS attack.
Something will have to be changed, these attacks are just going to get larger and more frequent the more networked devices there are. This Mirai attack was from tens of millions of devices. It could come from smartwatches, fitness trackers, smart TVs, set-top boxes, Echo-like devices, thermostats... The number of these combined will reach the billions eventually. It shouldn't just be up to the targets to do the filtering either, routers across the internet are forwarding the packets to the target repeatedly and they should be able to slow this down to make the attack ineffective.
Comments
DNS does have a lot of resiliency, which is why it's still working despite the attacks.
Region locations are only defined by ranges and no direct platform info. You'd have to analyse every packet for identifying info but a flood of data would overload the system. It could be formatted region string:identifier string:IP:platform class string and the regulations would cover the string identifiers like an FQDN. This allows countries to control their own IP allocation. Companies can register their company name as the identifier. When it comes to DNS, there would be a predefined range of company server addresses. When looking up twitter.com, the hardware can directly translate this to *:twitter:0.0.0.0-0.0.0.255:* so no need for a central 3rd party DNS translation (which improves privacy) because the hardware would all know where that address was.
The way it knows where these addresses are is due to the central internet authorities:
http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-43/121-resource.html
Instead of having preallocated IP numbers sent downwards through the chain, strings would be requested upwards. The central root authority only has to assign region codes and then every country has authority over their own internet space. Each country would have identifier strings and have their own authority. I would expect this authority to deal with organization strings so companies and ISPs.
In consumer equipment, the network hardware would define part of the platform string based on the regulations. This can include a device class code. A home IP might then look like:
US:AT&T:88.83.23.33:IOT
Localhost IPs would allow user defined strings on the end and they can optionally be attached to the external IP. If someone was using proxy servers, the identifier code might show up as 'server'. This allows firewalls to much more easily block incoming data quickly. If they suddenly get a whole load of traffic from IOT class devices, they just put *:*:*:IOT in the firewall and route everything through a separate filter. The regulation for the latter part could also include more specific product identifiers so that product manufacturers can be notified of a vulnerability.
In order to lookup the location of twitter.com from a computer using this scheme, the network would do what it does now. If you open a command-line and type traceroute apple.com, it shows the path that the network checks in order to reach the destination (Apple owns all the 17.x.x.x space) hopping through your own local router first to your ISP to national/international servers down to data centers down to the location. Every one of those hops checks the request to see where to go next, so it can do the exact same thing using string identifiers. International companies would register their company name with every country's central organizational authority.
A request for twitter.com would go out to some external server. This would still be a DNS server but not a central one. It can lookup organizations so by default *:twitter:0.0.0.0-0.0.0.255:*. It would find twitter to be a valid organization name and proceed through the routing to the destination. There wouldn't need to be large global routing tables:
https://en.wikipedia.org/wiki/Internet_backbone
http://blogs.cisco.com/sp/global-internet-routing-table-reaches-512k-milestone
The major routing tables (multiple routers updated from central authority) would only deal with organizations and those organizations would have to deal with routing down the IPs. If someone took out a DNS service, it wouldn't matter because routers can go directly to twitter's data center to a default IP range 0.0.0.0-0.0.0.254 and those machines can determine which servers to use. Domain names can be mapped to organizations rather than IPs and they determine what to do when someone reaches them using that domain. If you had a small company, your domain would be mapped to a domain service or your hosting provider and every router outside of the provider only has to remember where to reach the organization, not your server, that's up to the provider to figure out.
Also protocol-level packet encryption would be enabled by default and SSL would be reduced to an authority checking the encryption quality and company validity.
https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html
https://www.incapsula.com/ddos/ddos-attacks/
"In HTTP flood DDoS attack the attacker exploits seemingly-legitimate HTTP GET or POST requests to attack a web server or application. HTTP floods do not use malformed packets, spoofing or reflection techniques"
It's just a high volume of packets that causes the problem. If the network hardware that generated them was better regulated then they'd be more easily identified in the packet headers to separate legitimate traffic from malicious. Filters would be able to quickly identify region, network and device class, this scheme has to replace IPv6. The packets have to pass through other hardware but the regulations would require network hardware to maintain important information. Then firewalls at the target can filter packets very quickly, they'd use the information to filter/drop suspicious packets instead of trying to do anything with them. Things like proxy/VPN would identify as Server so would hide the source but servers can be considered suspicious traffic and malicious traffic wouldn't funnel through a proxy or it would defeat the purpose of the DDOS attack.
Something will have to be changed, these attacks are just going to get larger and more frequent the more networked devices there are. This Mirai attack was from tens of millions of devices. It could come from smartwatches, fitness trackers, smart TVs, set-top boxes, Echo-like devices, thermostats... The number of these combined will reach the billions eventually. It shouldn't just be up to the targets to do the filtering either, routers across the internet are forwarding the packets to the target repeatedly and they should be able to slow this down to make the attack ineffective.