While what you say is true Dimitris -- although
debatable.......the real point behind all this is that your firewall is a
great tool, but it has limitations and people need to be aware of
them.
Let us say for instance that you really lock down
the firewall and only allow dns, http, and https out for internet
browsing for all your employees (because it is so critical to your core
business ;)). Your firewall will then let out any traffic using port
80/tcp because it will believe that it is http traffic. Therefore
anybody who wants to could write an application (malicious or
otherwise) to use the same ports and most likely you would never know --
unless you use some of the other options mentioned in this thread. You
can bet this has already been done by the way.
Your normal stateful firewall has no feature set
for distinguishing between valid web traffic and another application using the
same ports. If you do not believe me, create the rulebase then open up a
telnet session and set the port to 80 instead of the default 23. You
will create a session with the web server at the other end -- although it will
not let you really do anything. Use a tcpdump and you will see the
three-way handshake.
With regards to ICMP, there are legitimate
reasons for using ICMP messaging -- it is NOT merely an administrative
tool. If you were referring to ICMP echo requests and replies, you could
make the case, but there are many different ICMP messages and just about all
of them can be used in one way or another to gather information -- legitimate
or otherwise.
Bill
----- Original Message -----
Sent: Thursday, June 13, 2002 3:59
AM
Subject: Re: [FW-1] [fw-1] Instant
Messenger bypass FW-1
I' ve been watching this for some days now. Yes I agree that
AIM and others pose a great security threat for a Company. But how does it
pose a great security threat? I mean that someone (maybe a Firewall
Administrator) should put something like (InternalNET)-(Any)-(TCP/UDP
53)-(Accept) inside the rule base. He or she could also put something
(DnsGroup) blah-blah-Accept inside the rule base. In both cases, if the
client with the AIM installed is included in there you people have a
problem. You may also have a problem if AIM can connect using a proxy server
over HTTP-HTTPS-FTP etc. But, isn't something like a best practise (or the
ONE AND ONLY DEFAULT RULE ANY-ANY-ANY-DROP-LONG) to deny both incoming and
outgoing connections when installing a firewall? Shouldn't everyone start by
denying EVERYTHING and then ACCEPTING only the ones ABSOLUTELY neccessary? I
really don;t know if the AIM client can use a proxy server to initiate a
connection and connect to the AIM servers. What I believe is that Companies,
that have allready invested $K's on security, could afford install a chat
server. Most Companies have M$ Exchange server, so they could install M$
Chat Server (I believe it is free of charge) and so they could communicate
with the remote branches all over the world using M$ Chat. This would
satisfy their need of cheap-easy-ready-to-rock communications. Needless to
say that they can configure both the Server and Firewall accept connections
from specific hosts and noone else. Companies that don't have M$ Exchange
Server could settle with something else (I don;t know what, maybe AIM Server
or something else, I guess that there are a lot of freeware or low-cost
programs out there). So what's all the commotion? What about ICMP? Should
one allow outgoing and incoming ICMP for everyone in the Corporate Domain? I
don't think so. ICMP poses another great threat for Companies. Needless to
say that ICMP is an administrative tool that it's use should be allowed ONLY
for the Administrators of a Company. Come on people, we are supposed to be
Firewall Administrators or something like that. We are not supposed to let
everything in and out of our Domains. I cannot also understand some people
letting the implied rules on. Many Admnistrators do that? How come? Are you
bored to find out what you should do to have the same functionality using
explicit rules? Is it so hard to put some rules allowing connections to the
Firewall ONLY from specific hosts (Management Server, Logging Administrator,
Firewall Engineer etc)? I don't think so. Another thing for AIM is (maybe I
am wrong though) that one could start a network monitor and capture data and
connection patterns from the AIM client. This way he or she could create a
custom service and finally block the AIM traffic itself rather than the
loggin servers for AIM. Just some thoughts I have.
P.S. I am not a Firewall or Security expert and I don't
consider myself of being one. One thing I know is that, no matter how hard
or pain the *** it is, you should start by defining
(ANY)-(ANY)-(ANY)-(DROP)-(LONG) in the rulebase, rather than
(ANY)-(ANY)-(ANY)-(ACCEPT). You can argue if you want to.
Cheers
Dimitris.
-----Original Message-----
From: Don
[mailto:[email protected]]
Sent: Wednesday, June 12, 2002 6:44 PM
To: [email protected]
Subject: Re: [FW-1] [fw-1] Instant Messenger bypass FW-1
> All stateful firewalls and packet filtering devices
will be vulnerable to
> this type of behavior
because they use information contained in the network
> (ip addresses) and transport (tcp/udp/etc) to determine whether
or not
> information should go through the
firewall. Any malicious or "slippery"
>
software will easily bypass a firewall in the outbound direction.
Only if your policy allows all outbound traffic, which it
should not.
(I do this all the time anyway... just
pointing out best practices)
> In some cases, inbound traffic is subject to this
as well. For
> instance, one piece of
software used IMCP echo replies to communicate
>
with "controlled" machines.
There is almost no
reason to allow internal machines to ping out to the
Internet in the first place. Block ICMP both ways and this is not
a
problem. Allow echo replies to a single trusted
system that you control
and can use for network
testing.
-Don