On 13 Mar 00, at 9:44, Ben Nagy wrote:
> It _is_ more efficient to pass all the things you know you're going to pass
> first - cuts down on processing time / cycles for permitted packets. As Tony
> pointed out the list is short circuited as soon as there is a match. Yes,
> you need to be careful with the ordering, but I doubt that Eric meant to
> move the rule to the very first entry in the list...
Exactly. When I was using ACLs on our system (before the
"netowork engineer" claimed that access control lists were
useless, insecure, and noone used them and removed them as
well as my access to do anything about it) it was clear that the
overwhelming majority (well over 90%) of incoming traffic was
"established". So it made sense to handle that traffic as early as
possible.
I figure that if you block the established traffic that you want to
block first and then let the permissable established traffic through,
the load on the router will be far less. But in the one presented,
they were kind of all mixed together with the established at the very
end. He must have a much faster router.
> Differences:
>
> I didn't strip spoofed traffic, because I don't really care. My hosts are
> (theoretically) hardened enough against attacks from valid IP ranges so
> spoofed packets are hardly going to hurt them. Yes, this is slightly tongue
> in cheek. If you want the extra overhead of the eight rules then go ahead -
> can't hurt.
>
> I allowed ANY established traffic to high ports. This is a potential hole.
> So, if a single forged packet can cause lots of damage to a machine running
> a high port service then I would either use reflexive ACLs or NAT - both
> have the effect of only opening holes for traffic when a packet actually
> leaves the network.
>
> I'd argue that this is _still_ more secure than having a permit base for any
> tcp gt 1023 however.
>
> I'm a lot harsher on UDP than John. I'll pick some DNS servers and stick to
> them. If anyone wants to run ICQ based apps I'll switch to reflexive ACLs or
> tell them "No".
>
> It's about 30 lines shorter. ;)
What might be worthwhile is to get the traffic for some reasonable
period and figure out the number of rules processed to handle that
traffic using different lists, and then use the equivalent rule set that
resulted in the fewest rules processed.
Looking back at the original list:
* ! block IP spoofing
*
* deny ip 10.0.0.0 0.255.255.255 any log
* deny ip 0.0.0.0 0.255.255.255 any log
* deny ip host 255.255.255.255 any log
* deny ip 127.0.0.0 0.255.255.255 any log
* deny ip 224.0.0.0 15.255.255.255 any log
* deny ip 240.0.0.0 7.255.255.255 any log
* deny ip 192.0.2.0 0.0.0.255 any log
* deny ip 169.254.0.0 0.0.255.255 any log
*
* ! block xwindows
* deny tcp any any eq 6666 log
* deny tcp any any range 6000 6100 log
* ! block other various high ports
* deny tcp any any eq 18000 log
* deny tcp any any eq 7007 log
* deny tcp any any eq 5050 log
* deny tcp any any eq 1521 log
* deny tcp any any eq 1522 log
* deny tcp any any eq 1526 log
* deny tcp any any eq 1031 log
* deny udp any any eq tftp log
* deny tcp any any eq 2049 log
* deny tcp any any eq 4045 log
* deny tcp any any eq 1030 log
* deny tcp any any eq 1032 log
* deny udp any any eq sunrpc log
* deny udp any any eq 2049 log
* deny udp any any eq 2000
* deny udp any any eq tftp
* permit tcp any any eq www
* permit tcp any any eq 22
* permit tcp any any eq ftp
* permit tcp any any eq ftp-data
* deny udp any any eq 4045 log
* deny udp any any eq syslog
* permit udp any any
* permit tcp any any gt 1023
* deny ip 192.168.0.0 0.0.255.255 any log
* permit tcp any any lt 1024 established
We could make this somewhat more efficient just by arranging the
tcp and udp separately:
* ! block xwindows
* deny tcp any any eq 6666 log
* deny tcp any any range 6000 6100 log
* ! block other various high ports
* deny tcp any any eq 18000 log
* deny tcp any any eq 7007 log
* deny tcp any any eq 5050 log
* deny tcp any any eq 1521 log
* deny tcp any any eq 1522 log
* deny tcp any any eq 1526 log
* deny tcp any any eq 1031 log
* deny tcp any any eq 2049 log
* deny tcp any any eq 4045 log
* deny tcp any any eq 1030 log
* deny tcp any any eq 1032 log
* permit tcp any any eq www
* permit tcp any any eq 22
* permit tcp any any eq ftp
* permit tcp any any eq ftp-data
* permit tcp any any gt 1023
* deny ip 192.168.0.0 0.0.255.255 any log
* permit tcp any any lt 1024 established
* deny udp any any eq tftp log
* deny udp any any eq sunrpc log
* deny udp any any eq 2049 log
* deny udp any any eq 2000
* deny udp any any eq tftp
* deny udp any any eq 4045 log
* deny udp any any eq syslog
* permit udp any any
Depending on the specific mix of udp vs tcp, it could easily make
sense to put the upd blocks first.
By the way, from the Cisco documentation concerning the
"established" keyword:
For the TCP protocol only: Indicates an established
connection. A match occurs if the TCP datagram has the
ACK or RST bits set. The nonmatching case is that of the
initial TCP datagram to form a connection.
What would happen if an attacker set the ACK or RST bits in the
datagram to get the packet passed through as "established"?
After the router passes it through, what will the server do with the
packet?
-------------------
Eric Johnson
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
