The Security Skeptic

Participate in any mailing list about firewalls and you will routinely find someone who'll post a query, "Are firewalls obsolete?" A recent post asked the question with a somewhat contemporary twist: Are firewalls obsolete in a world involving enterprise Webservice SOA?

This and all firewall obsolescence questions invariably call attention to the elephant in the conference room no one cares to talk about.

Firewalls are middleboxes (RFC 3234 classifies all sorts of firewalls as middleboxes and RFCs, even Informational, are more reliable sources than Wikipedia, right? ). Firewalls are one element in a line of defense. From an attacker's viewpoint, firewalls represent one line of defense that must be breached (for some set of attacks). Today, even the stone stupid attackers burn very few brain and CPU cycles attempting to breach IP firewalls. It is much easier to go after web services and web application code that is written by folks with little security clue, who use grossly generous language constructs, and compound the crime by ignoring the precious few OS and web server access control mechanisms they could employ if they'd taken a minute to read the man pages. (Two of my favorite quotes regarding web application development and secure coding come from Paul Melson's, who claims web services are an "epic fail from the beginning" and Marcus Ranum, who calls them "bad ideas happening fast".)

Each time a question of this kind is raised, it provides yet another opportunity to illustrate to even the most obdurate network designers that "the perimeter will save us" is a security principle that was long ago overtaken by events. This is a good thing: and after only two decades, we are actually turning our attention to considering remedies closer to communications endpoints.

The problem we still face is one of addiction. The historical comfort and debatable success that perimeter enforcement solutions provided created "a box in the middle will cure our application woes" mentality that persists today. What we really get each time we substitute a middlebox for secure programming and secure OS (implementation and configuration) is symptomatic relief, not cure.

The security industry is eager to build middleboxes that don't quite cure the woes but narcotize users sufficiently that they are happy to buy expensive boxes, flog configurations, study traffic logs, buy more boxes, flog configurations... Feed the addiction. As long as users are buying the drugs and doping themselves senseless so they can ignore the root causes at the endpoints, we shouldn't anticipate that things will improve dramatically.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID684 by Dave Piscitello  

My article, Are Commercial Firewalls Ready for IPv6?, is now available at USENIX ;login: online. USENIX has a very practical Copyright : authors own the copyright to their works and grant USENIX permission to publish it in ;login: and on the Web. USENIX owns the copyright on the collection that is each issue of ;login:

Rik Farrow, ;login: editor, has graciously provided a PDF file from the published version, which contains the issue version and date at the bottom of alternate pages.

Happy reading!

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID682 by Dave Piscitello  

A recent thread on the pen-test@securityfocus.com mail list asked whether firewall rules should drop or reject traffic that doesn't conform to the security policy. A firewall that rejects inbound traffic will either respond with an appropriately flagged TCP segment or return an ICMP response packet to the traffic originator (the ICMP packet contains an error notification that was originally intended to be used for diagnostic purposes). The responses a host would typically generate are as follows:

SYN/ACK if port open
RST/ACK if port closed
ICMP message type 3, code 1 (Destination host is unreachable) if targeted host is down
ICMP message type 3, code 0 (Destination network is unreachable) if targeted subnet is down
ICMP message type 11, code 0 (Timeout during transit) if destination cannot be reached within the specified TTL

A firewall that drops or silently discards inbound traffic is operating in what many call stealth mode and does not return any packet whatsoever. In theory, by not responding, the administrator prevents a would-be attacker from gathering information from the firewall.

In practice, operating systems of nearly every networked device can be distinguished from each other by the way (TCP) response traffic elicited from open ports is composed: this is called OS fingerprinting. Moreover, a security policy can be deduced by enumerating listening/responding ports, so security by obscurity buys you very little. However, some security practitioners argue that operational considerations may influence whether you reject or drop traffic, and if your firewall permits, you may wish to implement a different strategy on your trusted interfaces and public-facing (external) interfaces. For example, some practitioners suggest that responding explicitly using reject messages can be a useful strategy on trusted interfaces, to reduce delays associated with timeouts: if a port or destination is blocked, the client attempting to connect to that destination receives an error notification on the first attempt and no retries are attempted. On external interfaces, the reject strategy will cause the firewall to return a message to the source address in the IP header encoded in the packet that violated the security policy. This may be a spoofed address, and an attacker can use your firewall in a redirection/nuisance attack by spoofing the source IP address to point to a targeted 3^rd party.

One pen-tester made an interesting observation with respect to rejecting traffic on external interfaces and the potential that responses might abet a DOS attack.

...the chances are your network is going to expose at least one TCP port to the outside world, for instance. If you do, then an attacker can use you for reflected TCP handshake amplification on that port. You won't be able to do much to stop it, in all likelihood, and it doesn't matter if all of your blocked ports send out one [reject message]. The attacker won't bother using it, since he gets better amplification on the open port...My research was specifically focused on information leakage through TCP port scanning. After modeling the various scenarios (SYN stealth scanning, spoofed SYNs, spoofed SYNs through an idle scan, etc), I found that the best strategy for the defender is to always return a RST/AK on blocked ports.

The poster explains that a strategy limiting reject messages per IP address to one is a form of what is called tarpitting. Tarpitting is a strategy often used by email system admins to discourage spam. The email admin will cause an SMTP session to be paused after a permitted number of RCTPs is processed which makes his server more available to legitimate users and less attractive to a spammer (a delay of seconds imposed across millions of email messages can extend the spam delivery timeframe from minutes to months). This strategy does not prevent scanning but it does prevent your firewall from being the reflector of large numbers of TCP segments to a targeted third party machine (the machine that uses the IP address that was the source address in the instigating packet). If you explicitly reject every packet you receive from a single IP address, you generate lots of redirected packets. If you only send one per IP, you eliminate this amplification factor.

I thought this was an interesting thread and have attempted to consolidate many of the useful comments it into a single article. I take no credit for the comments and offer kudos to the folks who participated.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID613 by Dave Piscitello  

Most midrange enterprise firewalls have some IPS. Some have this as well as antivirus, antispam, and antispyware. Others offer HTTP proxies that provide considerable content control features. Don't expect to see many "pure play" Internet firewalls in future product offerings. Firewall/IPS vendors can't compete in the Global 2000 plus SMB market if they don't offer an expanded suite of security services in their appliances.

A recent thread on the Firewall Wizards email list asks whether this is a good or bad trend, and it made me think of the number of times that people ask me whether you sacrifice defense in depth by deploying multi-purpose security appliances.

You can still have defense in depth. You achieve it by deploying multiple and diverse security services where they are most effective in enforcing policy. This is a separate issue from whether the security appliance you choose has one or more security services, whether you use all the services in each location where you deploy the appliance, and of course, where you deploy security services in your topology to achieve defense in depth.

I think it's quite possible to use a multi-purpose security appliance, for different purposes, in multiple locations in your topology. For example, one might configure an Internet-facing security appliance to handle DDoS and network threats. Behind this, on a trusted segment where web and application servers, you might put a security appliance that examines HTTP streams and protects my servers from input validation, SQL injection and other application level attacks. On a separate trusted segment for client endpoints, you might put a security appliance that that performs user authentication, proxies HTTP and handles URL filtering and strips content that is disallowed by an AUP. The security appliance protecting the client endpoint segment might also providegateway antispyware, antispam and antivirus services.

Several security appliances support all these security services. Could I use the same appliance in different locations in the configuration I describe? Sure. IMO, the benefits of having a common management platform, common logging format and common configuration and log archival facilities (if present) outweigh any misgivings you might have about putting an appliance in your network and not taking advantage of every feature at every opportunity. Some people may argue that this violates a "best of breed" philosophy. I'd argue that sometimes, you may be just as well served buying the best of a multi-purposed breed. And if you find that no security appliance meets every security service need, well, then you might still consider the multi-purpose appliance that meets the majority of purposes, and complement this with single-purposed systems that meet the rest.

But the fact that all the security services your organization might require are bundled into a single security appliance shouldn't lead you to conclude that you can satisfy all your security policy objectives at a single location, using a single device.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID530 by Dave Piscitello  

Windows Firewall may not be the most fully-featured personal firewall, but this alone shouldn't prevent you from disregarding it entirely. Clearly, using Windows Firewall is better than using no firewall at all. But in a previous article, I described how many organizations disable personal firewalls on PCs connected to internal (trusted) LANs, and that this practice leaves computers vulnerable to malicious code that distributes itself using anonymous file shares and common LAN applications. So I'll reiterate my earlier claim that using Windows Firewalls on non-mobile systems in trusted LAN environments is an inexpensive way to improve your organization's security baseline.

Windows Firewall does support logging, and I'll of course argue that every PC with WF enabled should turn on logging. I've recently come across two freeware utilities that complement WF nicely. XP Firewall Log Reader is a no-frills log viewer. This very basic utility opens WF's pfirewall.log and displays it in a non-resizeable window. This utility might prove useful to help desk staff in large and small businesses. Imagine a user places a trouble call, claiming he can't access an application. Help desk staff asks the user, "launch XP Firewall Log Reader, scroll down to the date and time he experienced problems, look for the word DROP, and tell me what number is in the column called DST-Port..." You just may save the time you'd spend visiting the user's office, right?

FireLogXP1.3 is a more ambitious utility: FireLogXP actually analyzes your WF Log. The top pane of FireLogXP's window summarizes connections between source and destination IP pairs. Highlight a summary line in the top pane and the bottom pane summarizes the connections between the pair you highlighted according to port accessed. This feature that makes this an interesting utility is that each summary of ports accessed identifies both the standard port application (http/80, dns/53, ...) *and* a list of possible malware that are known to use the port. So while the conventional use of UDP Port 53 is DNS, FireLogXP will also inform you that ADM worm, li0n, MscanWorm and MuSka52 malware have been known to use this port as well. If you right click on a selected line in the lower pane, FireLogXP pops up a "What is port X"? prompt. Left-click on the prompt and the program opens a browser page to the Internet Storm Center (e.g., http://isc.incidents.org/port_details.php?port=53), where you can learn a great deal more about the ways this port is used and abused. FireLogXP is more of a power tool than XP Firewall Log Reader, and IT staff ought to consider including it in their own security toolkit. But home power users who are keen on learning Internet Security will find this utility to be an enormously helpful application as well.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID512 by Dave Piscitello  

A recent posting to a firewall mail list asked the question, "How do large organizations manage firewall rule sets? Specifically, how do they determine when to remove a policy that is no longer required?" This firewall administrator is always being asked to open access for new applications, but is rarely informed when an application is deprecated and the associated access policy can be removed. Sound familiar?

I mulled this over for a while. Organizations that implement security according to a regularly maintained security policy should never encounter this situation. Requests to add access are reviewed and if approved, recorded in the policy. For example, the security policy team meets in June 1994, reviews a request, and agrees that access to gopher service is permitted. The team notifies the firewall admin to open port 70/TCP. Time marches on. Everyone who used gopher has retired or expired.

In March 2006, the twenty-somethings who now comprise the security policy team review the policy. Everyone in the meeting says, "what the heck is gopher?" They agree to remove gopher access, revise and post the policy, and notify the firewall admin to remove the firewall rule and block access to gopher servers. Who wants a double shot mocha no fat?

OK, it's an interesting bed time story, but in the all too common world of policy-challenged organizations, the story is quite different. And so a more practical question to ask might be, "How do security admins of large organizations know when to remove an access rule from a firewall config?"

When firewall configuration is not policy-driven, admins can rely on what they see in logs. This gives me the opportunity to campaign once more for logging allowed traffic. If you know what traffic is allowed and you log all allowed traffic, then you can monitor what is actually being used and to what extent. Review your logs. When was the last time you saw outbound traffic on port 70/TCP on your network? December 2003? Now you can follow this simple rule of thumb: if you see diminishing to little traffic for a given application, ask management (and employees) whether a business need still exists. If no one speaks up to justify continued access, close the port and as my colleague and friend Fred Avolio says, "wait for the phone to ring, and ask for a business case".

Yeah, I know. This is too easy.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID511 by Dave Piscitello  

I just completed an article for Watchguard about using an http proxy to strip ad-serving cookies. Legally, not every ad-serving or behavior tracking cookie is spyware. Why not? Spyware installs without your notice and consent. Every browser provides ways to opt-out or refuse cookies, so cookies do not qualify as spyware *unless* they collect personally idenfitying information. Of course, now that legislation makes a clear distinction, the giant ad-serving companies have begun offering opt-out mechanisms and those that don't collect PII go to court to force antispyware software vendors to remove them from adware blacklists.

The legislation is flawed. Cookies collect lots of information that cannot be categorized as PII but are potentially harmful to you and your business, and potentially useful to an attacker (add'l reading).

For the Watchguard column, I did a small study of 3^rd party cookies that pass the "it's not spyware" criteria. From the cookie caches of a half-dozen PCs in my office, I identified a sampling of two dozen ad-serving cookies. I reviewed the privacy policies of the ad-serving companies and concluded that 20 of the 24 collected information I was not willing to share. In some cases, the cookie collected topology information; in others, the cookie collected exceedingly detailed accounts of web behavior. Call me paranoid. I don't want undisclosed third parties gathering this sort of information, even in an aggregated and anonymous manner. Behavior-tracking is just too Orwellian for me.

It's too hard to maintain "ad-serving cookies that are not spyware but annoying nonetheless" block lists at the browser level. Instead, I added proxy stripping actions on my FireboxX and blacklisted the 20 companies that may not be spyware to my Republican Congress but they are to me.

It's absolutely amazing how many cookies I'm stripping; in fact, if I watch my realtime event monitor, it's actually quite funny (or pathetic). And for what it's worth, stripping third party cookies doesn't appear to interfere with anyone's "web experience":-)

The cookie problem won't disappear. Cookies have been overused and overloaded, and first party or "site" cookies are unfortunately an integral part of many web user's experiences. If everyone blocks third party cookies, the behavior-tracking companies will obfuscate their cookies and make them indistinguishable from site cookies, or they'll sell services and software.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID510 by Dave Piscitello  

Following the second leg of the NWW Security Tour, I have even more questions to answer. Trying to knock off easy and popular ones quickly, I chose,

Where is the best place to put IPS in a network?

Where you place IPS (or IDS) is largely affected by the types of attacks you seek to block and the vectors you believe attackers will use. If you are worried about network level denial of service attacks from origins outside your trusted networks, you might use IPS at an Internet-facing firewall, but if you are worried about DOS attacks emanating from trusted network segments - WLANs, home office broadband and business partner networks connected to your trusted networks using IPsec VPNs - then you might place defenses against DDOS closer to server farm(s), or even on individual servers, in the form of host intrusion detection and protection. The closer you place IDS/IPS to actual assets, the more you are able to defend against both external and "insider" threats.

IPS can also block application level attacks. The same stipulations apply. I wrote about application protection in some detail here.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID463 by Dave Piscitello  

Some time ago, the question, "What do those of you in large environments do to manage your rulesets in terms of removing access that is no longer required?" was raised on the firewall wizards mail list. I failed to copy the mail list when responding to the question, so I'll post it here.

Let's assume your organization is policy-driven, and access adheres to authorization policies developed during the course of routine risk assessment. In situations where an organization's needs for application access are reflected in your policy - i.e., policy as of 7/17/2005 says SKYPE is permitted outbound from our trusted networks - then stakeholders who agreed to allow this application must also agree when that application is no longer needed or appropriate before IT can change the firewall policy. To handle *application deprecation* in this fashion, organizations institute a regular review cycle, and the excellent among these trim application "fat" whenever stakeholders conclude an application is no longer required.

Just as policy-before-access empowers IT administrators with the means to deny spontaneous and random introduction of applications with no (obvious) business purpose, it can also prevent applications from hanging around beyond their useful lifetime. How is this beneficial? In situations where an application simply piggybacks on an existing firewall policy, e.g., allowed port http/80 outbound, and assuming you'll always need http outbound, I'll admit it's not obvious. But consider a situation where your organization is not only allowing a defunct SNA application (yes, it's still around!), but rate-limiting traffic from other applications as well because of the bandwidth and latency you once reserved for tunneled APPC/LU6.2 sessions.

What if your organization isn't policy driven? If you log allowed traffic, you can use traffic logs to identify whether an application is still in use. If you also enforce user (and group) based access controls, you can identify who's using it. In the first case, if you see d=little or no activity, you can simply deny access and wait for the phone to ring. In the latter case, if you see diminishing to little traffic, you can inquire whether a business need still exists among the dwindling user constituency; if none is justified, you close the access. (Note: if http/80 is your organization's outbound ANY port, read blog #419.)

How far can you take firewall policy life cycle management? Some organizations are plain ruthless, and shut down access if little or no activity is seen as a matter of policy. This can be tricky, as some business critical applications may only be used sparingly, e.g., an application related to quarterly reporting (earnings, accounting, inventory...). Whether you are policy driven or not (but especially if your organization practices policy life cycle extremism) always document when you deny access and save the exact rule you modify in your firewall configuration. You'll be ready to restore service in the event a deprecated application is resurrected without a moment's (or day's) hesitation.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID461 by Dave Piscitello  

Reviewing logs when you introduce a new application to your internal networks is always a good idea, especially when that application involves client-server or peer-to-peer communications with external hosts. By reviewing logs, you learn that some applications are well-documented and well-behaved, and use a well-known port as the gods intended. Increasingly, however, application developers are bending the rules, all in the name of ease of deployment and plug-and-play.

The symptoms of the rule-benders have become all to familiar. The client application tries to connect to peers or servers over its well-known port(s). Failing to reach the mother ship using these ports, the client may try NETBIOS ports, and failing these, http/80. Why? HTTP/80 is almost assuredly open outbound on Internet firewalls today. The objective of the application developer is to make certain the client connects without requiring (firewall) administrative intervention. So what better port to choose as the default than http/80?

I've tested and use several collaboration clients, remote desktop clients, and multi-player online games that are written to behave in this manner. I often run a LAN analyzer or block http/80 outbound initially to see what the clients will try. One capture session for any of these applications quickly reveals they aren't trying to be stealthy (most are quite the opposite). They aren't maliciously seeking to evade detection. They just want the application to work the way users have come to expect applications to work - plug and play.

I no longer complain to vendors that this is architecturally distasteful. I will, however, open the well-known port these applications (hopefully) seek first. This allows me to monitor and control this application separately from web traffic in general. I can review logs and quickly see connections and traffic associated with individual applications. I can schedule times when this application is to be used; and allocate bandwidth based on relative application priority. With user authentication, I can even control who uses the application. None of these granular controls are available if I simply say "allow whatever over http/80". (I also eliminate all the silly port-seeking traffic).

In larger shops, this method might help administrators identify slackers and excessive users. I don't think you really need firewall logs to identify these folks, but that's fodder for another blog entry.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID419 by Dave Piscitello  

My friend and colleague Marcus Ranum delivers a "no holds barred" assessment of deep packet inspection and firewall proxy technology in this editorial. Some stateful inspection advocates will no doubt take exception to Marcus' analyses, but IMO, it's a bluntly accurate piece. From Marcus, you'd expect nothing less.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID409 by Dave Piscitello  

Microsoft Security Bulletin MS05-021 describes a vulnerability in Exchange Server that could allow remote code execution. Basically, an attacker can connect to Exchange Server SMTP port, issue a maliciously crafted command and gains admin privileges. A variant of the attack can be used to deny service.

Microsoft recommends that you use SMTP protocol inspection to filter out SMTP protocol extensions as a workaround to protect against this vulnerability, and suggests you use default ISA publishing rules for Exchange. They also casually mention 3^rd party solutions. How considerate that they point you to the right solution: a secure proxy.

A secure SMTP proxy, by definition, examines mail and strips or blocks malformed headers and suspicious contents. A secure mail proxy isn't a workaround, it's part of a layered defense. This vulnerability isn't something radical and new. We've seen dozens like it before, and folks like Marcus Ranum invented proxies for firewalls to deal with malformed protocol attacks. If you were running a secure mail proxy, you wouldn't have to worry so much about every little Exchange vulnerability...

Archived at http://www.securityskeptic.com/arc20050401.htm#BlogID385 by Dave Piscitello  

I've been experimenting with content filtering associated with the HTTP-Proxy at my firewall, to see what if any additional measures I can take to block malicious content from infesting my hosts. I began with a conservative list of allowed content types - text, image, pdf, xml - and a "suspect it's spyware and explicitly block it" list of undesirable body content types - zip archives, Windows exe/dll and CAB archives, and Java bytecode.

I slowly began adding types that are arguably not absolutely safe, but absolutely necessary if you expect to enjoy the richness of the web, especially its entertainment aspects. These included application/x-javascript, application/x-shockwave-flash. Life was good on all the PCs - no user complaints.

About 10 days into my experiment, my kids complained that the TV program listings no longer displayed on my ReplayTV. Visiting my firewall log, I discovered that ReplayTV uses its own content types - application/vnd.replay.cg and application/vdn.replay.headend - which my firewall was dutifully blocking. Adding these to the allowed list solved the problem, and my ReplayTV disk is once again filled with Japanese anime cartoons.

The experience illustrates how content filtering adds another dimension to security policy maintenance. It also illustrates how firewall admins are forced to keep current with application development at so many different levels - transport encapsulation, port and bandwidth utilization, protocol composition, network protocol, addressing, NAT and naming dependencies - that it's easy to overlook when a developer elects to create new content type rather than use an existing one.

And the developer probably did so because content filtering proxies were blocking the type he originally chose:-)

Archived at http://www.securityskeptic.com/arc20050301.htm#BlogID381 by Dave Piscitello  

I've written a handful of articles on firewalls. I've created a page of firewall-related resources to provide a "portal" to these and many other firewall resources I've accumulated over the years. If you know of good, recent firewall articles - and classic ones - please help me add to this list.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID367 by Dave Piscitello  

Routine examination of firewall logging activity is an important task, even for small business firewall admins. Look at your firewall log over the past several weeks, and compare what you're seeing to what I'm observing as the most common probes.

This week I see the DENY IN events for Microsoft RPC/LSA and Active Directly Login exploits (TCP/1025-1026) are again tops on the my "most frequent denies" list, followed closely by DNS requests (UDP/53).

Frequent DENY IN events for TCP/4899 reveals that copies of the W32.Rahack worm are scanning my ISP's IP address space (begins with 64) for hosts running the Win32 Remote administration program, Radmin.

I'm also seeing the occasional, single DENY IN events for TCP/15118, the Dipnet/Oddbob worm.

Another occasional, unusual DENY IN event appearing recently is TCP/6129, a probe for the Dameware remote admin tool.

I rarely see brute-force port scans these days. I don't see SQL scans, either. Three of my top probes are hunting for exploitable RATs or bots. If I factor how many web application probes I block daily (about 20% of my traffic), attack patterns at my site are representative of attack patterns and trends: a majority of attacks focus on exploitable or exploited applications.

Archived at http://www.securityskeptic.com/arc20050101.htm#BlogID358 by Dave Piscitello  

Too many firewalls and access routers allow trusted hosts access to virtually any services outside their firewall without considering the consequences. Organizations should be as concerned with the origins and kinds of Internet-directed or egress traffic as they are with incoming requests. Lax egress traffic filters can cause an organization many headaches, as Nathan Buff and I explain in this article. More...

Archived at http://www.securityskeptic.com/arc20041201.htm#BlogID337 by Dave Piscitello  

"De-perimeterization" is popular among the VPN, application protection, and web services communities. It's another in the never-ending stream of labels that marketing wonks invent to distinguish what they are trying to sell from what everyone else is selling. It's a dumb and inaccurate term that only serves to confuse buyers, which ultimately causes them to buy badly, or not buy at all. De-perimeterization is a testimony to the shortcomings of a society that operates on ten-word sound bites.

De-perimeterization is "a worldwide push toward a more porous corporate shell yet more secure collaborations in our increasingly interconnected online world"¹. De-perimeterization is yet another forecast of the demise of the corporate perimeter, the traditional network firewall, in this case due to the increased employment of web services in collaborative networking: simply put, not only people but executable code (services) move across enterprises, mostly over web, and hence through ports that network firewalls allow inbound and outbound.

What the term tries to convey can't easily be done in one word. What the term and the hype woefully misrepresent spreads the F.U.D.

De perimeter exists. You've misappropriated the prefix de.

There are many perimeters in the present and future enterprise. The perimeter that that de-perimeterization tries to deprecate is maintained through network layer firewalls. It's not going away. It's now decentralized through the use of personal, teleworker, and small office firewalls as complements to enterprise Internet-facing and compartmental firewalls.

Further complementing the network layer perimeter is a perimeter of application protection. This additional layer of security will be responsible for assuring that application connections are authenticated and that the data conveyed over them is authentic and (where appropriate) confidential. And by this, I don't mean "VPN".

The column I cited earlier casts skepticism on de-perimeterization's ultimate goal: "worldwide use of system-, data- and connection-level authentication". While I hate the term, I love the objective. What is often misunderstood when we use the word data is that data includes identities, information web services process and and the executable code (services) organizations exchange, as well as the channels over which this data are communicated. This is not de-perimeterization at all, but the addition of federated identities to our existing layers of security.

We don't need a new term. We need people to RTFM and use the terms we have appropriately.

Archived at http://www.securityskeptic.com/arc20040901.htm#BlogID303 by Dave Piscitello  

If you are reading my ISSA article, "Firewall Best Practices--Egress Traffic Filtering, you may want to also read The Enemy Within: Firewalls and Backdoors, by by Bob Rudis and Phil Kostenbader. This paper discusses backdoors: in the section, A Ready Defense, the authors cite some of the same best practices Nathan Buff and I mention in our column. Corroboration is always comforting.

And while you're reading both of these, if you want to know more about backdoors, read Detecting Backdoors, by Vern Paxson and Yin Zhang. This paper is from 1999 (a millennium ago!) but the general algorithms for detecting backdoors based on keystroke characteristics is interesting nonetheless.

Archived at http://www.securityskeptic.com/arc20040301.htm#BlogID224 by Dave Piscitello  

I've published an article on egress packet filtering in the March issue of the ISSA Journal. In the article, Nathan Buff and I explain that many organizations expose themselves to a number of risks by assigning lax egress (outgoing) traffic policies. We make a case to corroborate our claim that, "what you allow out can be as damaging as what you allow in", and then offer a list of egress traffic configuration considerations that can improve your security risk profile.

Find the full article here. Membership is required, but you can apply for a trial membership.

Archived at http://www.securityskeptic.com/arc20040301.htm#BlogID222 by Dave Piscitello  

A recent posting to firewall wizards illustrates two fundamental problems we absolutely must overcome before we can hope to improve security.

The post is a simple inquiry:

Im working on ... trying to connect to someone on ... using iChat AV to AIM...they get an error that says is probably caused by a firewall. If this firewall is put in by their network, is there anyway around it?

Problem #1. If we only think of security as an inconvenience and seek to circumvent it, no amount of technology and process can help us. The corollary to this axiom: If, in addition to playing network cat-and-mouse with attackers, we are forced to do so with legitimate users, we are truly hosed.

Archived at http://www.securityskeptic.com/arc20040301.htm#BlogID216 by Dave Piscitello  

Bob Frankston's written an interesting albiet contemporary rather than technical essay on firewalls, (Firewalls: The New Maginot Line). The essay claims that firewalls are of themselves not a sufficient solution; that firewalls (generically) create a false sense of security, and that additional measures, placed closer to assets at risk (my term) are required to improve security.

My gripe with Bob's essay is that using the term firewall generically rather than comparing Internet firewalls - the ones that separate trusted networks from the not-to-be trusted Internet - damages the analogy. Firewalls take many forms:

• Internet firewalls

• Inter-departmental firewalls

• Server-farm or Internet Data Center firewalls

• Security Switches (perhaps indistinguishable from IDC firewalls)

• Server firewalls (software or network interface card)

• Personal firewall software for PCs

I hate to see this distinction blurred because it adds fodder to the "firewalls are extinct" marketing sleight of hand.

InternetFirewalls aren't extinct: they are infrastructure. The presence of an Internet Firewall is an understood, a given, a prerequisite, a checklist item for compliance. [Note however, that an Internet Firewall is present is not an reliable indicator that it has been configured to operate effectively and consistently with a documented security policy.]

If you don't believe this is true, then take yours out of production.

A post script: I can't help but imagine the following simile in an achievement (or certification) test:

An Internet firewalls is to the Maginot Line as a Personal software firewall is to a:

• Post Office

• Militia

• Police force

• Forensic response team

Archived at http://www.securityskeptic.com/arc20030901.htm#BlogID134 by Dave Piscitello  

"When you pretend to sell a firewall, ensure that

it blocks traffic which it is not able to inspect" - new InquisiTeam

I couldn't resist publishing this quote. It comes from a July 9, 2003 vulnerability report on a firewall that fails to block broadcast frames containing non-IP traffic (SNA, IPX) when operating in bridge mode. The vulnerability report is nowhere near as important as the quote (except to this manufacturer's competitors and customers, of course).

If there ever were a definitive list of firewall design rules, you'd have to conclude that if this isn't design rule number one, it's got to be in the top five.

Archived at http://www.securityskeptic.com/arc20030701.htm#BlogID83 by Dave Piscitello  

A recent post on the firewall-wizards mail list asked whether a small office firewall offered more security than a NAT device.

The ensuing thread reveals a lot about how difficult it is to characterize small office security and access products into these simple categories.

One thing I'm very confident in stating is that:

All firewalls do NAT, but not all NAT devices do firewalling...

All the firewalls I've ever configured, small office or enterprise class, do at least one form of NAT - IP masquerading, a.k.a., dynamic NAT, which is more accuratley called Port Address Translation - where the only public IP address revealed to the outside world (Internet) is the firewall's public IP address. Most enterprise firewalls do static and 1:1 NAT (you can read more about all three here.

Today, it's hard to classify devices as firewall appliances or NAT devices. A look at the history (such a short time span probably only deserves to be called a chronology of events) of SOHO access and security devices reveals why.

In the broadband access marketplace, access devices began as little more than xDSL and cable modems. Early broadband "consumer" users and service providers heavy into consumer markets were ignorant of the need and hence reluctant to buy small office firewalls; i.e., the kind that do (stateful) packet inspection, terminate manly VPNs, and block some set of well-known denial of service and broadly automated attacks. These were and remain 2x-5x the cost of NAT devices, and for good reason.

Consumers did know they wanted to share broadband access across home and small office networks, and service providers (even the bad ones) realized they didn't have enough IP addresses to hand out like after-dinner mints, so NAT was quickly incorporated into modems to make everyone happy. The result was an access modem that does address and port remapping, elementary (two-port) routing or bridging, and service/authentication using some PPP variant (e.g., PPPoE).

If a NAT Device filters traffic, is it a firewall?

Some vendors added DHCP, a piddly set of security features (simple default inbound and coarsely adjustable outbound filters) and even a VPN - whatever they could squeeze into a commodity-priced product - and everyone began calling these devices SOHO firewalls.

Most "began as NAT" devices fail at least one basic litmus test: the NAT/firewall software doesn't undergo the kind of software audit, testing, and scrutiny firewall vendors are accustomed to imposing (inflicting) on their appliances.

Add any feature set you want. Claim a box is a firewall. Until you've scrubbed the code and subjected the device to accepted, common firewall evaluation criteria and it proves its mettle, it's a NAT box.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID63 by Dave Piscitello  

Firewall testing requires more effort than merely scanning addresses and ports for permitted inbound (and outbound!) services. Here are some tools that may help you assess whether your firewall and policy are satisfying your security objectives.

• Filterrules. This is a pair of programs. From a sending or a master program, you direct forged IP packets to a recipient or slave, which listens on the other side of the firewall and records which packets passed through. Generates a log file in IPFW format.

• ftester. This is a pair of perl scripts. A packet injector (ftest), injects custom packets, defined in ftest.conf, with a signature in the data part. A second perl script (ftestd) listens for such marked packets. Both scripts log results in a common format. A diff of the two produced files (ftest.log and ftestd.log) shows the packets that were unable to reach the sniffer due to filtering rules when these two scripts are ran on hosts placed on two different sides of a firewall.

• Firewalk performs an analysis of IP Packet Responses using a technique similar to that employed by traceroute to determine gateway Access Control Lists.

Archived at http://www.securityskeptic.com/arc20030401.htm#BlogID7 by Dave Piscitello