Changes in version 5.0:
- 186/8 and 187/8 allocated to LACNIC (SEP 2007).
Removed from the bogon filters.
Changes in version 4.9:
- Disabled TCL.
- Added access and enable command logging.
- Added the Netflow top talkers feature.
Changes in version 4.8:
- 94/8 and 95/8 allocated to RIPE (JUL 2007). Removed
from the bogon filters.
Changes in version 4.7:
- 46/8 re-listed as IANA Reserved (APR 2007). Added to
the bogon filters. 7/8 removed from bogon filters due to dispute in
allocation status.
Changes in version 4.6:
- 92/8 and 93/8 allocated to RIPE (MAR 2007). Removed
from the bogon filters.
Changes in version 4.5:
- 116/8, 117/8, 118/8, 119/8 and 120/8 allocated to
APNIC (JAN 2007). Removed from the bogon filters.
Changes in version 4.4:
- 96/8, 97/8, 98/8 and 99/8 allocated to ARIN (OCT
2006). Removed from the bogon filters.
Changes in version 4.3:
- 77/8, 78/8 and 79/8 allocated to RIPE (AUG 2006).
Removed from the bogon filters.
Changes in version 4.2:
- 121/8, 122/8 and 123/8 allocated to APNIC (JAN 2006).
Removed from the bogon filters.
Changes in version 4.1:
- 89/8, 90/8 and 91/8 allocated to RIPE (JUN 2005).
Removed from the bogon filters.
Changes in version 4.0:
- 74/8, 75/8 and 76/8 allocated to ARIN (JUN 2005).
Removed from the bogon filters. - 189/8 and 190/8 allocated to LACNIC (JUN 2005).
Removed from the bogon filters.
Changes in version 3.9:
- 41/8 allocated to AfriNIC (APR 2005). Removed from the
bogon filters.
Changes in version 3.8:
- 73/8 allocated to ARIN (MAR 2005). Removed from the
bogon filters.
Changes in version 3.7:
- 124/8, 125/8 and 126/8 allocated to APNIC (JAN 2005).
Removed from the bogon filters.
Changes in version 3.6:
- 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed
from the bogon filters.
Changes in version 3.5:
- 58/8 and 59/8 allocated to the APNIC (APR 2004).
Removed from the bogon filters. - Removed TCP Intercept, a feature best left disabled on
all routers.
Changes in version 3.4:
- 85/8, 86/8, 87/8, and 88/8 allocated to the RIPE NCC
(APR 2004). Removed from the bogon filters.
Changes in version 3.3:
- Removed 70/8 (allocated to ARIN JAN 2004) from the
bogon filters.
Changes in version 3.1:
- Removed 83/8 and 84/8 (allocated to RIPE NCC NOV 2003)
from the bogon filters.
Changes in version 3.0:
- APNIC returned the 223/8 allocation to IANA and
received the 60/8 allocation in its place on 07 April 2003.
Changes in version 2.9:
- Added the following netblocks to the bogon filters,
designated as RESERVED by IANA on 04 April 2003:
· 173/8 Apr 03 IANA - Reserved· 174/8 Apr 03 IANA - Reserved· 175/8 Apr 03 IANA - Reserved· 176/8 Apr 03 IANA - Reserved· 177/8 Apr 03 IANA - Reserved· 178/8 Apr 03 IANA - Reserved · 179/8 Apr 03 IANA - Reserved · 180/8 Apr 03 IANA - Reserved · 181/8 Apr 03 IANA - Reserved · 182/8 Apr 03 IANA - Reserved · 183/8 Apr 03 IANA - Reserved · 184/8 Apr 03 IANA - Reserved · 185/8 Apr 03 IANA - Reserved · 186/8 Apr 03 IANA - Reserved · 187/8 Apr 03 IANA - Reserved · 189/8 Apr 03 IANA - Reserved · 190/8 Apr 03 IANA - Reserved Changes in version 2.8:
- Removed 201/8 (allocated to LACNIC APR 2003) from the
bogon filters.
Changes in version 2.7:
- Removed 222/8 and 223/8 (allocated to APNIC FEB 2003)
from the bogon filters.
Changes in version 2.6:
- Removed 82/8 (allocated to RIPE NOV 2002) from the
bogon filters.
Changes in version 2.5:
- Removed 69/8 (allocated to ARIN AUG 2002) from the
bogon filters.
Changes in version 2.3:
- Added additional bogon filters to the black hole route
list. - Added additional bogon filters to the ACLs.
Changes on 22 JUN 2001 (version 2.3.1):
- Removed 67/8 and 68/8 from the "bogon" ACLs. These
netblocks will be allocated by ARIN (on /20 boundaries) as of 22 June 2001.
Changes on 16 OCT 2001 (version 2.3.2):
- Removed 219/8 from the "bogon" ACLs. This netblock
will be allocated by APNIC as of 17 October 2001.
Changes in version 2.4:
- Removed 221/8 from the ACL and black hole route list.
This netblock has been allocated to APNIC as of JUL 2002.
Introduction
One of the challenges of any network is how to mitigate, if not deny, the
various attacks launched daily on the Internet. While blocking the script
kiddies and their attempts to gain root or scan a subnet is one challenge, a
greater challenge has been to mitigate the DDoS attacks. While nothing is
foolproof, layers of protection can be applied to the problem.
Taking a holistic view of the challenge led to the creation of the layered
approach. In this approach, the following philosophies are applied:
1) The border router provides for protocol protection and defends itself and
the firewall.
2) The firewall provides port protection and defends itself and the host
residing behind it.
3) The end stations are configured to survive various DOS attacks as well as to
reduce the number of noxious services which might be exploited.
This results in the "funnel effect," wherein progressively less nasty traffic
comes through the overall pipe. The network is "crunchy through and through,"
not just at the edges.
A brief aside - If you are interested in tuning your UNIX systems to provide
additional defense against myriad attack types, please peruse my
UNIX IP Stack Tuning Guide.
The purpose of this document is to introduce the first wall of defense, the
router. The attached template provides a work in progress towards the goal of a
secure border device. This template does not cover router or routing protocol
basics, and only lightly touches on the topic of router performance tuning (e.g.
using the loopback device instead of the null device for black hole routes). For
more on router performance tuning tips, please see my
Cisco Router Performance Tuning document.
As an added bonus,
George Jones has written a tool, NCAT, that will validate Cisco
router configurations. Using a template configuration, NCAT will ensure
that any router configuration adheres to the policies in the template. I highly
recommend this tool. You will find it at
ncat.sourceforge.net.
While I list the bogon ranges on /8 boundaries, you may prefer to aggregate
further. For this please see my
Bogon List.
Barry Greene and Philip Smith, both of Cisco, have recently released a book
entitled Cisco ISP Essentials. This is an excellent collection of clue.
You can learn more about it at
www.ispbook.com.
Barry also keeps a nice collection of Cisco security documents
here.
Credits
I truly appreciate the suggestions, bug reports, and thoughtful discourse
provided by these folks. Thank you!
Bruce Babcock
Alison Gudgeon
Paul Jacobs
Deepak Jain
George Jones
Christian Koch
Mark Kent
Thomas Kernen
John Kristoff
Christopher Morrow
Hank Nussbacher
Johan van Reijenda
Ken Reiss
Rafi Sadowsky
Steve Snodgrass
Alfredo Sola
David Wolsefer
And, of course, the
FIRST community.
Overview
The Cisco Secure IOS Configuration Template is simply a template, or a
starting point. Individual sites will need to modify the template to varying
degrees. For example, the template does not include any routing protocol
information. This would make the template far too large and specific. Although
one could argue that a BGP configuration would meet the needs of a great many
border routers, it was decided to shelve that piece for another template. You
may wish to peruse my
Secure Cisco BGP Configuration Template to assist you in securing
your BGP configuration. As with all templates, your mileage may vary.
The template has undergone a trial by fire, protecting various sites. In one
case, a modified version of this template protects a site that endures upwards
of 10000 attacks per day. The template has weathered the storm well, although
not without some real time modification. As the instruments and methods of the
malcontents change, so do the attack styles. However, this template has yet to
fail, and the sites behind it have remained on-line throughout attacks of
moderate to great intensity.
Clearly, hardware counts. A 2501 with this template will not provide much in
the way of protection, and certain features of this template will not work on
the lower tier of Cisco routing products. The template was written with a Cisco
7000 or greater model in mind.
This template is not a panacea. It will not stop all attack types. It is
simply a part of a larger design. Remember the layered approach.
Decisions, Decisions
As noted, the template must be modified to fit the environment. Obviously
such things as IP addresses and routes must be changed. How ever, there are
other decisions to be made. The IP address of the FTP, TACACS+, and syslog
servers must be noted, for example.
Enabling the anti-spoofing feature of CEF (reverse-path) is another thorny
issue for those with the potential for asymmetric data flows. In this case, ACLs
should be used for anti-spoofing protection. Both options are provided in the
template.
Determining the proper CAR limits for multicast, ICMP, and UDP is quite site
specific. While some defaults have been placed in the configuration, it is best
to size the pipe and modify the limits accordingly. It is difficult to model a
situation where ICMP should be allowed more than 575Kb/s of bandwidth, however
your mileage may vary.
Caveats
As with all things, test test test. Do not deploy a configuration without
thoroughly testing it in a non-production environment. If you do not understand
the commands or the accompanying comments, do not utilize them. You may find
yourself in a sticky debugging session at some point, so complete understanding
of the configuration is highly recommended.
Tested IOS Versions
This template has been tested on the following IOS versions (as denoted on
the IOS software download site):
IOS 12.1.5a Service
Provider/VIP (Service Provider on the 4500M)
IOS 12.0.14 Service
Provider/VIP (Service Provider on the 4500M)
IOS 12.0.9 Service Provider
The template was tested on Cisco 7500 and 4500M series
routers. Obviously I did not test the VIP versions of the IOS on the 4500M, but
instead used the Service Provider versions.
If you have a special requirement to run a version of the IOS not listed
here, feel free to ping on me and I will attempt to test, time permitting, the
template on the version in question.
Question, Comments, Suggestions
This is a work in progress, and feedback from those who use the template,
have their own bag of tricks, or endure malicious attacks is most welcome! If
you have questions, I will do my best to answer them and assist you. Please
route all commentary and questions to
robt@cymru.com.
I hope you find this helpful in your effort to fend off the Internet vandals!
Template
The commands are in BOLD text so that they stand out from the
surrounding comments.
! Secure router configuration template.
! Version 3.1
! @(#)Secure IOS template v3.1 17 NOV 2003 Rob Thomas robt@cymru.com
! @(#)http://www.cymru.com/Documents/secure-ios-template.html
!
! This configuration assumes the following topology:
!
! Upstream/Internet
! 5.5.5.1/24
!
! 5.5.5.254/24 (Ethernet 2/0)
! THIS ROUTER
! 6.6.6.254/24 (Ethernet 2/1)
!
! 6.6.6.1/24
! Firewall
! 7.7.7.1/24
!
! 7.7.7.0/24
! Intranet
!
! In this case, 7.7.7.5 is the loghost, FTP server, etc.
! for the router. It could also be the firewall if
! circumstances dictate.
!
service nagle
service tcp-keepalives-in
service tcp-keepalives-out
! Show copious timestamps in our logs
service timestamps debug datetime msec show-timezone localtime
service timestamps log datetime msec show-timezone localtime
service password-encryption
no service dhcp
!
hostname secure-router01
!
boot system flash slot0:rsp-pv-mz.121-5a.bin
logging buffered 16384 debugging
no logging console
enable secret <PASSWORD>
no enable password
!
! Use TACACS+ for AAA. Ensure that the local account is
! case-sensitive, thus making brute-force attacks less
! effective.
aaa new-model
aaa authentication login default group tacacs+ local-case
aaa authentication enable default group tacacs+ enable
aaa authorization commands 15 default group tacacs+ local
aaa accounting exec default stop-only group tacacs+
aaa accounting commands 15 default stop-only group tacacs+
aaa accounting network default stop-only group tacacs+
tacacs-server host 7.7.7.5
tacacs-server key cheezit
!
! In the event that TACACS+ fails, use case-sensitve local
! authentication instead. Keeps the hackers guessing, and
! the router more secure.
username <USERNAME> secret <PASSWORD>
!
! Logging the commands run while at enable level access is
! a great way to track mistakes, security issues, etc.
archive
log config
logging enable
logging size 500
notify syslog
hidekeys
!
! Disable TCL, where available. This won't show up in the
! config. It will break your router-based TCL scripts if
! if you use such, so use with care!
no scripting tcl init
no scripting tcl encdir
!
! Enable the netflow top talkers feature.
! You can see the top N talkers (50 in this example) with the
! show ip flow top-talkers command. This is a handy
! utility to use during DDoS attacks and traffic issues. You
! can sort-by either packets or bytes, as you prefer.
ip flow-top-talkers
top 50
sort-by packets
!
! Don't run the HTTP server.
no ip http server
no ip http secure-server
!
! Allow us to use the low subnet and go classless
ip subnet-zero
ip classless
!
! Disable noxious services
no service pad
no ip source-route
no ip finger
no ip bootp server
no ip domain-lookup
!
! Catch crash dumps; very important with a "security router."
ip ftp username rooter
ip ftp password <PASSWORD>
! Give our core dump files a unique name.
exception core-file secure-router01-core
exception protocol ftp
exception dump 7.7.7.5
! Fire up CEF for both performance and security.
ip cef
! Set the timezone properly. It is best to standardize on one
! timezone for all routers, thus making problem tracking easier.
clock timezone GMT 0
! Synchronize our clocks with a local (trusted and authenticated)
! NTP server. The SECRETKEY must be the same on both the router
! and the NTP server.
ntp authentication-key 6767 md5 <SECRETKEY>
ntp authenticate
ntp update-calendar
ntp server 7.7.7.5
!
! Configure the loopback0 interface as the source of our log
! messages. This is often used for routing protocols as well.
! Select an IP address that uniquely identifies this router.
! One trick is to allocate a netblock for use as the router
! loopback netblock.
int loopback0
ip address 10.10.10.10 255.255.255.255
no ip redirects
no ip unreachables
no ip proxy-arp
!
! Configure null0 as a place to send naughty packets. This
! becomes the "roach motel" for packets -- they can route in,
! but they can't route out.
interface null0
no ip unreachables
!
interface Ethernet2/0
description Unprotected interface, facing towards Internet
ip address 5.5.5.254 255.255.255.0
! Do we run CEF verify? Yes if the data path is symmetric. No
! if the data path is asymmetric.
ip verify unicast reverse-path
! Apply our template ACL
ip access-group 2010 in
! Allow UDP to occupy no more than 2 Mb/s of the pipe.
rate-limit input access-group 150 2010000 250000 250000 conform-action
transmit exceed-action drop
! Allow ICMP to occupy no more than 500 Kb/s of the pipe.
rate-limit input access-group 160 500000 62500 62500 conform-action transmit
exceed-action drop
! Allow multicast to occupy no more than 5 Mb/s of the pipe.
rate-limit input access-group 170 5000000 375000 375000 conform-action
transmit exceed-action drop
! Don't send redirects.
no ip redirects
! Don't send unreachables.
! NOTE WELL that this may break PMTU discovery.
! For example, if this router is edge for a VPN of any sort, you might need
! to enable ip unreachables
! A typical symptom is ping working but a larger transmission doesn't.
no ip unreachables
! Don't propogate smurf attacks.
no ip directed-broadcast
! Don't pretend to be something you're not. :-)
no ip proxy-arp
! Do not reveal our netmask
no ip mask-reply
! Log all naughty business.
ip accounting access-violations
! If you allow multicast in your network or participate in the
! MBONE, the following multicast filtering steps will help to
! ensure a secure multicast environment. These must be applied
! per interface.
ip multicast boundary 30
!
! Keep flow data for analysis. If possible, export it to a
! cflowd server.
ip route-cache flow
!
interface Ethernet2/1
description Protected interface, facing towards DMZ
ip address 6.6.6.254 255.255.255.0
! Do we run CEF verify? Yes if the data path is symmetric. No
! if the data path is asymmetric.
ip verify unicast reverse-path
! If we are using RPF, comment out the ACL below.
ip access-group 115 in
no ip redirects
no ip unreachables
no ip directed-broadcast
no ip proxy-arp
ip accounting access-violations
ip multicast boundary 30
no ip mask-reply
ip route-cache flow
!
! Default route to the Internet (could be a routing
! protocol instead)
ip route 0.0.0.0 0.0.0.0 5.5.5.1
! Route to network on the other side of the firewall
ip route 7.7.7.0 255.255.255.0 6.6.6.1
! Black hole routes. Do not combine this with TCP Intercept;
! in fact, don't use TCP Intercept at all.
ip route 1.0.0.0 255.0.0.0 null0
ip route 2.0.0.0 255.0.0.0 null0
ip route 5.0.0.0 255.0.0.0 null0
ip route 10.0.0.0 255.0.0.0 null0
ip route 23.0.0.0 255.0.0.0 null0
ip route 27.0.0.0 255.0.0.0 null0
ip route 31.0.0.0 255.0.0.0 null0
ip route 36.0.0.0 255.0.0.0 null0
ip route 37.0.0.0 255.0.0.0 null0
ip route 39.0.0.0 255.0.0.0 null0
ip route 42.0.0.0 255.0.0.0 null0
ip route 46.0.0.0 255.0.0.0 null0
ip route 49.0.0.0 255.0.0.0 null0
ip route 50.0.0.0 255.0.0.0 null0
ip route 100.0.0.0 255.0.0.0 null0
ip route 101.0.0.0 255.0.0.0 null0
ip route 102.0.0.0 255.0.0.0 null0
ip route 103.0.0.0 255.0.0.0 null0
ip route 104.0.0.0 255.0.0.0 null0
ip route 105.0.0.0 255.0.0.0 null0
ip route 106.0.0.0 255.0.0.0 null0
ip route 107.0.0.0 255.0.0.0 null0
ip route 108.0.0.0 255.0.0.0 null0
ip route 109.0.0.0 255.0.0.0 null0
ip route 110.0.0.0 255.0.0.0 null0
ip route 111.0.0.0 255.0.0.0 null0
ip route 112.0.0.0 255.0.0.0 null0
ip route 113.0.0.0 255.0.0.0 null0
ip route 114.0.0.0 255.0.0.0 null0
ip route 115.0.0.0 255.0.0.0 null0
ip route 127.0.0.0 255.0.0.0 null0
ip route 169.254.0.0 255.255.0.0 null0
ip route 172.16.0.0 255.240.0.0 null0
ip route 173.0.0.0 255.0.0.0 null0
ip route 174.0.0.0 255.0.0.0 null0
ip route 175.0.0.0 255.0.0.0 null0
ip route 176.0.0.0 255.0.0.0 null0
ip route 177.0.0.0 255.0.0.0 null0
ip route 178.0.0.0 255.0.0.0 null0
ip route 179.0.0.0 255.0.0.0 null0
ip route 180.0.0.0 255.0.0.0 null0
ip route 181.0.0.0 255.0.0.0 null0
ip route 182.0.0.0 255.0.0.0 null0
ip route 183.0.0.0 255.0.0.0 null0
ip route 184.0.0.0 255.0.0.0 null0
ip route 185.0.0.0 255.0.0.0 null0
ip route 192.0.2.0 255.255.255.0 null0
ip route 192.168.0.0 255.255.0.0 null0
ip route 197.0.0.0 255.0.0.0 null0
ip route 223.0.0.0 255.0.0.0 null0
!
! Export our NetFlow data to our NetFlow server, 7.7.7.5. NetFlow
! provides some statistics that can be of use when tracing the true
! source of a spoofed attack.
ip flow-export source loopback0
ip flow-export destination 7.7.7.5 2055
ip flow-export version 5 origin-as
!
! Log anything interesting to the loghost. Capture all of
! the logging output with FACILITY LOCAL5.
logging trap debugging
logging facility local5
logging source-interface loopback0
logging 7.7.7.5
!
! With the ACLs, it is important to log the naughty folks.
! Thus, the implicit drop all ACL is replaced (augmented,
! actually) with an explicit drop all that logs the attempt.
! You may wish to keep a second list (e.g. 2011) that does not
! log. During an attack, the additional logging can impact the
! performance of the router. Simply copy and paste access-list 2010,
! remove the log-input keyword, and name it access-list 2011. Then
! when an attack rages, you can replace access-list 2010 on the
! Internet-facing interface with access-list 2011.
!
! Block SNMP access to all but the loghost
access-list 20 remark SNMP ACL
access-list 20 permit 7.7.7.5
access-list 20 deny any log
!
! Multicast - filter out obviously naughty or needless traffic
access-list 30 remark Multicast filtering ACL
! Link local
access-list 30 deny 224.0.0.0 0.0.0.255 log
! Locally scoped
access-list 30 deny 239.0.0.0 0.255.255.255 log
! sgi-dogfight
access-list 30 deny host 224.0.1.2 log
! rwhod
access-list 30 deny host 224.0.1.3 log
! ms-srvloc
access-list 30 deny host 224.0.1.22 log
! ms-ds
access-list 30 deny host 224.0.1.24 log
! ms-servloc-da
access-list 30 deny host 224.0.1.35 log
! hp-device-disc
access-list 30 deny host 224.0.1.60 log
! Permit all other multicast traffic
access-list 30 permit 224.0.0.0 15.255.255.255 log
!
! Block access to all but the loghost and the firewall, and log any
! denied access attempts. This also serves to create an audit trail
! of all access to the router. Extended ACLs are used to log some
! additional data.
access-list 100 remark VTY Access ACL
access-list 100 permit tcp host 7.7.7.5 host 0.0.0.0 range 22 23 log-input
access-list 100 permit tcp host 6.6.6.1 host 0.0.0.0 range 22 23 log-input
access-list 100 deny ip any any log-input
!
! Leave one VTY safe for access, just in case. The host
! 7.7.7.8 is a secure host in the NOC. If all the VTYs are
! occupied, this leaves one VTY available.
access-list 105 remark VTY Access ACL
access-list 105 permit tcp host 7.7.7.8 host 0.0.0.0 range 22 23 log-input
access-list 105 deny ip any any log-input
!
! Configure an ACL that prevents spoofing from within our network.
! This ACL assumes that we need to access the Internet only from the
! 7.7.7.0/24 network. If you have additional networks behind
! 7.7.7.0/24, then add them into this ACL.
access-list 115 remark Anti-spoofing ACL
! First, allow our intranet to access the Internet.
access-list 115 permit ip 7.7.7.0 0.0.0.255 any
! Second, allow our firewall to access the Internet. This is useful
! for testing.
access-list 115 permit ip host 6.6.6.1 any
! Now log all other such attempts.
access-list 115 deny ip any any log-input
!
! Rate limit (CAR) ACLs for UDP, ICMP, and multicast.
access-list 150 remark CAR-UDP ACL
access-list 150 permit udp any any
access-list 160 remark CAR-ICMP ACL
access-list 160 permit icmp any any
access-list 170 remark CAR-Multicast ACL
access-list 170 permit ip any 224.0.0.0 15.255.255.255
!
! Deny any packets from the RFC 1918, IANA reserved, test,
! multicast as a source, and loopback netblocks to block
! attacks from commonly spoofed IP addresses.
access-list 2010 remark Anti-bogon ACL
! Claims it came from the inside network, yet arrives on the
! outside (read: Internet) interface. Do not use this if CEF
! has been configured to take care of spoofing.
! access-list 2010 deny ip 6.6.6.0 0.0.0.255 any log-input
! access-list 2010 deny ip 7.7.7.0 0.0.0.255 any log-input
! Bogons
access-list 2010 deny ip 0.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 1.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 2.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 5.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 10.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 23.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 27.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 31.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 36.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 37.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 39.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 42.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 46.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 49.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 50.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 100.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 101.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 102.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 103.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 104.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 105.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 106.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 107.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 108.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 109.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 110.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 111.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 112.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 113.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 114.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 115.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 127.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 169.254.0.0 0.0.255.255 any log-input
access-list 2010 deny ip 172.16.0.0 0.15.255.255 any log-input
access-list 2010 deny ip 173.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 174.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 175.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 176.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 177.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 178.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 179.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 180.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 181.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 182.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 183.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 184.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 185.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 192.0.2.0 0.0.0.255 any log-input
access-list 2010 deny ip 192.168.0.0 0.0.255.255 any log-input
access-list 2010 deny ip 197.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 223.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 224.0.0.0 31.255.255.255 any log-input
! Drop all ICMP fragments
access-list 2010 deny icmp any any fragments log-input
! Allow IP access to the intranet (firewall filters specific ports)
access-list 2010 permit ip any 7.7.7.0 0.0.0.255
! Allow multicast to enter. See also access-list 30 for more
! specific multicast rules.
access-list 2010 permit ip any 224.0.0.0 15.255.255.255
! Our explicit (read: logged) drop all rule
access-list 2010 deny ip any any log-input
!
! Do not share CDP information, which contains key bits about our
! configuration, etc. This command disabled CDP globally. If you
! require CDP on an interface, use cdp run and disable cdp
! (no cdp enable) on the Internet-facing interface.
no cdp run
! SNMP is VERY important, particularly with MRTG.
! Treat the COMMUNITY string as a password - keep it difficult to guess.
snmp-server community <COMMUNITY> RO 20
!
! Introduce ourselves with an appropriately stern banner.
banner motd %
Router foo. Access to this device or the attached
networks is prohibited without express written permission.
Violators will be prosecuted to the fullest extent of both civil
and criminal law.
We don't like you. Go away.
%
!
line con 0
exec-timeout 15 0
transport input none
line aux 0
exec-timeout 15 0
line vty 0 3
access-class 100 in
exec-timeout 15 0
! Enable SSH connectivity. This is much more secure than telnet.
! Obviously, you must have an IOS image that supports SSH, and don't
! forget to generate the key with crypto key generate rsa.
transport input telnet ssh
line vty 4
access-class 105 in
exec-timeout 15 0
transport input telnet ssh
!
Rob Thomas
http://www.cymru.com
0 comments:
Post a Comment