Allan Leinwand wrote:
> Hi Tony,
>
> Thanks for the comments and the detailed response - I'll definitely make sure
> your comments are read by our documentation people.
>
> Back to the topic, after reading your reply a few times I'm not sure that we
> are saying different things. I don't know what a Cisco "responder list" is,
> but after your first email on this topic I assumed, perhaps incorrectly, that
> this was a marketing term for an IOS extended access-list for TCP that uses
> the "established" keyword.
>
> Using the Vyatta system, I've set up my firewall to behave as you describe -
> I only permit TCP sessions inbound on my Internet port (eth0) that origin
> from another LAN interface. Here's a config snipet:
>
> ethernet eth0 {
> firewall {
> in {
> name: "internet"
> }
>
> [...snip...]
>
> firewall {
> name internet {
> rule 1 {
> protocol: "tcp"
> state {
> established: "enable"
> }
> action: "accept"
> source {
> network: 0.0.0.0/0
> }
> destination {
> network: 10.X.X.X/16
> }
> }
>
> If I remove all other firewall rules from my eth0 (which is the LAN to my
> Internet provider) I can still establish TCP sessions outbound, but no
> inbound sessions are allowed. I hope this is useful.
>
That is exactly what I was talking about and what I did
in mine set-up also. And as I said to 'punch holes' through
the firewall you now need to specified the port and use the
state of 'new', which will allow new connections through the
punched hole.
As for if 'reflextive access lists' *(what I have been calling
as 'reflector' lists) is marketing speak or not, well
when I was setting up my Cisco-806 for here at the home I found
the information about reflextive access lists in the O'Reilly
book "Cisco IOS in a Nutshell" by James Boney on page 92.
<quote (without permission)>
Reflexive access lists are an important tool added to IOS 11.3
and its successors. They allow you to create lists that
dynamically change based on what services your users need.
Basically, you create an inbound and an outbound access list.
The outbound access lists creates entries in a temporary access
list. To put it another way, packets going out the interface
create temporary entries to allow packets of the same session
back in. When an outbound session ends, the temporary entries
are destroyed, which closes the hole in the inbound access list.
Reflexive list are similar to extended TCP access list with the
established keyword in the you will usually use reflexive list
to allow communications that have been initiated by your users.
As I explained earlier, established connections rely on two bits
(ACK and RST) being set in the incoming packet.
<highlighted by me>
While the established keyword works, it presents two problems.
First, someone attempting to crack your site can exploit the
established assumption by illegitimately setting the ACK and RST
bit in a packet that doesn't belong to an established session,
tricking the router into thinking the packet is legitimate.
Second, the system is always open for attacks, even if no
outbound sessions are in progress. With reflexive list,
however we open the entry in the inbound access list only for
valid current sessions.
</highlighted>
</quote>
So now the question comes down does OFR fully support the
'reflexive' list or is it only able to support the 'extended
TCP access list with the established keyword' as described
above. It would be best to be able to support the 'reflexive'
style.
And if currently OFR does not support the reflexive style
how long will it be before this feature can be added which
would being OFR and IOS closer together?
Tony
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
