uncompiled.com

One core tenet of demilitarized zone (DMZ) design is to segregate network devices, systems, services and applications based on risk. Because of this, it’s crucial to carefully plan and design a DMZ because it may not be easy to fix major flaws in the DMZ’s design once it’s live. Here, Knowledge Center contributor Michael Hamelin explains how to design a secure DMZ for your enterprise.

We have come a long way when it comes to DMZs (demilitarized zones). It’s no longer a question of if your organization needs a DMZ, but rather, it’s now a question of how you should design one.

In computer security, a DMZ is a physical or logical subnetwork that contains and exposes an organization’s external services to a larger, untrusted network—usually the Internet. The original DMZ designs included a simple network separated from the internal network, where everything that needed access to the Internet was placed.

Today, there are as many DMZ designs as there are vehicles on the road. You have industrial trucks designed to simply transport goods as cheaply as possible. You have economy cars designed to save money. And you have exquisite Italian sports cars that are sure to make your friends jealous (and fast enough that you always arrive with plenty of extra time for a nice cup of espresso). DMZ designs are a lot like cars: there are many varieties which go by a lot of different names but they all serve the same purpose.

There are hundreds of names that we use for networks today but, essentially, there are internal networks, external networks and DMZs. They may be called partner nets, vendor zones, internal DMZs or security zones. But the reality is that they are all DMZs with a mix of ownership devices, connectivity and risk levels.

Goals of DMZ design

If you ask ten network architects about how to design a DMZ, they’ll come back with ten different answers. While variety is the spice of life, as an industry we should have some generally accepted practices of DMZ design.

One of the core tenets of DMZ design is to segregate devices, systems, services and applications based on risk. The goal is to isolate risk, so if something goes bad and the Web server is hacked, it is essential to know what other devices the hacker would have easy access to. Beyond segregation by risk, four other common design approaches are separation by operating system, data classification schemes, trust levels or business unit.

If you look at recent audit and compliance requirements, you’ll see that they include a growing number of specific technical design requirements. In some of the new requirements, we find the mandate to keep the Web and application tier separated from databases—a very good idea. We also see the move back to single purpose servers; for example, your Web server cannot also be your DNS server.

Four levels of DMZ design

Let’s break DMZ design into four levels, with Level 1 being the simplest design and subsequent levels providing more segmented security.

When we want to build a basic DMZ, we start with a single segment of the firewall. Let’s call this Level 1 in our DMZ design book. This design is fine if you have a few servers that need Internet access. But if you do any e-commerce transactions, you have already outgrown this design.

Many people make the mistake of keeping this design, placing the Web and application servers in the DMZ and the databases on the internal network. This is no longer acceptable. As database attacks become more targeted, the risk of having the database on the internal network requires a more sophisticated design.

Level 2 DMZ designs

A Level 2 DMZ would consist of multiple DMZ networks off of the firewall. This design is a substantial improvement over a Level 1 design. It allows traffic rules to be written between each DMZ for control and segregation. A good start is having separate DMZs for Web and application servers, databases, authentication services, VPNs, partner connections, e-mail and mobile services. This is very feasible today; most firewalls can easily handle tens of interfaces and multiple VLANs on each interface.

Level 3 DMZ designs

One problem often seen in Level 2 DMZ designs is that overly permissive firewall rules can lead to devices getting Internet access that should never have it. One way to rectify that is to use two firewalls. This design, which we’ll call Level 3, is built with an external firewall and an internal firewall. The DMZ is placed between the firewalls based on access restrictions. Inbound Internet access is allowed into the external DMZ via the external firewall—never directly routed to devices placed in the internal DMZ on the internal firewall. The internal network can talk to the internal DMZ but not the external DMZ.

This Level 3 DMZ design effectively separates Internet-connected devices and the services they require using just two firewalls with their own policies. Most security teams quickly understand the rule base design between externally accessible and internally accessible DMZs. The temptation is to create rules allowing inbound access from the DMZs to the internal network. This should never be allowed. All the services that are needed should be moved into DMZs so that internal networks are never exposed.

This restriction is often violated. A lack of coordination or communication between IT groups, the rush to deploy new applications, network complexity and other factors result in organizations building critical services on their internal networks.

Level 4 DMZ designs

Level 4 DMZ designs are where things start getting more complicated. A Level 4 scenario would most likely include deploying multiple firewall pairs in parallel along your border rail, and spreading your DMZs out among them, segregated by your choice of metrics. Most people choose to separate the firewalls into business or functional groups, while others like to separate them by trust levels.

Best practices dictate building separate firewall stacks based on Service Level Agreements (SLAs) and data classification. This creates a situation where there is an entirely separate firewall stack for PCI, separate firewalls for user services (such as Web browsing, FTP, e-mail, patching, etc.) and separate firewall stacks for business services. Consider business services placed in DMZs by SLA: 90 percent, 98 percent and 99.9 percent make for three good goals. Designing DMZs by SLA can streamline DMZ management and reduce business disruptions.

Conclusion

In closing, it’s imperative to place as much rigor as possible into the planning and design process. Assume that once the DMZ is live, it may not be so easy to fix major flaws in the design. Internal due diligence can be used as a way to establish strong lines of communication with other stakeholders—whether they are other IT folks, business owners, partners or managers. It can raise your profile within your company as a thoughtful risk manager and strategic thinker. And, perhaps most important, it will invite feedback outside your frame of reference. If one conversation with one person has a significant impact on DMZ design, wouldn’t you want to have that conversation before you design it?

Source

Trend Micro is blazing a new trail with a service called SecureCloud intended to give enterprises a way to encrypt data in cloud-computing environments.

SecureCloud allows you to maintain control over the encryption key used to secure data stored in the Amazon EC2, Eucalyptus or VMware vCloud cloud infrastructures. Other cloud-computing variants could be added in the future.

“IT operations may be firing up [a remote virtual machine] image but we have security validating the integrity, and it’s encrypted until it hits the cloud, and it’s encrypting data at rest,” according to Todd Thiemann, senior director of data center security and marketing at Trend Micro.

He notes that SecureCloud allows the IT department using either public or private cloud-computing services to answer the basic questions, “Is this image OK? And is it mine?”

Now in beta with general availability expected by year end, SecureCloud is provided through a Web site portal and makes use of policy-based encryption to allow access to a virtual-machine image as well as storing related activity logs.

In addition to offering the security service, Trend Micro is looking at making comparable software available to companies for on-premises use.

In a separate announcement, Trend Micro also unveiled an antimalware protection module for its VMware server security software, Deep Security 7.5. It includes integrity monitoring, log inspection and stateful firewall capabilities, and leverages the most recent VMware vShield Endpoint APIs. Trend Micro Deep Security 7.5 is expected to ship in October.

Source

For 12% of CIOs, hearing complaints from employees over IT security measures — specifically, limits on their access to certain types of websites or networks while using the office network — is a common occurrence. Meanwhile, 29% of CIOs say such gripes are at least “somewhat common.”

The numbers come from a survey of more than CIOs, selected randomly from companies in the United States with 100 or more employees, conducted by staffing firm Robert Half Technology.

“There will always be employees who feel IT security policies are too restrictive,” said John Reed, executive director of Robert Half Technology, in a statement. “But in most situations, robust information security measures are necessary to protect sensitive data and an organization’s network integrity from increasingly sophisticated threats.”

On the other hand, said Reed, if too many people are complaining, then maybe it’s time to reevaluate whether an organization’s security policies have come down on the wrong side of the security-versus-productivity equation.

Rather than worrying whether their security policies are too restrictive, however, many organizations have a more fundamental problem: they lack any security policies, or else mechanisms for automatically enforcing those policies.

The result in either case is the same: employees often take their chances, ignoring any rules that they think are slowing them down, such as social networking restrictions or file transfer rules. According to numerous studies, when it comes to flouting security policies, IT personnel can be amongst the worst offenders.

But if corporate security or web access rules are cramping your style and making it harder to do your job, Reed recommends speaking up. “Some policies may simply be outdated and no longer make sense,” he said. “Asking someone in your organization’s IT department why access is restricted is often one of the quickest ways to resolve an issue.”

If policies aren’t judged to be outdated, he suggests talking up the business reasons for why they should change. “If employees can’t access a client’s website or a professional networking site that can generate business, it will probably be an easy case to make,” he said.

Source

There’s a tremendous buzz today about cloud computing, but before outsourcing your critical business systems to the cloud let’s review some security concerns.

The most critical business applications deal with corporate HR, finance, credit card, and other sensitive data. If any of this information is compromised lawsuits may ensue and your corporate brand is tarnished. This is a nightmare that could lead to customers avoiding purchasing your products or services. How can cloud computing effectively protect sensitive data?

There are three areas that need to be addressed to effectively push your applications into the cloud:

Let’s start with defense in depth.

First, put sensitive data in a second tier of firewall segments behind the main corporate firewalls. This second-tier firewall and corresponding network shields sensitive applications and their data from being easily accessed if the Web-facing firewalls are breached. For example, let’s look at grocery stores. It would be wise to deploy at least four firewall/network segments: one for HR data, one for financial data, one for credit card PCI (Payment Card Industry) data, and one for services that the other segments share. The segment containing services that are shared could contain common support services such as network and systems management, encryption and PKI functions, access control services, and security event management functions.

Another architectural implementation that protects corporations from internal data theft is the creation of a Tunneling Access Protocol. The Tunnel Access Protocol is an access control function that forces all administrators to log information before they perform administration on segment systems. Hence, all administrative access is tracked, discouraging internal theft of information

The second area that needs addressing is the analysis needed to determine successful migration of the application to behind the cloud’s second-tier firewalls. I recommend starting with the application design document first. It gives you a big-picture understanding of which business need the application performs, what middleware is used, what databases are used, and what protocols it uses. It also often contains the logical architecture.

It is important to focus on all the systems the application interacts with. Your security team will have a variety of information collected about the application: what data is sensitive, how and what tools are used to encrypt the data, and penetration testing results if it is a Web-facing application. Also, I recommend creating a protocol diagram showing all servers and their IP addresses, the protocols being used, and the protocol (TCP or UDP) ports being used. This network view specifically shows which servers need to talk to each other and what protocols (ports) they will use to do it. It is not necessary to include switches, routers and other network infrastructure components because the protocols/ports just ride over them. If the protocol diagram is thorough, it should be a simple step to create the firewall rules. Firewall rules are made up of source and destination IP (Internet Protocol) addresses, protocol used, and ports that ride on top of those protocols.

Lastly, I recommend a thorough collection of system and application metadata. The need to port your application well requires this work. Plus, if you have a disaster, business interruption or want to pull your application from the cloud — you need this data. System information exists per firewall/network segment. All applications share the same system data such as the same firewall, routers, switches, encryption algorithm (if used for all applications in a segment), and storage subsystem. System metadata includes vendor, model, software release and version, and other system-wide configuration data. Application data is similar but it addresses load balancers, encryption method, middleware, database, server hardware and operating system, and services, protocols, and ports that ride on top of those systems. Application metadata includes vendor, model, software release and version, and other application configuration data.

The next debate is where this metadata should be contained. I recommend containing this information in a hierarchy in a LDAP repository. I would create two tiers in the directory: one called Segment System for each of the four segments in the example above, and lastly one called Application for all applications within a given segment. This ordering enables a systematic collection of all metadata so that sensitive cloud applications can quickly be deployed. And, most importantly, it enables a quick deployment of the application and/or segment into a cloud.

In summary, migrating critical cloud applications involves putting data behind a second tier of firewalls. Common services exist in one of the segments that can be shared by all segmented applications. Applications should be in separate segments based upon the type of data that is being protected such as credit card data, finance data and HR data, and services that are shared. A variety of documentation should be created and/or reviewed to make sure that the porting of applications behind the second-tier ‘deep theater’ defense firewalls goes well. This collected metadata is from a hierarchy of two layers: common system per segment and different applications within each segment. I recommend the metadata be saved in a directory where it can be easily retrieved.

Source

Eucalyptus Systems, supplier of Amazon EC2-compatible software for building the private cloud, has brought out version 2.0 of its Eucalyptus open source system.

The Santa Barbara, Calif., company was founded to support the output of the Eucalyptus open source project, founded at the University of California at Santa Barbara’s computer science department. Prof. Rich Wolski and associates produced interfaces compatible with Amazon Web Services’ EC2 APIs and packaged them together as a way to start building out an enterprise cloud.

Eucalyptus 2.0 is the second major release of the open source code. In it, “we have improved scalability all over the product,” said Marten Mickos, CEO, in an interview. The firm provides technical support for Eucalyptus open source code. The open source version is not to be confused with the Eucalyptus commercial Enterprise edition, also labeled 2.0, although based on a pre-2.0 version of the open source code.

The Eucalyptus open source code is issued under the GPL, contains features and functions ahead of the Enterprise edition, and can be freely downloaded. The firm is seeing 12,000 downloads in peak months and Eucalyptus is included in Canonical’s Ubuntu Linux distribution, he said.

Eucalyptus scales across a larger server cluster more easily because the 2.0 version “has been clearer about the segregation of tasks. We no longer locate the cluster controller and the node controller on the same node,” where they sometimes ended up in contention over resources, Mickos noted. The former CEO of MySQL, now part of Oracle, joined Eucalyptus Systems in March.

Version 2.0 supports iSCSI disks as elastic block store volumes and allows the cloud builder to place an iSCSI storage controller on any server in a cluster, including outside the cloud domain of the cluster, if he chooses, Mickos said.

Version 2.0 also supports the open source virtio, an API for virtualizing I/O that is used by the open source KVM hypervisor. KVM is included in distributions of Red Hat Enterprise Linux and Novell’s SUSE Linux Enterprise System. Virtio uses a common set of I/O virtualization drivers that are both efficient and potentially adaptable for use by other hypervisor suppliers, Mickos said. Virtual I/O consists of a virtual machine sending both its communications traffic and storage traffic through the hypervisor to a virtual device, rather than through a server’s network interface card or host bus adapter. From the virtual device, it can be moved off the virtualized server into the network fabric and handled more efficiently there.

Eucalyptus 2.0 also supports retrieval of specific versions of objects stored in Walrus, the Eucalyptus storage system that is compatible with Amazon’s S3 storage service. Users may perform version control on objects as they are stored in Walrus and retrieve a specific version, as needed.

Eucalyptus to some extent now mimics the slogan of the OpenStack project, started recently by Rackspace, which claims it’s building governance software for a million-node cloud, a prospect that even the largest service providers have yet to attain.

“Sure Eucalyptus can support a million-node cloud, but the more important question is how large an application can you run on your cloud” and how effectively can you manage it there with your cloud software. Eucalyptus is concentrating on effective management for private clouds, not massive public infrastructure providers, Mickos said.

Source

In our continuing series of groundbreaking tests of cloud computing services, we take a look at what enterprises can expect if they decide to entrust data to a cloud storage provider.

We found that cloud storage lives up to its advance billing in two key areas: cloud storage can be fast and the pay-as-you-go model can be a real cost saver. We also found that security could be an issue for enterprise shops, and the formulas for trying to predict overall costs can be complex.

The services that we tested were Amazon S3, Rackspace’s CloudFiles, Egnyte’s On Demand File Server, Nasuni Cloud Storage, and Nirvanix’s Storage Delivery Network.

Amazon, Rackspace and Nirvanix represent the containerized/object-oriented model. Egnyte embodies the file/folder metaphor, while Nasuni offers a different twist – it’s a front-end that simplifies cloud storage for enterprise customers and connects to other cloud storage vendors on the back end.

To test cloud-based storage, we accessed the cloud vendor’s site through their supplied APIs, where applicable. We moved data either from virtual machines in our cabinet at n|Frame in Indianapolis at 100Mbps, or from our lab connected via standard Comcast broadband.

We pounded each site with a variety of file sizes ranging from 500KB to 1GB. We also tested in two periods, daytime and nighttime, to see if Internet congestion played a role in cloud storage performance.

Overall, performance was strong, although it was also somewhat random and unpredictable. Generally speaking we did get faster uploads and downloads at night, when Internet congestion is lower. And we found that download speeds were considerably slower than upload speeds for all the vendors tested.

Rackspace delivered the best overall performance, with an average speed 2.57Mbps for uploads and roughly 650Kbps for downloads. But all of the vendors delivered impressive performance.

Nirvanix delivered an average upload speed of 1.3Mbps and Egnyte topped 1Mbps. Amazon had the lowest average upload speed at 835Kbps, but also the highest download speed at 773Kbps, giving it the best balance between upload and download speeds.

Security concerns
Those desiring comfortable high security may be disappointed. While all of the vendors we tested provided link encryption, data encryption was glossed over by the container providers. We wanted to see port scrambling, and IP address access control lists, but these were missing across the board. Admittance control would, for some thinkers, break the cloud model by creating an extranet relationship between a subscriber and the cloud storage area, but we’d feel happier if there were greater admittance control by IP address. At press time, Amazon announced such IP address admittance control, along with HTTP_Referrer control (URL-based admittance), but we were unable to examine it at deadline.

Source

The Web threat landscape is becoming increasingly dynamic and opportunistic as hackers continue to adapt to new online functionality and trends, according to a report on online security from Zscaler, a security firm that specializes in cloud computing.

“While the goals have not changed, the techniques continue to evolve,” wrote Michael Sutton, the company’s vice president of security research, in the “State of the Web” report for the second quarter of 2010. “The attacks that we’re seeing are increasingly dynamic in nature, continually shifting locations and swapping out payloads to avoid detection.”

Attackers are using social networking functionality, exploiting current events and using techniques such as fast flux to quickly change the Domain Name System resolution for IP addresses, a tactic that allows them to evade blacklists that block malicious sites. The trends are not new, but they illustrate the continued threat posed by increasingly professional criminals with access to a growing kit of malicious tools available in the underground market.

“Attackers are quickly moving content to different locations in order to ensure that enterprises cannot simply protect themselves by blocking a specific range of IP addresses,” the report concludes. “It is clear that security vendors must be able to quickly adapt and inspect Web-based content on-the-fly in order to identify and secure against emerging threats in this continually evolving environment.”

Legal inroads are being made against organized online crime. The Secret Service announced last week that Vladislav Anatolieviech Horohorin, known online as BadB, had been arrested by French authorities on U.S. federal indictments for access-device fraud, aggravated identity theft, and aiding and abetting. According to Secret Service officials, Horohorin was one of the founders of CarderPlanet, which the agency called “one of the most sophisticated organizations of online financial criminals in the world.” The site allegedly is operated by cyber criminal organizations to traffic counterfeit credit cards and false ID information and documents. The site provides a forum for purchasing stolen data and credentials as well as attack tools.

But criminals are resilient and continue to take advantage of current events, such as the recent World Cup tournament and Apple’s release of the iPad, and of new functionality, such as Facebook’s “Like” button. Zscaler described Likejacking schemes in which invisible buttons use clicks anywhere on a Web page to drive advertising by raising its Facebook profile.

The increasingly popular Twitter is also a rich target for phishing attacks as malicious third parties solicit Twitter account information with offers to increase the number of the account’s followers.

In addition, criminals are using search engine optimization techniques to drive malicious Web sites to the top of search results on major search engines, including Google, Bing and Yahoo, Zscaler found.

The United States remains by far the top country for malicious IP addresses identified by Zscaler in the second quarter, despite dropping from 62 percent of malicious addresses in April to 48 percent in June. All the other leaders are in the single digits. China and Germany were tied for second place with 7.11 percent each.

However, those figures likely say more about the number of computers and the rate of Internet use in a country than about where attacks originated.

Source

Understanding what the IEEE 802.1x standard is and why you should care means understanding three separate concepts: PPP, EAP and 802.1x itself.

Most people are familiar with PPP – Point-to-Point Protocol. PPP is most commonly used for dial-up Internet access. PPP is also used by some ISPs for DSL and cable modem authentication, in the form of PPP over Ethernet. PPP is part of Layer 2 Tunneling Protocol, a core part of Microsoft’s secure remote access solution for Windows 2000 and beyond.

PPP evolved beyond its original use as a dial-up access method and iis now used all over the Internet. One piece of PPP defines an authentication mechanism. With dial-up Internet access, that’s the username and password you’re used to using. PPP authentication is used to identify the user at the other end of the PPP line before giving them access.

Most enterprises want to do more for security than simply employing usernames and passwords for access, so a new authentication protocol, called the Extensible Authentication Protocol (EAP), was designed. EAP sits inside of PPP’s authentication protocol and provides a generalized framework for several different authentication methods. EAP is supposed to head off proprietary authentication systems and let everything from passwords to challenge-response tokens and public-key infrastructure certificates all work smoothly.

With a standardized EAP, interoperability and compatibility of authentication methods becomes simpler. For example, when you dial a remote-access server and use EAP as part of your PPP connection, the RAS doesn’t need to know any of the details about your authentication system. Only you and the authentication server have to be coordinated. By supporting EAP authentication a RAS server gets out of the business of acting as middle man, and just packages and repackages EAP packets to hand off to a RADIUS server that will do the actual authentication.

This brings us to the IEEE 802.1x standard, which is simply a standard for passing EAP over a wired or wireless LAN. With 802.1x, you package EAP messages in Ethernet frames and don’t use PPP. It’s authentication and nothing more. That’s desirable in situations in which the rest of PPP isn’t needed, where you’re using protocols other than TCP/IP, or where the overhead and complexity of using PPP is undesirable.

802.1x uses three terms that you need to know. The user or client that wants to be authenticated is called a supplicant. The actual server doing the authentication, typically a RADIUS server, is called the authentication server. And the device in between, such as a wireless access point, is called the authenticator. One of the key points of 802.1x is that the authenticator can be simple and dumb – all of the brains have to be in the supplicant and the authentication server. This makes 802.1x ideal for wireless access points, which are typically small and have little memory and processing power.

The protocol in 802.1x is called EAP encapsulation over LANs (EAPOL). It is currently defined for Ethernet-like LANs including 802.11 wireless, as well as token ring LANs such as FDDI. EAPOL is not particularly sophisticated. There are a number of modes of operation, but the most common case would look something like this:

The authenticator sends an “EAP-Request/Identity” packet to the supplicant as soon as it detects that the link is active (e.g., the supplicant system has associated with the access point).

Source

Federal agencies are making some progress on developing and executing strategies for building a stronger cybersecurity workforce, but much remains to be done, government officials and industry representatives said at a conference this week.

Coordinated efforts to spark improvements in the federal cybersecurity workforce, formerly part of the Comprehensive National Cybersecurity Initiative (CNCI), have been folded into a larger effort, the National Initiative for Cybersecurity Education (NICE), a broader national agenda, announced in April, which includes K-12 education and awareness campaigns as well as federal workforce efforts.

“We want to become a resource to not only get the federal government up to the best level it can be, but to be a leader for the rest of the country,” NIST’s NICE program lead, Dr. Ernest McDuffie, said in an interview.

In terms of government, NICE includes two tracks of work focused explicitly on improving the federal cybersecurity workforce — one on workforce structure, and the other on training and professional development. Some of the work under these buckets had already begun when NICE began, but it’s beginning to accelerate.

For example, the Office of Personnel Management embarked on a path to sharpen and redefine cybersecurity job policies last November, and that effort is picking up steam. Earlier this year, working groups began re-defining competency models — key roles and responsibilities — for cybersecurity pros in government. Soon, OPM will survey agencies to get feedback on draft competency models, and plans to release the final competency models in December.

However, the competency models are only the first step. OPM and auditors have long found cybersecurity pros working in a number of federal job series — groups of formally defined jobs — and there’s still some consideration of whether the cybersecurity workforce needs its own series to help better define what cybersecurity pros do. OPM is also considering whether hiring authorities and practices need to change, Maureen Higgins, OPM’s assistant director for agency support and technology assistance, said in an interview.

Work on workforce structure seems to be moving along, but training and professional development suffer from numerous challenges, such as a muddle of certifications, required skills and training that can sometimes make it difficult for hiring managers to determine who’s qualified or just what additional training their employees need.

Some things under consideration in terms of workforce development include the use of a practical, hands-on exam to determine qualifications. “There’s some divisiveness here, so we’re trying to get to what makes sense here,” John Mills, special assistant to the CNCI from the office of the assistant secretary of defense for networks and information integration, said in a presentation.

Source

Dear Amazon EC2 customer,

We are pleased to announce that as part of our ongoing expansion, we have added a new public IP range. The current Amazon EC2 public address ranges are:

US East (Northern Virginia):

216.182.224.0/20 (216.182.224.0 – 216.182.239.255)
72.44.32.0/19 (72.44.32.0 – 72.44.63.255)
67.202.0.0/18 (67.202.0.0 – 67.202.63.255)
75.101.128.0/17 (75.101.128.0 – 75.101.255.255)
174.129.0.0/16 (174.129.0.0 – 174.129.255.255)
204.236.192.0/18 (204.236.192.0 – 204.236.255.255)
184.73.0.0/16 (184.73.0.0 – 184.73.255.255)
184.72.128.0/17 (184.72.128.0 – 184.72.255.255)

US West (Northern California):

204.236.128.0/18 (216.236.128.0 – 216.236.191.255)
184.72.0.0/18 (184.72.0.0 – 184.72.63.255)

EU (Ireland):

79.125.0.0/17 (79.125.0.0 – 79.125.127.255)
46.51.128.0/18 (46.51.128.0 – 46.51.191.255) [NEW]

Asia Pacific (Singapore)

175.41.128.0/18 (175.41.128.0 – 175.41.191.255)

Sincerely,

The Amazon EC2 Team

Source