Perimemter Router Security

bfrericks · ‎09-18-2007

Hello,

I am looking for some information on what I should consider doing on my perimeter router that conencts me to an ISP. The rotuer links to a ASA 5510. Other than the usual spoofing ACL's what other ACL's should I consider? All outbound traffic will be allowed and I was considering blocking all inbound at the router accept for the pinholes we have allowed through our firewall (eg. SMTP, ICA, HTTP/S) Another question, if I apaply this ACL in the inbound direction, will the return traffic still be allowed? My understanding is that because a router ACL is not "stateful" (we will not have the firewall feature set) that the return traffic would be blocked by the inbound ACL.

Any information or help would be very much appreciated.

Jon Marshall · ‎09-18-2007

Hi

There are a wealth of articles on this subject at the SANS website. Attached is a link to the section at SANS concerned with securing network devices including Cisco routers.

http://www.sans.org/reading_room/whitepapers/networkdevs/?portal=ee581c9581dd65a1d8cabe372ad73986

On a more general note the idea of allowing only the same ports as your firewall allows is not necessarily a good idea because

1) routers primary function is to route. You do not want to overload the router with acl checking when you have a dedicated firewall to do the job.

There are basic acls you can implemen such as filtering RFC addresses which you mention above and these are fine.

2) By using the router to filter all traffic you can lose visibility of what is trying to access your network. A lot depends on where/if you deploy IPS/IDS but again firewalls have very good logging facilities for this sort of thing.

As for the return traffic. You are correct in what you say in that an acl is not stateful but if you apply an acl inbound on the outside interface of your router, because it is not stateful, it will only have an effect on traffic coming from the Internet. The router has no concept of "return" traffic. Only an access-list applied inbound on the inside interface or an access-list applied outbound on the outside interface could affect return traffic.

HTH

Jon

Jon Marshall · ‎09-20-2007

Hi

That last point regarding the access-list should have been explained differently as it is a little misleading.

i was explaining the return traffic from a connection initiated from the outside to the inside but i omitted to mention the effect an acl applied inbound on the outside interface can have an return traffic from the internet.

An acl applied inbound on the outside interface will affect traffic initiated from the outside to the inside but it will also affect return traffic that has been initiated from the inside for precisely the reason you say, it is not stateful. You can look at reflexive access-lists which may be of help.

Apologies if i misled you.

Jon

jamie.sobczyk · ‎09-28-2007

Have you tried the [established] flag on the inbound ACL?

example:

ip access-list extended sample-acl

permit tcp 10.99.54.0 255.255.255.0 any established

This should allow any TCP traffic that was initiated from the inside of your network to be permitted back inside.

treebug00 · ‎10-23-2007

what about udp traffic? say you have a range of udp that you need to use for outbound connections such as video/voice. Do you have to allow that whole range of udp inbound access? Will the connection be dropped if there is no matching source/dest port/address?

tdistlists · ‎10-24-2007

For voice/video traffic, an ACL will never suffice, because of the whole dynamic port scenario. You cannot just open 30,000 UDP ports because video might choose one of them.

Different protocols behave differently when traversing a FW/NAT device. That is why they have ALGs for SIP or H.323 for instance. This layer-7 inspection will not only create the necessary pinholes (for return traffic) but it will alter the payloads with the correct NATed IPs.

Some apps, such as skype, use a central-server, or non-natted supernode, to connect two users behind FWs, via sewing two connections together. That is why skype works without much intervention. However, something like ichat AV, which uses a proprietary spin on SIP, will usually fail to traverse a FW without proper ALG configuration. Other apps use UDP-hole-punching to find an opening in your FW, by forcing an inside client to make an outbound connection, and therefore allowing the admin not to open 30,000 UDP RTP ports.

Other video, like cisco's tandberg or, polycom video, work differently... but still often fail to work without a layer-7 approach. Encrypting phone and video calls throw another wrench into the mix, and that's why ASA v8.0 will allow decryption of voice signalling.

Something like the SBC (session border controller, if I recall correctly) is better suited to protect the enterprise while allowing for incoming requests, because it acts like a proxy for all calls. However, we have to wait for Cisco to come out with a hardware accelerated version.

Not sure if I answered your question, but yes, an incoming connection will be dropped if there is no session in the session table. The problem is not only with policy, however, but with translation.