|
Another thing is (I'm maybe wrong though) that you can even deny the
use of programs with "tunneling capabilities if you define a URI resource
permiting HTTP, HTTPS, FTP traffic. The catch is that IMHO you MUST define the
methods that can be used (GET, PUT, POST, HEAD etc). I think that if you declare
that ONLY GET is allowed, the programs with tunneling capabilities will be
worthless. Just a thought I had. I will try it and inform you the time I have
the results.
The
rulebase should look like:
1.
(ProxyServer)-(ANY)-(Http->BlockDownloadsHttp)-(DROP)-(Long)
2.
(ProxyServer)-(ANY)-(Http->PermitedBrowsing)-(ACCEPT)-(Long)
3.
(ProxyServer)-(ANY)-(ANY)-(DROP)-(Long)
1.
Name: BlockDownloadsHttp
Comment: BlockDownloadsHttp
Connection Methods: Transparent (Assumes that users browse using an
Internal Proxy Server)
URI
Match Specification Type: Wild Cards
Exception Track: Log
Schemes: http
Methods: All, Others: *
Host: *
Path:
{*/*.{exe,zip,bin,mp*,avi,dat,ra*,rm*,asx,gz*,tar,ace,cmd,com,cpl,ins,isp,pif,reg,scr,rpm,wav,eml,iso,lha,bh,par,ocx,cab},*.{exe,zip,bin,mp*,avi,dat,ra*,rm*,asx,gz*,tar,ace,cmd,com,cpl,ins,isp,pif,reg,scr,rpm,wav,eml,iso,lha,bh,par,ocx,cab}}
Query: *
Replacement Uri: http://www.myInternalWebServer/ITPolicy.htm (the
.htm file stating what users should do and should not explaining the reasons
why. No threatening, no bulling around, no "It's the law, my way or the
highway").
HTML
Weeding: none
Response Scanning: none
CVP:
none
2.
Name: PermitedBrowsing
Comment: PermitedBrowsing
Connection Methods: Transparent (Assumes that
users browse using an Internal Proxy Server)
URI
Match Specification Type: Wild Cards
Exception Track: Log
Schemes: http
Methods: GET, POST, HEAD, PUT, Others: blank
Host: *
Path: *
Query: *
Replacement Uri: blank
HTML
Weeding: none
Response Scanning: none
CVP:
none
3. I think it is obvious why.
I believe that once you define the above you
will not have to be afraid of programs with "tunneling" capabilities. I'll try
it and let you know.
I also like what Joe Pampel wrote. I quote
"one view of the world... Our environment is very demanding (Wall
St) and so we have taken great pains to create a stable build for our
workstations. They run for months w/o a reboot which I'm very happy about.. From
the POV of keeping the machines "flat" as well as security everyone knows not to
DL anything. The net result of this is that our staff works efficiently and
without the frustration of machine instability and reboots. If folks want/need
something extra on their desktops that will help them out, they can always come
and ask. There is no reason IMHO for end users to be installing stuff ad hoc on
their workstations. They need to understand that. Everyone here does, and it's
not a "control freak" or "keep them down" thing.. it's simply letting each group
of people do the best job they can and trusting one another. Everyone is cool
about it. I don't know if it would hold up at a big firm (we're small, <100)
but explaining what's up to everyone rather than just putting in dracronian
rules and sending out a memo stating "because I said so".. has worked well.
Bottom line for me is that the box belongs to the firm, with everything on it.
Part of my job is deciding what goes on it. I am paid for my "expertise" (such
as it is!) in assessing what products will work well together, be secure, and
most importantly - solve our business problem. I use a lot of end user
input/feedback to determine the last bit so it is as participative as possible.
I don't play with the accounting rules or dabble in marketing.. Why would
someone without the expertise need to alter a machine that our IT dept has
spec'd and built, and potentially put others in the firm at risk?". This is also
what I wanted to point out. I 100% afree with Joe Pampel. If and only if
everyone understands what the threats are, an environment can be secured (but
never 100%).
Cheers,
Dimitris.
What i said is that you only permit for a group of people or for
specific servers/workstations etc not the entire domain. If you permit for the
entire domain you have no firewall installed. I am also aware of what ICMP is
capable of. I only mentioned ICMP because most people think that it has to do
only with "ping". What I really had in mind is that (and this goes for ALL
services) ICMP should only be permited for specific servers/workstations and
that only if it is really needed. Everything permited MUST be permited for
specific people/groups/servers/workstations etc NOT for everyone in the
Domain. Unless you follow this you have no security whatsoever, you have just
a box that is supposed to be a firewall. I know that it is a pain in the ***
to configure the firewall having in mind the "10 immutable laws of security".
Even if you install the perfect rule base you could be subjective to other
security threats eg. if you install a Proxy server, giving access to the
Internet to the Proxy server itself, and you don't configure the Proxy server
be utilized by specific users only, you have a BIG problem. Even if you do
that you should regularly check the workstations allowed to go to the internet
through the Proxy server to find out whether they have downloaded programs
with "tunneling" capabilities or not. You should also check these workstations
for non-legit applications. Needless to day that you should create a URI
resource containing forbiden file extensions for those going out to the
Internet using the Proxy server. I know that configuring a firewall the
"secure" way has become something like a "Science", not to mention Information
Systems Security in general, BUT unless you configure it the "Secure" way you
have no firewall. This is what I believe. I am maybe wrong, but think about
it. Only permit the services you have to, for specific
Workstations/servers/users/groups, and for specifies
hours.
Cheers,
Dimitris.
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
|
