If you ever feel in need of a lesson in humility, try reading through the TCP/IP RFCs and related literature. I have two questions I have no idea how to answer but rather naively expected that reading this material would help. It didn’t, in truth because I didn’t understand most of it; so now I’m asking you to explain the issues to me.
The two questions are, first, why can’t router software let us stamp out address spoofing? And secondly, why do we use firewalls?
Address spoofing depends crucially on being able to hide the real source address, so why not make that impossible?
One way to do it would be to have all the ISPs and network carriers whose connections constitute the Internet certify where packets entering the network come from.
Any packet has to have an origin characterized, from an Internet perspective, by the point at which it first reaches part of the shared resource — usually a router or other device maintained by an ISP or backbone carrier. Suppose, therefore, that we put software on those devices that allows them to form a self-authenticating community and insert a signed source address into every packet forwarded from the customer’s premises.
Shifting Responsibility
You can do that yourself if you have a network of machines running Solaris 2.7 or later, and the capability appears to be built into IPsec, too, but the goal here would be to shift responsibility, and therefore control, from the originator to the carrier that first puts the packet on the shared network. There seems to be room for this in the standard, the technologies needed are well understood, and the number of major carriers and ISPs involved is relatively small.
Making it happen shouldn’t be very hard, and the nature of the carrier’s role as the packet producer’s gateway to the Internet means that attempts to send packets with false information already loaded will fail, while internal authentication among participating routers should make spoofing it at the point of delivery impossible.
If even a relatively small percentage of e-mail and other Net-aware applications were changed to make use of the resulting unforgeable “this came from” information in every arriving packet, both Web- and spam-spoofing would very quickly become impractical.
That has good consequences for both the antispam and antiphishing forces. For example, software to automate ISP source tracing and customer notification, if a PC or other device started spewing spam, would be almost trivial — meaning that putting someone else’s machines into disservice through a virus or worm would become much less effective than it is now.
Denial of Service
More importantly, spam recipients could safely respond to spam in the obvious way — by bouncing the mail back to its real source several dozen times, thus initiating a denial-of-service response on the spammer without allowing others to use the predictability of this response as a means of initiating a denial-of-service attack on the innocent.
So what’s wrong with this picture to explain why it isn’t done? I haven’t a clue, do you?
My second issue is both more straightforward and stranger. I’ve been watching a client blow up his network by installing SP2 in support of the notion that several thousand PCs inside a highly protected, and carefully segmented, network should all have their own firewall protection too.
That seemed a bit of overkill to me, but asking why they thought this appropriate showed that they were responding on auto-pilot and thus raised the more general question: why use firewalls at all?
Like everyone else, I know firewalls should be used, but not why. Is this something sensible like wearing a seatbelt or an obsolete workaround, like DHCP, for long-gone limitations in Windows?
It’s the Service, Stupid!
The way firewalls work is instructive here. In the simplest case, arriving packets are captured before any local processing takes place and are either discarded or passed on for normal handling, depending on whether the destination port is supposed to be open or not.
Think about that; am I being naive or wouldn’t just not starting the service have the same effect without incurring the overheads associated with the firewall?
Obviously, there are some services that users don’t want to do without, but sometimes that’s just too bad –my own secure workstation, for example, is protected by a combination of Solaris 2.8 on SPARC and an empty socket where the network connector should be.
Most of the time, however, layering functionally identical firewalls just seems to lead to user frustration without providing much in the way of real protection. Not only do things like Microsoft’s use of SOAP and webXML as a programming environment for the Internet provide nearly ideal means of bypassing firewalls, but the reality is that even relatively simple hacks can render most firewalls useless. Two widely known methods from the past, for example, used the ttl (time to live) setting and significant differences in the packet assembly process used by Unix and Windows derivatives to bypass both firewalls and active intrusion detection systems.
Unnecessary Effort
There are more esoteric attacks — reprogramming the firewall’s own receipt-side NIC produces an undetectable bypass — and easier ones, like overpowering a WiFi installation, but such things might simply not be necessary. After all, if firewalls are so valuable, where’s their impact on the spread of worms? When SQL-Slammer took roughly 19 minutes to slam most of the world’s network-facing Windows machines — including Microsoft’s own — where were the firewalls? Out of the loop and useless, that’s where.
So why do we use firewalls instead of debugging services for security-related errors, using standard tools like subnetting and nonroutable packets to limit external exposure while turning off things we don’t need, like SMB networking, error reporting, or QoS futzing?
The more I worry at it, the less obvious the answer becomes, so if you can tell me — without calling me an idiot — I’d really like to know.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.
Loading ...
So will anything ever be done about address spoofing?
Will firewalls make your computer move slower? I really don’t know what there use is either, or if the use of firewalls are really more headache than anything.
With respect to address spoofing, there are methods which help to alleviate the problem. The most common is IP reverse patch, and is implemented by many routers and firewalls, from Cisco and other manufacturers. The idea is the following: a packet is received from an interface IN with a source address SRC. One can check if the packet source address may have been spoofed simply by doing the following check: If we were to send out a reply packet (with a destination address SRC), would it be sent out using the same interface IN? That is, whenever a packet is received, the router checks if, when replying to that packet, the response would follow the same path it was received from.
Of course, there could exist a scenario where this kind of checking couldn’t be applied, but the premise is strong: if a packet is received from a source address through an interface, but the source address is not reachable from that interface, the source address could have been spoofed (or maybe a route loop exists, or else).
NAT devices shouldn’t create address spoofing problems since their martian (non-routable) addresses get translated by a NA(P)T device into a global, valid IP at the network exit point. Thus, public, end-systems don’t see the martian IP address, but an IP address from the NA(P)T pool of global addresses.
Also, every border router should perform ingress and egress filtering to prevent possible packets with source/destination martian addresses don’t pass through them.
Thus, IP spoofing can be, if not eliminated, at least reduced, by using this simple techniques. I _already_ perform ingress and egress filtering on my border routers and perform IP reverse-path checks on all my Cisco routers. I think you should too.
– He asks "Why can’t we have guaranteed unspoofable source addresses on packets". Several answers to this one, but the two that come to mind first are:
(1) Most computers on the internet don’t have real unique internet-routable email addresses; they’re behind some other computer doing network address translation. Many of those that do have real addresses only hold on to them for a little while using DHCP.
(2) You could not really guarantee unspoofable source addresses unless EVERY SINGLE DEVICE ANYWHERE IN THE WORLD capable of routing packets to the internet had code built into it to enforce it. Unless you were satisfied with narrowing it down to the ISP, in which case you still have several million users to finger in some cases. This buys you nothing.
– He says "The number of major carriers and ISPs involved is relatively small". A quick SWAG based on looking at some ISP rating websites indicates somewhere around 5000 that are big enough to advertise on such a thing. Adding MomAndPop ISP’s might bring that to 6000. Adding web host, colo, business, and hotspot, and you probably have aroun 7000. Wait, that’s just in the US! Now you need to add all the other countries. Fugetaboutit!
– He says "Why don’t firewalls stop email worms?" Duh. The Firewalls most people and companies use are designed to make sure you only get connections to services from valid places, and under the right conditions. They don’t scan your emails. They don’t, in general, filter content. The reason worms spread so fast and pervasively is because Microsoft has deemed that users are best served by having all incoming content (from email or web pages, for example) deployed automatically, or at most with a single click, and that the last few letters following the last few dots, indicating the type of file, would confuse the user, so they’re better off not seeing them. Yes, these options can be changed to some extent, but most of the MSFT users out there don’t know how, or why.
– Enabling or disabling a service is NOT the same thing as opening or closing the port on a firewall. The firewall can do more, like ensure that incoming packets are only allowed in response to a connection sent out (SYN/ACK checking), disallowing new incoming connections to the higher (>1024) ports, disallowing connections from know evil parties, etc.
Thanks for the comment but…
<P>
There are perhaps 50,000 qualifying ISP/primary connection sources worldwide. Isn’t that easier to deal with than a claimed 200 million PC users?
<P>
ISPs using DHCP to deliver home/soho services have both the temp IP address and the account id available to identify the user. The IP lets the response get routed back, the account lets the ISP get in touch with the offending user. The situation for companies operating many PCs begind proxies/NAT is similar: as a user I don’t care if joe or jane sends the offending message as long as I can get to their bosses to have the problem taken care of.
<P>
I’m not saying firewalls should stop worms, I’m saying they’re not useful for the purpose. In fact, if you go down the list of what they’re supposed to be good for, I’m starting to think you could eliminate all of them if the fundamentals of tcp/ip were a bit better handled at the PC.
Paul Murphy on Sep 23 2004 said ..
<para>
"The two questions are, first, why can’t router software let us stamp out address spoofing? And secondly, why do we use firewalls?"
<para>
"Address spoofing depends crucially on being able to hide the real source address, so why not make that impossible?"
<para>
There is no provision in the current protocol (IPV4) for verifying the from address. Routers work at the lowest level and do just that – route.
<para>
"One way to do it would be to have all the ISPs and network carriers whose connections constitute the Internet certify where packets entering the network come from."
<para>
In order to do that then all routers in the world would have to be simultaneously upgraded. There are enhancements in the next IP version IPV6 to provide for this.
<para>
"the goal here would be to shift responsibility, and therefore control, from the originator to the carrier that first puts the packet on the shared network"
<para>
"So what’s wrong with this picture to explain why it isn’t done? I haven’t a clue, do you?"
<para>
a) It is difficult to impliment.
b) Therefore it is expencive.
c) The ISPs can’t be bothered.
<para>
"Like everyone else, I know firewalls should be used, but not why"
<para>
01. If you’re running an internal IP service on port 5192 and you are also connected to the Internet through a gateway then you don’t want anyone on the Internet being able to ping this service. No doubt this service is password protected but you still don’t want it visible to the Internet as information can be extracted from repeated querying of the service. With no firewall any machine on the network can be co-opted as a proxy to relay information in and out. Netcat is one usefull tool that comes to mind.
<para>
02. If a Windows machine is compromised and tries to run a backdoor service on port 5192 then at least it get blocked at the firewall.
<para>
" am I being naive or wouldn’t just not starting the service have the same effect without incurring the overheads associated with the firewall?"
If you could guarantee that no such service could be started or that the port could not be opened – then yes.
<para>
In the original Unix model only ROOT could open the standard (FTP etc) ports. An ordinary user could not. That was part of the trust relationship on a network. If a local server contacted your server on port X then you could guarantee that is was from where it said it was from.
<para>
"things like Microsoft’s use of SOAP and webXML as a programming environment for the Internet provide nearly ideal means of bypassing firewalls"
Yes, that is correct. Since the advent of SOAP and ‘web services’ the protections afforded by a firewall have been much diluted. SOAP, a HTTP wrapper of an XML wrapper of a RPC wrapper of an executable. All so dynamic web pages can get through the firewall. Never mind what this does for security. The future is going to be very interesting.
<para>
"So why do we use firewalls instead of debugging services for security-related errors"
In conjunction with other services a firewall can limit the damage of a security breech.
<para>
from ‘Are Firewalls Useful? And Another Thing…’
http://www.linuxinsider.com/story/Are-Firewalls-Useful-And-Another-Thing-36837.html