CISCO 837 CONFIG NEEDS SECURING

Discussion in 'Network Security' started by gillz, Oct 27, 2007.

  1. gillz

    gillz New Member

    9
    0
    1
    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
     
  2. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    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
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  3. gillz

    gillz New Member

    9
    0
    1
    Hi Spice,

    Thanks for your detailed informative response.

    Cheers
     
  4. ManishBehal

    ManishBehal New Member

    6
    0
    18
    Certifications: CCIE,CCNP,CCDA,CCNP,MCSE,MCSA,MCDST,MCT
    WIP: CCIE Security,
  5. Fergal1982

    Fergal1982 Petabyte Poster

    4,196
    172
    211
    Please dont resurrect old threads!
     
    Certifications: ITIL Foundation; MCTS: Visual Studio Team Foundation Server 2010, Administration
    WIP: None at present
  6. ManishBehal

    ManishBehal New Member

    6
    0
    18
    "Please dont resurrect old threads!"


    You are joking, right??
     
    Certifications: CCIE,CCNP,CCDA,CCNP,MCSE,MCSA,MCDST,MCT
    WIP: CCIE Security,
  7. Qs

    Qs Semi-Honorary Member Gold Member

    3,081
    70
    171
    Admittedly the last post in the thread was over 12 months ago, Manish.

    Qs
     
    Certifications: MCT, MCSE: Private Cloud, MCSA (2008), MCITP: EA, MCITP: SA, MCSE: 2003, MCSA: 2003, MCITP: EDA7, MCITP: EDST7, MCITP: EST Vista, MCTS: Exh 2010, MCTS:ServerVirt, MCTS: SCCM07 & SCCM2012, MCTS: SCOM07, MCTS: Win7Conf, MCTS: VistaConf, MCDST, MCP, MBCS, HND: Applied IT, ITIL v3: Foundation, CCA
  8. ManishBehal

    ManishBehal New Member

    6
    0
    18
    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.
     
    Certifications: CCIE,CCNP,CCDA,CCNP,MCSE,MCSA,MCDST,MCT
    WIP: CCIE Security,
  9. Fergal1982

    Fergal1982 Petabyte Poster

    4,196
    172
    211
    help: Good. Necroposting: Bad! (Fire: Bad! :biggrin)

    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.
     
    Certifications: ITIL Foundation; MCTS: Visual Studio Team Foundation Server 2010, Administration
    WIP: None at present
  10. Qs

    Qs Semi-Honorary Member Gold Member

    3,081
    70
    171
    Indeed, and we're all for that! :D

    Fergal's point is that the OP isn't going to be looking at this anymore and nor is anyone else.
     
    Certifications: MCT, MCSE: Private Cloud, MCSA (2008), MCITP: EA, MCITP: SA, MCSE: 2003, MCSA: 2003, MCITP: EDA7, MCITP: EDST7, MCITP: EST Vista, MCTS: Exh 2010, MCTS:ServerVirt, MCTS: SCCM07 & SCCM2012, MCTS: SCOM07, MCTS: Win7Conf, MCTS: VistaConf, MCDST, MCP, MBCS, HND: Applied IT, ITIL v3: Foundation, CCA

Share This Page

Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.