RE: [FW1] Inbound, outbound, or eitherbound?

[Little, Craig (SSI-SIAP-NP5)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As I said, that was an abridged list of rules (so as not to confuse
too much). Firstly though, there is no NetBIOS on our firewall.
NetBIOS itself has been uninstalled, as has the TCP/IP NetBIOS
helper, WINS etc.

I do have two rules to prevent the logging of 'noise' though. They
are:

Any  broadcast-addresses  any    drop  (no logging)
Any  Any                  Noise  drop  (no logging)

The broadcast-addresses object is a group which contains commonly
seen broadcast addresses for each subnet connected to the firewall.
The Noise object is a group of services which includes bootp, ident,
NBT, rip and rip-response.

Before people start saying 'you should reject ident, not drop it', my
response is I just don't want to see it.

Craig.

> -----Original Message-----
> From: Reed Mohn, Anders [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 17 August 2000 7:42 p.m.
> To: Little, Craig (SSI-SIAP-NP5)
> Subject: RE: [FW1] Inbound, outbound, or eitherbound?
> 
> 
> 
> As far as I can see from you little list of rules, you're logging
> all those bloody annyoing "nbname" and "nbdatagram" 
> broadcasts from the
> FW 
> itself. Unless you have some other way getting rid of them....
> We run a small system with low traffic, and all these broadcasts
> make up a proportionally very large part of our logs.
> Any hint you could give me about getting rid of it?
> I've already turned the "MaintainServerList" off in NT, but I 
> suppose there is mor I could do to it?
> In tried setting up NT to "hide" from browser lists, but this
> didn't help much.
> 
> Cheers,
> Anders :)
> 
> > -----Original Message-----
> > From: Little, Craig (SSI-SIAP-NP5)
> > [mailto:[EMAIL PROTECTED]] Sent: 17. august 2000 03:45
> > To: [EMAIL PROTECTED]
> > Subject: RE: [FW1] Inbound, outbound, or eitherbound?
> > 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Refer: VPN-1/FireWall-1 Administration Guide * January 2000
> > 
> > pp. 238-241 - Properties Setup - Security Policy
> > p. 625 - How is a Security Policy enforced on a host's different
> > interfaces?
> > 
> > WRT not trusting an administrator on the Firewall - none of our
> > firewalls are used for anything but firewalls. I.e. no DNS, no
> > SMTP, no Web etc. You'll be amazed at what I've seen some
> > Firewalls used for. They are inspection stations only. There is
> > no need to 
> be on the
> > Firewall, except to perform maintenance (new SP, changes to 
> proxy ARP
> > etc.). Some people allow a web browser to be installed on the
> > firewall to perform service pack downloads etc. I insist on
> > downloading separately and burning to CD-ROM, otherwise you are
> > asking for trouble.
> > 
> > The only account defined for the server is the super-user, and
> > only one person knows it (and I think I trust myself!). The
> > latest
> > password is written down and stored in a safe for emergency use.
> > Policy states that no one can make changes to the firewall alone
> > - another qualified (CCSA minimum) person must be present during
> > any configuration changes. 
> > 
> > The management console, reporting and intrusion detection 
> are all run
> > from other machines, so there is no need for the firewall 
> to send out
> > unsolicited IP. For this reason, I have defined the following
> > rules to keep things tight and report unauthorised accesses
> > (simplified slightly):
> > 
> >    Src     Dst     Svc     Action    Track
> > 1. EncDom1 EncDom2 Any     Encrypt   Account
> > 2. EncDom2 EncDom1 Any     Encrypt   Account
> > 3. FW1     FW2     IPSEC   Accept    Log
> >    FW2     Fw1
> > 4. FW1     Mgmt    FW1     Accept    Log
> >    FW2             FW1_log
> > 5. Mgmt    FW1     FW1     Accept    Log
> >            FW2     FW1_log
> > 6. FW1     Any     Any     Reject    Log
> >    FW2
> > 
> > Kind Regards,
> > 
> > Craig Little  BSc, CPD, CPI, SCJP, CCSA, CCSE
> > Inter-Networking / Security Consultant
> > 
> > Shell Services International
> > 
> > Phone:              +64 4 462 4661
> > Fax:                +64 4 463 4060
> > Mobile:     +64 21 37 5858
> > mailto:[EMAIL PROTECTED]
> > http://www.shellservices.com
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Frank Knobbe [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, 17 August 2000 7:26 a.m.
> > > To: 'Carric Dooley'; [EMAIL PROTECTED]
> > > Subject: RE: [FW1] Inbound, outbound, or eitherbound?
> > > 
> > > 
> > > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Hmmm... I just read again in the FW-1 manual following on
> > > Accept Outgoing Packets:
> > > 
> > > Accept Outgoing Packets - Accept all outgoing packets (from the
> > > Firewall, not from the internal network).
> > > 
> > > On gateways, rules are usually enforced in the inbound
> > > direction only. When a packet passing through the gateway
> > > leaves 
> the gateway,
> > > it will be allowed to pass only if one of the following
> > > conditions is true:
> > > 
> > > * The Accept Outgoing Packets property is checked.
> > > * Rules are enforced both directions (eitherbound), and there
> > > is a rule which allowed the packet to leave the gateway.
> > > 
> > > Then it references the drawing and addtl information in the
> > > Architecture manual, which basically states what you have
> > > written.  
> > > 
> > > Given that, am I the only one feeling uncomfortable with
> > > Inbound only since packets originating from the firewall to the
> > > outside would go unchecked? Assuming that usually (!) nothing
> > > is 
> running on
> > > the
> > > firewall and no user is working on it, there are still 
> packets that
> > > the FW itself creates and sends out, as in authentication and
> > > VPN traffic. Wouldn't it be possible for exploits to go 
> unnoticed if no
> > > rules has been set to monitor/filter outgoing data? In order to
> > > enforce those rules, Eitherbound would need to be selected.
> > > 
> > > Am I just too paranoid, or does anyone else think it might be a
> > > good idea to keep an eye on traffic leaving the firewall, 
> and hence
> > > use Eitherbound?
> > > 
> > > Regards,
> > > Frank
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Carric Dooley [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, August 14, 2000 12:46 PM
> > > > To: Frank Knobbe; 'Padden, Greg';
> > > > [EMAIL PROTECTED]
> > > > Subject: Re: [FW1] Inbound, outbound, or eitherbound?
> > > > 
> > > > 
> > > > My understanding of eitherbound is on which interface the 
> > > > policy is applied
> > > > to the traffic.... example:
> > > > 
> > > > If you have IF_A as your internal  interface, and IF_B as 
> > > > your external, if
> > > > you set your policy for "Inbound", packets coming from the 
> > > > public network
> > > > would be filtered at IF_B (the inbound interface for that 
> > > > direction).  An
> > > > outbound policy would evaluate the traffic from the outside 
> > > > at IF_A as the
> > > > traffic leaves the firewall.  "Eitherbound" means the packets
> > > >  have to pass
> > > > through the policy at BOTH interfaces doubling the amount of 
> > > > work for the
> > > > firewall (at least from policy perspective) for each packet. 
> > > >  This is the
> > > > most secure, but if you are pushing a lot of traffic, not 
> > > > ideal.  I would
> > > > typically set that property for "inbound" myself.  If you set
> > > > it for "outbound" a DoS (from the outside) would affect 
> the firewall
> > > >  itself because the traffic is not analyzed until it hits the
> > > > internal  interface (IF_A). Eitherbound is overkill in a lot
> > > > of situations, but inbound  means if someone attacks the
> > > > firewall, it has to make it through the policy,  and the same
> > > > would apply for traffic from the internal network out 
> > > > (evaluated before it passes through the firewall). 
> > > 
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: PGP Personal Privacy 6.5.1
> > > Comment: PGP or S/MIME (X.509) encrypted email preferred.
> > > 
> > > iQA/AwUBOZrqzkRKym0LjhFcEQIakACg2WyHMepBcqrB4Nz5+m0tXSrli1UAoMap
> > > H4SH0xOKQTKmXy3b/5uNcx/Q
> > > =WHGk
> > > -----END PGP SIGNATURE-----
> > > 
> > > 
> > > ==============================================================
> > > ==================
> > >      To unsubscribe from this mailing list, please see the 
> > > instructions at
> > >                http://www.checkpoint.com/services/mailing.html
> > > ==============================================================
> > > ==================
> > > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.5.3 for non-commercial use 
<http://www.pgp.com>
> 
> iQA/AwUBOZqZzMkKSVawnurJEQJbYACgiNq/srmBeIygWxsBo+47Hkk8L88AnAuR
> GvxWuFenRucuNFKG/3aI0xPx
> =NSfS
> -----END PGP SIGNATURE-----
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOZuwOMkKSVawnurJEQI6GQCdHMMOhAMPMoT9mkLUe5RqJaR1LbMAn3kF
Im7DXV3NuyCgwBlE9OAqXhi2
=icNB
-----END PGP SIGNATURE-----


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================