Sorry for the late reply everyone. Been out of town for a while. I will try to summarize a few answers for this thread into one email. Hope it's clear.
Vyatta uses iptables/netfilter for our firewall implementation. For discussion refer to the following diagram... This is pulled from section 3.2 of the Linux Netfilter Hacking HOWTO. http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html --->PRE------>[ROUTE]--->FWD---------->POST------> Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter This diagram shows the order of netfilter hooks and what actions happen in each one. For example, in the NF_IP_PRE_ROUTING hook, all conntrack functions take place followed by mangle and dest NAT. Iptables allows the user to populate the input (NF_IP_LOCAL_IN hook), output (NF_IP_LOCAL_OUT), and forward (NF_IP_FORWARD) filter tables. In Vyatta, an in firewall populates the forward table with --in-interface implicitly added to the rules. An out firewall populates the forward table with an implicit --out-interface added to the rules. A local firewall populates the in table. We can see from this diagram that dest NAT happens before filtering and source NAT happens after filtering for traffic forwarded through the device. Also, NAT and firewall rules are connected to completely different netfilter hooks in the kernel (for forwarding). Specifying a NAT rule will not open any ports on the firewall. AFAIK, reflexive access lists were implemented in Cisco IOS because ACLs are not stateful. So if I have an ACl like "access-list 101 permit tcp any 10.0.0.0 0.0.0.255 established" I can get through the filter by sending packets with the headers faked to look like an established session because the router has no way to associate this session with a real outbound one. It simply trusts the packet when the packet tells it that it is part of an established session. This usually means the host will respond to the spoofed packet in some way and that allows me to gather information about the host like system type, services running, etc. (Or I can DOS you.) However, if the user implements a reflexive list, when an outbound packet is sent from the LAN a corresponding inbound ACL is dynamically created on the port. This means I don't have to use an established rule. The system is then not open to the world, only the IPs that the outbound requests were sent to. Using the established keyword in Vyatta turns the firewall into a stateful firewall. When an outbound request is sent from the LAN, a conntrack entry is created that tracks all further packets associated with that flow both inbound and outbound. When a spoofed packet comes in from the Internet a lookup is done in that conntrack table. If there is no existing session the packet is dropped. If you setup your filter as described by Allan, your LAN is protected from spoofed packets. Stateful filtering does away with the need for reflexive lists. Either way, reflexive or stateful, to allow sessions initiated from outside your network you have to punch holes in the firewall. Both reflexive and stateful require an outbound session before a hole is opened. So if you want to provide services (http, ssh, ftp, etc.) you have to explicitly open the associated ports so the initial session packets can reach your server. This is where your tcp/new filter comes in. So in the case of the border router, I would apply an in filter to my WAN interface that first permits established. Then if I were providing services, http for example, I would open up port 80/new. Continue to add services as required. Hope that helps. Cheers, Robert. Allan Leinwand wrote: > Hi Tony, > > Thanks for the clarification. I have definitely heard of reflexive > access-lists in IOS :) > > I'm not an expert on iptables, but what you say makes sense when > considering a DoS SYN attack. That being said, I'm not entirely sure if we > can do exactly what this IOS feature can do, but I do know we can rate limit > TCP SYN handling with the "syn-cookies enable" command. Maybe Robert can save > me from myself here - ummm... Robert? > > You can vote for new features at > http://www.vyatta.com/twiki/bin/view/Community/TopEnhancements and we always > take time to review this community input regularly. > > Take care, > > allan > > ----- Original Message ----- > From: "Tony Cratz" <[EMAIL PROTECTED]> > To: "Allan Leinwand" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Sent: Thursday, October 4, 2007 5:59:59 PM (GMT-0800) America/Los_Angeles > Subject: Re: [Vyatta-users] How firewalls work using Vyatta OFR > > 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 _______________________________________________ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
