CISCO 837 CONFIG NEEDS SECURING

[gillz]

Hi All,

I need some help in securing my 837 configuration; I've searched around and have added a few things to lock the router down further. I seem to have a problem applying access lists to the Dialer interface, for example blocking RFC1918 ranges to prevent ant-spoofing. Although the access list is accepted by the IOS as soon as it’s applied I lose my internet access????? If anyone can point out where I can lock the device down further it would be appreciated. I'm new the IOS so any assistance would make me less paranoid when using this router.

Building configuration...

Current configuration : 2322 bytes
!
version 12.3
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname cs837
!
enable secret 5 xxxxxxxxxxxxxx
!
no aaa new-model
ip subnet-zero
ip domain name yourdomain.com
ip name-server x.x.x.x
ip name-server x.x.x.x
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool home-pool
import all
--More--   network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server x.x.x.x x.x.x.x
!
!
ip audit notify log
ip audit po max-events 100
no ftp-server write-enable
!
!
!
!
!
!
!
interface Ethernet0
description Ethernet
ip address 10.10.10.1 255.255.255.0
ip access-group 100 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
hold-queue 100 out
--More--  !
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no atm ilmi-keepalive
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
dsl operating-mode auto
!
interface FastEthernet1
no ip address
duplex auto
speed auto
!
interface FastEthernet2
no ip address
duplex auto
speed auto
!
--More--  interface FastEthernet3
no ip address
duplex auto
speed auto
!
interface FastEthernet4
no ip address
duplex auto
speed auto
!
interface Dialer0
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname xxxxxxxxxxx
ppp chap password 0 xxxxxxxxxx
 !
ip nat inside source list 1 interface Dialer0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0
no ip http server
no ip http secure-server
!
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 100 remark lan access to router
access-list 100 deny udp any eq netbios-ns any
access-list 100 deny udp any eq netbios-dgm any
access-list 100 deny udp any eq netbios-ss any
access-list 100 deny icmp any any redirect
access-list 100 permit udp any eq bootpc any
access-list 100 permit ip 10.0.0.0 0.255.255.255 any
access-list 100 deny ip any any log
!
line con 0
no modem enable
line aux 0
line vty 0 4
password xxxxxxxxxxxx
login
!
scheduler max-task-time 5000
!
end

Cheers,

Gillz

[Spice_Weasel]

Here are some quick recommendations:

- Better logging:
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service sequence-numbers

- Use aaa for authentication/authorization:
aaa new-model
aaa authentication login default local
aaa authentication login admin local

- Create enable password
enable secret 0 <some strong password>

- Create a suitable user account.
user <some name> secret 0 <a good password>

- Source routes and grat arps are not good, disable them
no ip source-route
no ip gratuitous-arps

- Close half open connections
ip tcp synwait-time 10

- Do not resolve names
no ip domain lookup

- Log logins, give three attempts before blocking logins
login block-for 60 attempts 3 within 30
login on-failure log
login on-success log

- CDP should not be used unless needed. And never on a router connected to untrusted networks.
no cdp run
Also, use "no cdp enable" on each interface, as it is a good practice to disable cdp globally and on each interface.

- SSH configuration. Use version 2 and log it.
ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh version 2
ip ssh logging events

As well, you will need to generate a key, use the following:
cry key gen rsa mod 1024

- Use ssh to access router, and admin aaa group. Get rid of the password on the vty lines.
line vty 0 4
transport input ssh
login authentication admin

- Create an access-list to protect the vty lines
access-list 15 permit 10.0.0.0 0.0.0.255 log
access-list 15 deny any log

- Apply the access-list to your vty lines
line vty 0 4
access-class 12 in

- Kill the aux port, unless you use it.
line aux 0
no exec
transport input none
transport output none

- Stop backscatter from null0
int null0
no ip unreachables

- Log stuff.
logging buffered 32768 debug

- but keep console clear.
logging console critical <-- usually I will disable console logging. But here I left critical messages to console.

- Set up ntp, and disable ntp on all interfaces except on the interface you will receive time updates on.
ntp server 132.246.168.148 <-- sample timeserver ip's
ntp server 132.246.168.164
ntp disable <-- apply to interfaces that do not provide time info

- If you are not using snmp, disable it.
no snmp-server enable

- Don't boot from the network.
no network boot

Do the login related changes first and don't save them. Test them out thoroughly. If you accidentally lock yourself out just cycle the power. Don't write the changes until you are sure they work properly.

Also, in access-list 100 the permitted network is too large, change it to match your actual internal lan. As well, if you really want a well protected network, I would strongly advise filtering outbound traffic. For example, permit only http, https and dns (to a valid dns server) out. Then add further to the permitted list as needed.

You will need an access-list on the external interface (di0) - or, even better, use the IOS firewall if available. Depending on how thoroughly you want to filter inbound packets, your external access-list could just block private addresses, e.g.:

ip access-list ext incoming
10 deny ip 10.0.0.0 0.255.255.255 any
20 deny ip 172.16.0.0 0.15.255.255 any
30 deny ip 192.168.0.0 0.0.255.255 any
40 deny ip 127.0.0.0 0.255.255.255 any
50 deny ip 224.0.0.0 31.255.255.255 any
60 deny ip 225.0.0.0 0.255.255.255 any
70 deny ip 169.254.0.0 0.0.255.255 any
80 deny ip host 0.0.0.0 any
90 permit ip any any

If you have a static ip, deny packets with that ip as a source. You can also log the above deny lines - logging is a good thing!
You can also block ports, e.g. telnet, snmp, etc. that you never want coming into your network. There are plenty of things you can add to the external access-list depending on your preferences.
You can also go all the way and restrict bogon and hijacked ip address blocks, but that takes work and must be maintained, and can be considered overkill for a home user.

I always create a loopback and use it for a variety of purposes, in particular as a source ip for certain functions, e.g. syslog, snmp, ssh, rcmd, etc.

There are other things you can do, e.g. ip accounting, ios firewall, ip verify unicast, syslog/snmp, ip flow, archive, ids, mop, etc.

This will get you started, more can be done later. Depending on your IOS version and feature set not all of the above may be available.

Spice_Weasel

[gillz]

Hi Spice,

Thanks for your detailed informative response.

Cheers

[ManishBehal]

Or use Cisco Auto-Secure - it does all this for you!!

http://www.cisco.com/univercd/cc/td/...1/ftatosec.htm

[Fergal1982]

Originally Posted by ManishBehal

Or use Cisco Auto-Secure - it does all this for you!!

Please dont resurrect old threads!

[ManishBehal]

"Please dont resurrect old threads!"


You are joking, right??

[Qs]

Originally Posted by ManishBehal

"Please dont resurrect old threads!"


You are joking, right??

Admittedly the last post in the thread was over 12 months ago, Manish.

Qs

[ManishBehal]

Yes the post was 12 months ago and Cisco has moved on leaps and bounds since then. My post simply highlighed the new feature that is now the preferred method for securing a Cisco SOHO router like that of the Original Poster.

No worries, no harm intended, just trying to help.

[Fergal1982]

help: Good. Necroposting: Bad! (Fire: Bad! )

A lot of areas have moved on in leaps and bounds in the years since the post was made here in CF, If everyone went back and necroposted every time there was a curriculum change in the A+, to update the posts, it would never end now, would it?

More than a few months old is the general rule of thumb for necroposting (and even then sometimes less depending on the topic). General exceptions are if the OP is returning to update the forum on their current situation in relation to the thread topic. Even then they should generally create a new post.

Other notable exceptions are posts that lend themselves to necroposting, such as the polls.

[Qs]

Originally Posted by ManishBehal

Yes the post was 12 months ago and Cisco has moved on leaps and bounds since then. My post simply highlighed the new feature that is now the preferred method for securing a Cisco SOHO router like that of the Original Poster.

No worries, no harm intended, just trying to help.

Indeed, and we're all for that!

Fergal's point is that the OP isn't going to be looking at this anymore and nor is anyone else.