Re: using router's ACL to substitute firewall

• Previous message: Walter Roberson: "Re: using router's ACL to substitute firewall"
• In reply to: Walter Roberson: "Re: using router's ACL to substitute firewall"
• Next in thread: Doug Fox: "Re: using router's ACL to substitute firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Doug Fox" <dfox168@hotmail.com>
Date: Sat, 19 Apr 2003 15:18:31 GMT

Walter;

Many many thanks!

Regards;

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:b7qn46$99s$1@canopus.cc.umanitoba.ca...
> In article <J2_na.64775$BQi.58087@news04.bloor.is.net.cable.rogers.com>,
> Doug Fox <dfox168@hotmail.com> wrote:
> :Due to financial constrains, a network guy proposes to use Cisco router's
> :ACL to secure the network, instead of using a firewall. He commented
that
> :the ACL can restrict IP addresses and (service) ports. Not being
familiar
> :with functionality of a router, any comments/suggestions are appreciated.
>
> He is correct that you can do that, but it has some drawbacks.
>
> When you use just ACLs to do filtering, then the filtering
> is "stateless", so you have to permit responses to any port number
> that *might* be the source of traffic, and you have to permit
> new connections to any port number that *might* ever act as a server
> in some way.
>
>
> You can handle TCP responses with a statement such as
>
> access list 102 permit tcp any any established
>
> which allows through TCP packets that do NOT have the SYN flag
> set (except that the SYN ACK combination is allowed.) This
> is effective unless you happen to have a trojan inside that
> is listening in promiscuous mode against the possibility
> that it might be sent control packets "out of the blue" that
> don't have SYN set [e.g., a crafted packet instead of a normal
> TCP connect() sequence.]
>
>
> Unfortunately, UDP has no notion of "response", so if your inside
> systems have any programs that dynamically allocate UDP source
> ports, you have to permit UDP to any valid dynamic port:
>
> access-list 102 permit udp any any gt 1023
>
> It's pretty common for there to be programs running with UDP ports
> above 1023, so you either need to block most UDP and tell users
> "Sorry, you just can't run these programs", or else you have to
> put in internal firewall software on each of the hosts. Oh yes,
> and of course it's pretty common for NETBIOS to send out
> packets with a UDP source port of 137, so if your applications
> need to talk via NETBIOS, You Have A Problem.
>
>
> For incoming connections, UDP is again a problem, in that UDP
> cannot tell new connections from responses.
>
>
> Incoming TCP connections can be more of a problem than you first think.
> There are the obvious ports such as 80 and 25 and 23, but if you use
> streaming media or standard FTP, then even when your users are
> connecting outgoing, the protocols used require that your hosts accept
> incoming connections on a dynamic port whose port number is sent to the
> remote machine. For FTP, PASV (passive) helps; if you don't enforce
> passive but you allow people to download files via FTP (e.g., including
> via ftp:// URLs), then you end up having to
>
> access-list 102 permit tcp any any gt 1023
>
>
> In short, you can, for the most part, make do with just access-lists
> if you are very careful and are willing to be very restrictive
> about what kind of traffic is allowed. Unless, that is,
> that you have a need to run networked Microsoft applications
> [e.g., you have peered Exchange servers], in which case you should
> be utterly unhappy about the idea of running them without
> a true "stateful" firewall.
> --
> Those were borogoves and the momerathsoutgrabe completely mimsy.

• Previous message: Walter Roberson: "Re: using router's ACL to substitute firewall"
• In reply to: Walter Roberson: "Re: using router's ACL to substitute firewall"
• Next in thread: Doug Fox: "Re: using router's ACL to substitute firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]