Educause Security Discussion mailing list archives

Re: Preparing for Default Deny Firewall

From: Steven Alexander <alexander.s () MCCD EDU>
Date: Tue, 1 Feb 2005 10:09:20 -0800

Another note, if you are going to rate-limit traffic to avoid a DoS,
it's best to apply the rate-limiting on the upstream router so that the
traffic is dropped before it eats up any of your bandwidth.

-----Original Message-----
From: Yantis, Jonathan Lindsey [mailto:YantisJ () COFC EDU]
Sent: Tuesday, February 01, 2005 9:48 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Preparing for Default Deny Firewall

Here's a list of ACLs that I happen to have for ICMP inbound. I
can not verify all of them but I was assured they were the proper ones
to allow in: Take from it what you will:

300 permit icmp any any unreachable

310 permit icmp any any echo-reply

320 permit icmp any any packet-too-big

330 permit icmp any any time-exceeded

340 permit icmp any any traceroute

350 permit icmp any any administratively-prohibited

360 deny icmp any any

You may want to allow echo requests in, but I would not advise
doing that unless you are going to rate-limit it as it opens you up to
DoS. As far as your other inbound traffic, I would do a server
assessment and find out all services running and what the corresponding
ports are. I would not recommend just allowing port 80 traffic in,
rather restrict port 80 to set of specific machines. I hope that makes
sense.

On your outbound side, I suggest everyone drop outbound requests
on port 135, 137, 139 and 445 plus whatever else you feel is necessary
while allowing all other outbound traffic. These are common ports used
by viruses and have no real business outside your intranet. It's also a
good idea to create an outbound rule that drops all traffic that is not
sourced from a known internal network to prevent your network being used
to launch spoofed zombie attacks. For example, if your network is
172.16.10.0/24, you would want the following outbound ACL

[truncated outbound ACLs]

Permit ip 172.16.10.0 0.0.0.255 any

Deny ip any any - done by default but I like to see it.

Also, if you want to watch for outbound syn requests, modify
this tcpdump filter for your situation:

tcpdump -n src net yournet/yourmask and "tcp[13] & 2 != 0" and
not port 80 and not port 25 and not port 443

I drop 80, 25, and 443 because they generate a lot of the
outbound syn requests. I actually use this filter as a quick virus
check to see if any machines are making massive outbound connection
attempts but it should work for you.

Hope this helps someone.

-- Jonathan Yantis - yantisj () cofc edu - (843-953-7770)

_____

From: The EDUCAUSE Security Discussion Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Scholz, Greg
Sent: Tuesday, February 01, 2005 12:27 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Preparing for Default Deny Firewall

I am looking at the same situation. Does anyone have a
recommendation for ICMP types/codes in general? It is obvious to me
that ECHO should not be allowed in to avoid ping scans. What about ECHO
REPLY for insiders wanting to test general network connectivity outbound
(this may pose a problem due to infected ResNet computers) or poorly
written applications that may use ICMP to test valid hosts outside the
campus network? Also DESTINATION UNREACHABLE, SOURCE QUENCH, TIME
EXCEEDED, etc. inbound may be of value since they are designed to help
the network/hosts react appropriately to problems outside the network.

Some of my concerns with this type of change:

When it is time to make this switch I plan to do some packet
level analysis to determine what may break. The best idea I have come
up with would be to watch OUTBOUND traffic for "Syn/Ack". This way I
can determine if there are any REAL services being provided that are not
documented and at that time determine if the services are legitimate.
If you have had a firewall that I refer to as "inside out" (because it
does the opposite of what firewalls are designed to do) for some time I
would expect you have a number of unapproved (although possibly valid)
services being provided by hosts inside your network.

_________________________

Thank you,

Gregory R. Scholz

Lead Network Engineer

Information Technology Group

Keene State College

(603)358-2070

_____

From: Steven Alexander [mailto:alexander.s () MCCD EDU]
Sent: Tuesday, February 01, 2005 11:39 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Preparing for Default Deny Firewall

One small note: You should allows incoming ICMP packets of type
3 code 4 ( Fragmentation needed but no frag. bit set ). These packets
are needed for Path Maximum Transmission Unit Discovery (PMTUD). PMTUD
is enabled by default in Windows XP and Server 2003. If you do not
allow these packets in, it may cause problems for some people viewing
your school's website or accessing other services.

Steven

-----Original Message-----
From: Cary, Kim [mailto:Kim.Cary () PEPPERDINE EDU]
Sent: Tuesday, February 01, 2005 8:05 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Preparing for Default Deny Firewall

We will shortly be going to an default-deny firewall
(inbound only)
here (8000 students 1000 staff, 7 campuses on a WAN).

For those of you that have such a situation, I would
appreciate any
tips you have for:
1. Moving from block known bad to permit known good
inbound posture.
2. Procedures you have to processing & approving
exceptions for new or
changed services.

For those of you that decided against this type of
firewall, I think
our implementation would be informed of some things to
look out for by
hearing from you about your issues that prevent you from
going to this
position.

We also are in receipt of a recommendation that states
our router ACLs
should also be default deny. Any tips/comments on that
recommendation
would be welcome as well.

Kim Cary
Infrastructure Security Administrator
Pepperdine University
310 506 6655

**********
Participation and subscription information for this
EDUCAUSE Discussion Group discussion list can be found at
http://www.educause.edu/groups/.

______________________________________________________________________
This email has been scanned by the MessageLabs Email
Security System.
For more information please visit
http://www.messagelabs.com/email

______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security
System.
For more information please visit
http://www.messagelabs.com/email

______________________________________________________________________
********** Participation and subscription information for this
EDUCAUSE Discussion Group discussion list can be found at
http://www.educause.edu/groups/. ********** Participation and
subscription information for this EDUCAUSE Discussion Group discussion
list can be found at http://www.educause.edu/groups/. **********
Participation and subscription information for this EDUCAUSE Discussion
Group discussion list can be found at http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at
http://www.educause.edu/groups/.

Current thread:

Preparing for Default Deny Firewall Cary, Kim (Feb 01)
- <Possible follow-ups>
- Re: Preparing for Default Deny Firewall Steven Alexander (Feb 01)
- Re: Preparing for Default Deny Firewall Arturo Servin (Feb 01)
- Re: Preparing for Default Deny Firewall Scholz, Greg (Feb 01)
- Re: Preparing for Default Deny Firewall Brawner, David (Feb 01)
- Re: Preparing for Default Deny Firewall John Kristoff (Feb 01)
- Re: Preparing for Default Deny Firewall Yantis, Jonathan Lindsey (Feb 01)
- Re: Preparing for Default Deny Firewall Steven Alexander (Feb 01)
- Re: Preparing for Default Deny Firewall Jeff Kell (Feb 01)