I've had quite a few people mail me off-list, inquiring what
"firewalking" is.
Here's a quick writeup, outlining the basic functionality,
concerns that are often overlooked, and some possible
solutions.
In short - what is firewalking?
---------------------------------
Firewalking is a traceroute-like technique that lets you:
1. Map entire networks behind firewalls
2. Probe ACLs on packet filtering routers / firewalls
How is this accomplished?
---------------------------
Normal traceroutes work by sending UDP or ICMP packets
with different TTL (Time-To-Live) values. As the TTL values
expire at different routers, responses (ICMP Time Exceeded)
are sent back to the origintator to inform him/her
that the IP packet didn't make it all the way.
Normal packet filter rulesets block much of this behaviour,
but when being a little less cooperative, these "traceroute"
packets can actually be injected past packet filters
and even some stateful inspection firewalls.
So, again, the main idea of tracerouting is:
1. Send X packets to a given IP with different
TTLs
2. Observe the returned ICMP Time Exceeded responses, especially
taking note of the sender IP.
Also, an interesting feature of the Time Exceeded messages
is that a copy of the original packet is included inside
the ICMP data, so that the sender can match the ICMP
message to data that has been sent. This is important to
remember, as you'll see below.
What a "firewalk" tool does, is let you specify what
packet gets sent. For instance, you can send TCP
packets to port 80 of a web server, or you can
UDP packets to port 53 of a DNS server.
This lets you inject your short-lived packets past
packet filtering devices, provided that you send them to
hosts/ports that the packet filter allows.
The benifit is that you get to see all routers between
the packet filter and the ultimate destination, if the
packet filter allows the outbound ICMP Time Exceeded
messages.
What about firewalls and NAT devices?
---------------------------------------
This is where it gets much more interesting. The value
of firewalking is increased substantially when NAT
is involved.
For some remote attacks to work, you need to know
private IPs behind NAT devices such as firewalls.
A firewalk will often let you:
1. See all router IPs between the NAT device and the
destination host.
2. See the private IP of the host, since the
firewall will address translate your inbound
probe. This data is then included in the ICMP message.
In some cases, the firewall will even reveal private
IPs of directly connected hosts, even if there are
no routers between the firewall and the destination
host.
But I don't care if someone traceroutes my public servers!
------------------------------------------------------------
Being able to traceroute (or "firewalk" as the case might
be) may or may not be a major concern. A point that many
people are missing however, is:
IT IS ALSO POSSIBLE TO FIREWALK TO INTERNAL CLIENTS, EVEN
THROUGH SOME OF THE STATEFUL INSPECTION FIREWALLS!
(Yes, I intended to write that in upper case, just because
so many people fail to realize it.)
All you need is to know of an open connection from a
client behind the firewall. For instance, if you
know of a connection to www.somewhere.com, port 80,
you can send TCP packets having the ACK flag set, with
different TTLs. These packets are likely to pass through
the firewall and expire at routers behind it.
I thought that my firewall was protecting me?
-----------------------------------------------
Surprise. Many (not all) firewall vendors claim
that most ICMP error messages are harmless, such
as Host Unreachable, Time Exceeded, etc, and pass
them through with little or no inspection.
(I think all agree that ICMP Redirects are very
dangerous though.)
Especially, outbound ones are considered really
harmless. Too bad the firewalking problem _is_
outbound ICMP messages.
I don't have a comprehensive list of which vendor
does what. You'll have to ask someone else which
is doing what, or verify it for yourself with
a firewalking tool.
Fascinating! I want to read more about this!
----------------------------------------------
Go directly to the source:
http://www.packetfactory.net/Projects/Firewalk/
where you'll find the firewalk whitepaper aswell
as source code and a ready-to-go ELF binary.
----
Well, that's it for this time. I hope it'll be
of assistance to at least some of you out there.
--
Mikael Olsson, EnterNet Sweden AB, Box 393, SE-891 28 �RNSK�LDSVIK
Phone: +46-(0)660-29 92 00 Fax: +46-(0)660-122 50
Mobile: +46-(0)70-66 77 636
WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
