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

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

D-Link enhanced its router security to a higher level of protection by incorporating both CAPTCHA and DNSSEC to guard against hacking, worms, viruses and other malicious Web attacks.

DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications that adds security to the DNS to provide assurance that the information received from a Domain Name Server is authentic. The security extensions are designed to protect the DNS from man-in-the-middle and cache poisoning attacks, which can occur when hackers corrupt DNS data stored on recursive name servers to redirect queries to malicious sites.

DNSSEC applies digital signatures to DNS data to authenticate the data’s origin and verify its integrity as it moves across the Internet and can provide users with effective verification that their applications, such as Web or email, are using the correct addresses for servers they want to reach.

CAPTCHA is a challenge-response test that ensures that a response during a user logon is not computer-generated but instead is truly entered by a human hand, by requiring a user to manually enter a small amount of text displayed in an image to help prevent automated registration and fraud.

To further consider security while future-proofing its routers, D-Link is migrating to IPv6 certification. With the growing number of Internet-capable devices on the market the pool of IPv4 address has dropped to six percent and is expected to run out sometime in 2011. While this is a major motivation for IPv6, other improvements are also realized.

The IPv6 specification now specifies certain security measures that were not defined in IPv4, such as IPSec. IPSec is a method of authenticating and encrypting data transferred between pairs of hosts. Although it was possible to implement IPSec with IPv4, it was not part of the specification. IPSec is now a requirement, not an option, in the IPv6 specification.

Source

The problem of getting EC2 images to do what you want is quite significant, mostly I find the whole thing a bit flakey and with too many moving parts.

When and what AMI to start
Once started how to do you configure it from base to functional. Especially in a way that doesn’t become a vendor lock.
How do you manage the massive sprawl of instances, inventory them and track your assets
Monitoring and general life cycle management
When and how do you shut them, and what cleanup is needed. Being billed by the hour means this has to be a consideration
These are significant problems and just a tip of the ice berg. All of the traditional aspects of infrastructure management – like Asset Management, Monitoring, Procurement – are totally useless in the face of the cloud.

A lot of work is being done in this space by tools like Pool Party, Fog, Opscode and many other players like the countless companies launching control panels, clouds overlaying other clouds and so forth. As a keen believer in Open Source many of these options are not appealing.

I want to focus on the 2nd step above here today and show how I pulled together a number of my Open Source projects to automate that. I built a generic provisioner that hopefully is expandable and usable in your own environments. The provisioner deals with all the interactions between Puppet on nodes, the Puppet Master, the Puppet CA and the administrators.

Sadly the activity in the Puppet space is a bit lacking in the area of making it really easy to get going on a cloud. There are suggestions on the level of monitoring syslog files from a cronjob and signing certificates based on that. Really. It’s a pretty sad state of affairs when that’s the state of the art.

Read More

According to a study conducted by security information and event management provider netForensics, 80% of IT managers expect network-borne threats to increase throughout 2010 and 2011, and 85% see their security environment becoming more complex. But more than half said that their organization wasn’t budgeting sufficiently, or recruiting enough new talent, to counter the added threats or complexity.

The study of about 100 IT managers also found changes in security staff size over the past year, with it increasing for 15% of responding organizations, decreasing for 24%, and remaining static for 54%. Going forward, 20% of organizations planned to hire more security personnel, 15% planned to downsize, and 51% expected to stay the same.

remaining static or decreasing, and budgets not being allocated to put security processes in place, organizations are going to face greater challenges than ever to their security posture.”
The also study found that just over half of respondents stated that their organization was more secure today, versus 12 months ago. Yet 65% don’t think their organization has “complete visibility” into its security posture at any given time.

Based on the survey results, “security professionals are being asked to do more with less, while at the same time, the organization is being put at a higher risk,” said Tracy Hulver, executive VP of products and marketing at netForensics, in a statement.

Her recommendation is that organizations should look at using tools and technologies that can scale up their response, without adding staff or budget. Examples of such tools include “outsourcing to cloud security, deploying technologies that maximize existing security infrastructure without having to invest in new, big-budget items, [and] acquiring technology via SaaS pricing models.”

Interestingly, even with the majority of organizations seeing increasing numbers of threats, but little or no increase in their security budget, 70% of respondents said they wouldn’t outsource their organization’s security. Then again, such a move might risk making respondents redundant.

Source

The federal agency in charge of securing the government’s computer systems is unable to monitor the networks or analyze threats in real time, and it lacks the authority and staff it needs to do its job, according to an internal report.

The U.S. Computer Emergency Readiness Team must share information about threats and trends more quickly and in greater detail with other federal departments so they can better protect themselves, the audit said.

Issued Wednesday by the Homeland Security Department’s inspector general, the report lays out criticism that long has been aired by U.S. officials and outside experts who say the government’s computer systems are vulnerable to attacks, are persistently probed, and lack the needed management and security standards.

And it highlights many of the problems Congress is trying to address in a number of bills aimed at creating a more effective government structure to improve and enforce security standards.

Cyber security has become a top priority for the government, bolstered by President Barack Obama’s declaration last year that it is “one of the most serious economic and national security challenges we face.” Officials say U.S. networks are scanned and probed millions of times a day, and in some cases breached by hackers, cyber criminals and other nations.

The 35-page report said the Computer Emergency Readiness Team, which is a part of DHS, has made progress helping federal agencies protect against computer-based threats, including the creation of a cyber center. But it said the team does not have the enforcement authority it needs to get other federal agencies to take the steps required to secure their systems.

In a detailed response to the report, DHS Undersecretary Rand Beers noted that the inspector general did not make a recommendation on how the agency could gain more enforcement authority. But he said the agency agrees that giving DHS more formal authority would be helpful.

Members of Congress currently are tussling over legislation that would give Homeland Security greater power to draft and enforce standards, and require federal agencies to more quickly address gaps in their computer systems. Other lawmakers say that authority should reside in the White House and with the National Institute of Standards and Technology.

Sen. Susan Collins, R-Maine, who along with Sen. Joe Lieberman, I-Conn., has legislation to increase the DHS’ power, said the agency needs “precise authorities with real teeth.” That effort got a boost Wednesday as key House members said they would introduce a similar bill.

The report also said the Computer Emergency Readiness Team has been plagued with staff shortages and leadership turnover, hindering its ability to retain qualified staff. And due to the security clearance process, it can take nine months to 12 months for a new hire to begin work.

DHS is in the middle of a major boost in staffing. In early 2009, the readiness team had 16 employees, but the number jumped to 31 by October, and is now at 55, with another 25 workers in the hiring process.

The report notes that officials from other federal agencies have complained that the readiness team doesn’t quickly share data on cyber threats or incidents. DHS officials responded that much of the data is from intelligence agencies and is classified at various levels, making it difficult to coordinate and share.

Source

The few blocks of Internet addresses yet to be allocated under the old IPv4 protocol seem to be home to some “hotspots” of unwanted traffic that anyone who gets the addresses would have to pay for, a researcher said at the North American Network Operators Group conference on Monday.

No one can set up a web server on an IP (Internet Protocol) address that hasn’t been allocated, but anyone can write code that points to the unused addresses. The unexpected activity found in these “dark spaces” may come from a variety of sources, including both Internet-borne attacks and benign code for testing an application or PC. Though the traffic doesn’t represent a security threat itself, an enterprise that acquired the affected addresses from an Internet service provider (ISP) typically would have to pay for the transmission of the irrelevant packets, said Manish Karir, a researcher at Merit Network. Merit is an educational network operator and Internet research center in Michigan.

IPv4 only allows for about 4.3 billion addresses, and that supply is expected to run out within the next two years. If some of those remaining addresses are polluted with unwanted traffic, that could make the problem even more urgent for enterprises that want new, usable IPv4 addresses.

IP addresses are allocated by regional Internet administrators, usually to ISPs, which then assign smaller blocks of them to their enterprise customers. Only a small number of blocks of IPv4 addresses are still waiting to be handed out. Karir and a group of other researchers tried to find out whether the addresses at the bottom of the virtual barrel are as good as those that have already been handed out.

“There’s growing concern that these blocks are less desirable,” Karir said. The concern is over types of traffic that have been blocked or moved from already-allocated blocks to ones that so far haven’t been assigned.

Karir’s team joined with APNIC, the Internet registry for the Asia-Pacific region, to test one new block, called 1.0.0.0/8, because it was known to have been used in examples and test cases over the years. Capturing packets over a period of about 10 days, they found a large amount of traffic.

In the entire 1.0.0.0/8 block, there was an average of 170M bps (bits per second) of sustained traffic, at an average of 150 packets per second, Karir said.

Some of the traffic occurred in a subnet called 1.1.1.0, which is commonly used to test computer and router configurations. But the researchers were puzzled by a very large amount of traffic in another subnet, which made up nearly 35 percent of all the traffic in the entire address block. So they used the Wireshark protocol analyzer to reconstruct it. The traffic consisted of fast busy signals and audio messages advising callers they had the wrong phone number. “If you’d like to make a call, please check the number and try again,” said one of the messages, which Karir played for the NANOG audience.

The researchers believe these signals were a side effect of problems with SIP (Session Initiation Protocol), a commonly used technology for voice over IP and other types of packet-based communication. The signals could have appeared in the dark space because of misconfigured SIP servers or because of “SIP invite” attacks, in which a system is flooded with malformed invitations to join a SIP session, Karir said. Because of a “hard-coded default,” the busy signals are configured to come to that particular subnet, he said.

Another source of packets to the address block, more than 17 percent of the total, was misdirected DNS (Domain Name System) queries embedded in Web pages that users clicked on.

Given the findings, APNIC decided to block the worst hotspot subnets within the 1.0.0.0/8 block. Cutting off the 10 worst hotspots significantly reduced the unwanted traffic, Karir said.

However, the researchers found evidence of similar types of pollution in several other unallocated address blocks, and it’s hard to predict where such traffic will turn up, he said.

“Each dark space is different … because hotspots exist in strange and unusual places,” Karir said.

He advised network administrators who are given polluted blocks to talk to the ISP about exchanging them. But this may become harder to do as the number of unused IPv4 addresses dwindles, he warned. There are only 16 remaining blocks of about 16.7 million addresses each, down from 22 such blocks just three months ago, Karir said.

Source

SonicWall directors have accepted a US$717 million offer to sell the company to a group headed by Thoma Bravo, a private equity investment firm, with the aim of growing the company faster and developing products quicker than it could as a listed company.

The security appliance company is profitable and growing — its earnings last quarter were 17% higher than for the same quarter last year — but with the security appliances industry consolidating, it needs to grow faster, says Patrick Sweeney, vice president of product management for SonicWall. The company has $200 million in cash as well, he says.

If approved by shareholders, the deal will enable faster development of the company’s next big product push, called Super Massive, a jump to 10Gbit/s speeds for its unified threat management hardware with all the security features turned on, he says. “It’s important for us to grow as fast or faster than the market,” he says. “This will allow us to build a larger company a lot faster.”

Size is important because the industry is consolidating, he says, pointing to HP’s purchase of 3Com and its security devices division Tipping Point, making smaller companies more vulnerable.

As a listed company, SonicWall’s goals were constrained to ever increasing 90-day demands between fiscal reporting quarters, which limits longer term investments that can alter a company’s strategic course, he says.

SonicWall, which makes unified threat management, firewall, VPN and backup appliances as well as endpoint security, email security and antispam software, says the deal will buy out current shareholders for $11.50 per share in cash, which is 63 percent more than the stock is going for publicly. Stockholders still have to approve the deal, and that is expected by early in the fourth quarter of this year.

Source

We continue to enhance Amazon CloudFront at a rapid pace. Here’s the latest and greatest:

We’ve added a new edge location in New York City. This location will provide even better performance to users requesting your content from New York and the northeastern United States.

We’ve reduced pricing for CloudFront HTTP requests by 25%. The prices now start at $0.0075 per 10,000 requests.

You can now deliver content over an HTTPS connection by replacing the “http:” with “https:” in the links to your CloudFront content.

You can configure any of your CloudFront distributions so that the content must be accessed by an HTTPS connection.

The first three items should be pretty much self-explanatory, so let’s take a look at the fourth…

You can now configure an Amazon CloudFront distribution such that access to the Amazon S3 objects represented by the distribution is limited to HTTPS connections. You can do this to protect your content as it travels from a CloudFront edge location to your client application, or to avoid the dreaded “mixed content” warning issued by many web browsers.

To configure your distribution in this matter you simply set the distribution’s RequiredProtocols attribute to the value “https”. If you do not set this attribute, the contents of the distribution will be accessible via both HTTP and HTTPS. You cannot currently make HTTPS requests via a CNAME.

The following third-party applications provide simple tools to set up your distributions for HTTPS access:

CloudBuddy Personal
CloudBerry S3 Explorer
Bucket Explorer
These third-party tools are provided by companies unaffiliated with AWS.

– Jeff;

Source

A brace of data center products introduced by Juniper Networks this week promises to eliminate an entire layer of switching from customer networks while delivering lower latency and higher performance as well as smaller footprints and lower power consumption.

Much of the trick to the new “3-2-1″ network architecture involves the application of Juniper’s Virtual Chassis fabric technology to the access layer, thereby eliminating the need for aggregation. The firm claims the process can reduce by 99%, the number of switch interactions compared to legacy three layer networks.

Juniper said the new products enable legacy data center networks to be reduced almost immediately from three to two layers and to a single layer in the future. There’s more to the flood of new Jupiter software, services, systems and partnerships unveiled this week: ten new Gigabit Ethernet switches yielding up to five times lower latency are promised, too. Taken together capital expenditures of data center networking can be cut by 35%, the company said.

“Legacy data center networks are inherently complex, and they often force an unacceptable trade-off between user experience and economies,” said Jupiter’s David Yen in a statement. “Our breakthrough 3-2-1 architecture lays out a clear path to help customers flatten the network and eliminate layers of cost and complexity while simultaneously improving application and business performance.” Yen is executive vice president and general manager of Juniper’s Fabric and Switching Technologies Business Group.

The announcement hardens the battle lines between its data center approach and Cisco’s with IBM and Dell also lining up with Juniper.

Data center improvements have been rapidly accelerating with the pell-mell rush toward cloud computing and as old alliances are being dropped in favor of new partnerships. For instance, Juniper noted that IBM will ship Juniper’s SRX Series Services Gateways and that IBM will also provide Jupiter expertise and support with one call.

“The traditional approach of more boxes and more layers benefits legacy vendors, while burdening the customer with cost and complexity,” said Juniper CEO Kevin Johnson. “Our approach is different , and it’s fueled by a combination of Juniper and partner innovation at the systems, software and services levels – all designed to help IT eliminate those layers of cost and complexity while also enhancing applications and business performance.”

Source