> -----Original Message-----
> From: Steve Birnbaum [SMTP:sbirn @
security .
org .
il]
> Sent: den 4 februari 1998 11:03
> To: Robert Ståhlbrand
> Cc: 'Marek Kubita'; 'firewalls @
greatcircle .
com'
> Subject: Re: FW-1 and FIN scanning (was: nmap tool)
>
>
>
> robert .
stahlbrand @
nmac .
ericsson .
se said:
> > And when I think I don't understand why the connection would close.
> I
> > can unplug my wire for an hour and when I attach it again my
> > telnet-session (for example) is not closed (unless you hit a key
> while
>
> Unlike a packet filter where you generally allow all established
> traffic,
> Firewall-1 keeps a state table of open connections and dynamically
> allows
> only the required established traffic. My understanding is that
> re-installing the policy clears the state table. Therefore, you'd
> have to
> send out a new SYN in order for it to add a new entry to the state
> table
> if it didn't have some way to dynamically re-add running sessions.
>
> [Robert Ståhlbrand]
> That is one of the strength with Checkpoint 8-) (not allowing
> established packets as a general).
> What you say is that Checkpoint caches all the current connections and
> when you clear the state table reestablish the connections. Is this
> done with a new SYN-packet? Not very likely is it? How would you do
> that? Shall the firewall send out the SYN-packet to the
> destination-address with the initiators ip-address. That is spoofing
> and how should the initiator know that the firewall has sent out this
> packet and accept the SYN,ACK he recieves back? This won't work and
> you cannot force the initiator to resend a SYN-packet without loosing
> the current connection (or force him at all).
> If think this is done with a cache with all current connections. When
> you clear the table (installing a policy) he just puts this cache
> somewhere and after it has been installed lifting the cache back in
> the system. Why should you put in more effort?
>
> If I'm wrong here please describe the progress!
>
> I still don't see the connection between dropping packets and
> reestablishing connections and why only with dropping packets rules
> you can pass a not established connection???
>
>
> However, I agree that this behaviour is not well known and I would
> personally rather see sessions lost than allow the ability to scan the
> network. The least that could be done is to make this an option,
> disabled
> by default, with a nice red friendly warning that pops up when you try
> to
> enable it.
>
> I am, however concerned about your statement that data is passing
> through.
> Hopefully this behaviour is unique to pre-version 3.
> [Robert Ståhlbrand]
>
> We will recieve an answer on that pretty soon, I assume from Marek
> Kubita?
>
> Steve
>
> --
> sbirn @
security .
org .
il Phone: +972-2-6795860 (PGP key available)
> Fight Internet Spam! http://www.vix.com/spam/ Disclaimer: My
> opinions only.
>
> << File: ATT00173.ATT >>
> [Robert Ståhlbrand]
>
> /Robert Ståhlbrand, Ericsson Telecom AB
Follow-Ups:
|
|
