Title: RE: Port 135 and Firewall-1

First Off Remember this:
Port 135 is BAD!

Volker's comments are very good and I just wanted to add one thing to them.
I'm assuming that you are running MS Exchange, so access to port 135 is needed for the Outlook client to connect correctly. I'm assuming that you have remote employees that also need to access their email when not in the office. I have the same setup and a good way to protect you network is to use the Secure Remote client.

SR allows you to create a VPN connection to your firewall and treat these roaming machines as internal hosts. By doing things this way you don't open up 135 to the unauthenticated (the outside world!). The main problem with this is that you need to lock down these client pc's. If not you open the network to mischief from the other end of the VPN, thereby negating all your work! Play around with the SR client from Checkpoint it's free just cal your Checkpoint reseller. Make sure that you apply stringent rules to the Secure Remote users because they can be a liability, although security is a balancing act for risk so everything is a liability.

If you would like more info on how to get Secure Remote working contact me off-list or check out www.checkpoint.com and www.phoneboy.com

If you're using FW1 and haven't been to phoneboy yet go there!

Hope this helps,
Mike

-----Original Message-----
From: Volker Tanger [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 4:52 AM
To: Warren van Eyssen
Cc: Firewalls (E-mail) (E-mail)
Subject: Re: Port 135 and Firewall-1
Importance: High


Greetings!

Warren van Eyssen schrieb:

> Can anybody tell me if their is any danger with the following log entry on a
> firewall-1 server?
>
> Action  Port    Source                  Destination     Proto.
> > accept        135     c7-ndf-77.dail-up.net   mail server     tcp

First a general answer:  firewall rules MUST be documented. Non-documented rules
should be disabled immediately.
The reason behind this rule is that each rule punches a hole through the FW -
and this risk has to be shouldered by
some manager (it's HIS head that should roll in case of problems - not the
administrator's). Short: no access until there is a business need AND some
manager signing responsible for use and misuse of that specific protocol. And
before opening a protocol there should be a risk assessment so the manager can
weigh risk and achievement.

Specifically: your MS-Exchange server is WIDE open to that dial-up number -
maybe even to all internet addresses. It seems you allow MS-RPC thus full access
(network-layerish) to server remote control and MS Exchange. If you can not
verify 280% that this was one of your administrators, chances are good that your
system already has been compromized. Check your MS-Exchange server thoroughly
(file through every directory and the registry - manually!) - and at the
slightest sign of intrusion or compromize back up the data and re-install your
system from scratch. If so, check your NT domain controllers which have trust
relationship to the Exchange system (and vice-versa). If there are signs, back
up the data and re-install from scratch. As it is quite possible that user
accounts were compromized even if you do not find indicators for a full
break-in, verify each and every user account on the local server(s) and for the
NT-Domain to belong to an employee and force a password change.

Do NOT put the MS-Exchange server back to internet without verifying that the
network access to that system is limited to the ports you have (signed!)
management clearance for. Make sure your system has all current SPs and hotfixes
installed - and keep it current.

Sorry
    Volker

--

Volker Tanger  <[EMAIL PROTECTED]>
 Wrangelstr. 100, 10997 Berlin, Germany
    DiSCON GmbH - Internet Solutions
         http://www.discon.de/


_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls

Reply via email to