RE: PIX Question

• Previous message: David Lubowa: "RE: Locking Cisco Router"
• In reply to: jamesworld@intelligencia.com: "RE: PIX Question"
• Next in thread: Stephen Wilcox: "RE: PIX Question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Stephen Wilcox" <stephenwilcox@universalcomputersys.com>
To: <jamesworld@intelligencia.com>
Date: Mon, 18 Nov 2002 11:08:55 -0600

James,

You would be more familiar in the PIX an I am and I agree with what you had
to say on the locking down a router and yes the firewall will block internal
address from propagating to the public side... It's just a recommendation
for creating a safe infrastructure. With out some sort of filtering on the
edge router you will still leave yourself open to certain attacks. Though
you can not prevent all attacks, preventive actions should still be
deployed.

Like you said, take care of you body... you still need to exercise, take
vids and eat right, right :)

Here is the advice that Cisco give in deploying a medium network edge router
and firewall.

Edge Router

The function of the edge router on the medium network is to provide the
demarcation point between the ISP network and
the medium network. At the ingress of the edge router on the medium network,
basic filtering limits access to allow only
expected IP traffic, providing a coarse filter for the most basic attacks.
RFC 1918 and RFC 2827 filtering is also provided
here as a verification of the ISP's filtering.

In addition, because of the enormous security threat that they create, the
router is configured to drop most fragmented packets that should not
generally be seen for standard traffic types on the Internet. Any legitimate
traffic lost because of this filtering is considered acceptable when
compared to the risk of allowing such traffic.

Finally, any IPSec traffic destined for the VPN concentrator or the firewall
is allowed through. Filtering on the router is
configured to allow only IKE and IPSec traffic to reach the VPN concentrator
or firewall. Because with remote access VPNs
the IP address of the remote system is not generally known, the filtering
can be specified only to the headend peer (VPN
concentrator) with which the remote users are communicating. With
site-to-site VPNs, the IP address of the remote site is
usually known; therefore, filtering may be specified for VPN traffic to and
from both peers.

Firewall

The primary function of the firewall is to provide connection-state
enforcement and detailed filtering for sessions initiated
through the firewall. The firewall also acts as a termination point for
site-to-site IPSec VPN tunnels for both remote site
production and remote site management traffic. There are multiple segments
off the firewall. The first is the public services
segment, which contains all the publicly adressable hosts. The second is for
remote access VPN and dial-in, which is iscussed later. Publicly addressable
servers have some protection against TCP SYN floods through mechanisms such
as the use of half-open connection limits on the firewall. From a filtering
standpoint, in addition to limiting traffic on the public services
segment to relevant addresses and ports, filtering in the opposite direction
also occurs. If an attack compromises one of the
public servers (by circumventing the firewall, HIDS, and NIDS), that server
should not be able to further attack the network.
To mitigate against this type of attack, specific filtering prevents any
unauthorized requests from being generated by the
public servers to any other location. As an example, the Web server should
be filtered so that it cannot originate requests of its own, but merely
respond to requests from clients. This setup helps prevent a hacker from
downloading additional utilities to the compromised box after the initial
attack. It also helps stop unwanted sessions from being triggered by the
hacker during the primary attack. An attack that generates an xterm from the
Web server through the firewall to the hacker's
machine is an example of such an attack. In addition, private VLANs prevent
a compromised public server from attacking
other servers on the same segment. This traffic is not even detected by the
firewall, a fact that explains why private VLANs
are critical.

Stephen

-----Original Message-----
From: jamesworld@intelligencia.com [mailto:jamesworld@intelligencia.com]
Sent: Monday, November 18, 2002 10:23 AM
To: Stephen Wilcox
Cc: jamesworld@intelligencia.com; security-basics@securityfocus.com
Subject: RE: PIX Question

Stephen, et al,

I agree whole heartedly with 2827 filtering and the PIX can do that as well
(router can too). I however, disagree with 1918 at the edge router. The
ASA algorithm in the PIX makes it a better location to handle the NATing of
public to 1918 addresses. Also, the edge router is not being
burdened. It's doing a routers job: routing. Let the security device take
care of security.

I was not giving a definitive plan for deployment. Just making answers to
specific comments/questions.

Still, lock up the router, use access-classes on the VTY lines. Disable
unused transports, verify the IOS against field notices. Use the local
database or better yet, a TACACS+ server to authenticate and log attempts
to break in to the router. (since you have it use it on the PIX and the
rest of your network infrastructure). Check your logs daily. Disable SNMP
and every service that is not needed on the external edge
routers. (internal too :)

Just like your own body, treat your network the same way. look after it
daily, protect it against the elements that come against it and keep the
juice clean :-)

-James

At 08:33 11/18/02, Stephen Wilcox wrote:
>James,
>
>I would still practice RFC1918 and RFC2827 at your edge router
>
>
>Stephen Wilcox
>R & D Specialists
>Universal Computer Systems
>Voice: (713) 718-1800 ext. 2172
>Email: Stephenwilcox@universalcomputersys.com
>
>
>-----Original Message-----
>From: jamesworld@intelligencia.com [mailto:jamesworld@intelligencia.com]
>Sent: Thursday, November 14, 2002 7:24 AM
>To: naman.latif@inamed.com
>Cc: security-basics@securityfocus.com
>Subject: PIX Question
>
>
>
>You need no protection. The PIX will withstand what is put against it.
>All the advice you are receiving about BDS fw, IOS FW and the like doesn't
>address your specific need.
>
>Key being. You are terminating IPSEC. You put another FW in front and you
>risk losing the IPSEC.
>
>I work with PIX daily. It needs no protection.
>Telnet:
>As far at telnet (you cannot telnet to the outside of a PIX- impossible)
>PDM:
>Set up access via the command: http <host_IP_address> 255.255.255.255
>outside
>for each host you want to have access from.
>Better yet, open none of that and VPN to the PIX and then use
>telnet/ssh/pdm from inside the VPN tunnel.
>
>Don't run CBAC unless you have a 3600 series router or above.
>
>If you really want protection that the PIX does not provide, get your ISP
>to limit the ICMP traffic to a max of 20 % of incoming traffic. help
>protect against DDOS
>
>Got questions, email me offline
>
>
> >Sent: Monday, November 04, 2002 8:47 PM
> >To: security-basics@security-focus.com
> >Subject: Protecting PIX Firewall at the Perimeter Router
> >
> >
> >Hi All,
> >
> >
> >I wanted some suggestions\practical experiences for protecting a
> >Firewall wall at the Perimeter Router Level.
> >
> >
> >We have a PIX Firewall connected to our Cisco Router, which is
> >connected to the Internet. Should there be any IOS Firewall Rules in
> >the Router, other than blocking Telnet,FTP etc to the Firewall itself
> >?
> >
> >
> >PIX will be doing NAT, protecting DMZ machines, and IPSec
> >connections.
> >
> >
> >Regards \\ Naman
> >

• Next message: Eric Polin: "RE: apache server plus ipfilter"
• Previous message: David Lubowa: "RE: Locking Cisco Router"
• In reply to: jamesworld@intelligencia.com: "RE: PIX Question"
• Next in thread: Stephen Wilcox: "RE: PIX Question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]