Remove ICMP Timestamp Request on Cisco 837

Unanswered Question
Jul 18th, 2007

We have a few Cisco 837's working as L2L's. I have scanned them for vulnerabilities, and received this message, and need jelp to remove it:

ICMP Timestamp Request:

THREAT:

ICMP (Internet Control and Error Message Protocol) is a protocol encapsulated in IP packets. It's principal purpose is to provide a protocol layer able to inform gateways of the inter-connectivity and accessibility of other gateways or hosts. "ping" is a well-known program for determining if a host is up or down. It uses ICMP echo packets. ICMP timestamp packets are used to synchronize clocks between hosts.

IMPACT:

Unauthorized users can obtain information about your network by sending ICMP timestamp packets. For example, the internal systems clock should not be disclosed since some internal daemons use this value to calculate ID or sequence numbers (i.e., on SunOS servers).

SOLUTION:

You can filter ICMP messages of type "Timestamp" and "Timestamp Reply" at the firewall level. Some system administrators choose to filter most types of ICMP messages for various reasons. For example, they may want to protect their internal hosts from ICMP-based Denial Of Service attacks, such as the Ping of Death or Smurf attacks.

However, you should never filter ALL ICMP messages, as some of them ("Don't Fragment", "Destination Unreachable", "Source Quench", etc) are necessary for proper behavior of Operating System TCP/IP stacks.

It may be wiser to contact your network consultants for advice, since this issue impacts your overall network reliability and security.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Wed, 07/18/2007 - 10:48

Andy

I am not aware of any way to disable the ICMP timestamp messages in the router - and the material that you quote does not advocate that the messages be disabled. It does suggest that they could be filtered (it would make the most sense to filter them at the edges of the network).

The logic to filter them is easy to do in an extended access list:

access-list 101 deny icmp any any timestamp-request

access-list 101 deny icmp any any timestamp-reply

you could include these lines in any access list that is examing traffic entering your network.

If you are interested in information about the various types of ICMP messages this link has a very nice chart of them:

http://www.iana.org/assignments/icmp-parameters

HTH

Rick

whiteford Thu, 07/19/2007 - 01:59

I already have this line below, will it be a problem?

access-list 101 permit ip 172.20.3.0 0.0.0.255 any

Richard Burts Thu, 07/19/2007 - 09:53

Andy

Some information about how that access list is used, in particular is this one line the entire ACL, on which interface and in what direction is it applied, would help me give you a better answer.

If this is the entire ACL then I would assume that it was probably applied inbound on the interface where the 172.20.3.0 subnet is connected and is used as an anti-spoofing mechanism. If that is the case I doubt that ICMP timestamps would be an issue. But if you do want to filter the ICMP timestamps then the lines that I suggested need to come before the line that you gave in the ACL.

If my assumption is not correct then please clarify.

HTH

Rick

whiteford Sun, 07/22/2007 - 23:26

It's mainly on the outside interface, with info can I give you please. I really want to fix this.

Richard Burts Mon, 07/23/2007 - 05:29

Andy

I asked several questions that you did not answer, including:

- is the one line you posted the entire access list or are there other lines?

- is the access list applied inbound or outbound?

It would also help to know a bit about the topology of the network. In particular where (and what) is network 172.20.3.0?

HTH

Rick

whiteford Mon, 07/23/2007 - 06:05

Inbound, I scanned the Internet facing IP, here is the config:

username x password 7 hA0j23

no aaa new-model

ip subnet-zero

ip dhcp excluded-address 172.19.3.1 172.19.3.10

!

ip dhcp pool client

network 172.19.3.0 255.255.255.0

default-router 172.19.3.1

lease 0 2

!

!

ip inspect name outbound tcp

ip inspect name outbound udp

ip inspect name outbound ftp

ip inspect name outbound http

ip inspect name outbound icmp

ip audit notify log

ip audit po max-events 100

no ftp-server write-enable

!

!

!

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key 0 x address x.x.x.173

!

!

crypto ipsec transform-set set esp-3des esp-md5-hmac

!

crypto map vo_t_set 10 ipsec-isakmp

set peer x.x.x.173

set transform-set set

match address 101

!

!

!

!

interface Ethernet0

ip address 172.19.3.1 255.255.255.0

ip inspect outbound in

hold-queue 100 out

!

interface ATM0

no ip address

no ip unreachables

no atm ilmi-keepalive

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

!

interface Dialer1

ip address negotiated

ip access-group inbound in

no ip unreachables

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap pap callin

ppp chap hostname [email protected]

ppp chap password 7 7404123282179

crypto map set

!

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

no ip http server

no ip http secure-server

!

!

ip access-list extended inbound

permit udp any any eq isakmp

permit esp any any

permit icmp any any

permit udp any any eq ntp

permit tcp x.x.x.64 0.0.0.31 any eq telnet

permit tcp x.x.x.64 0.0.0.31 any eq 22

permit tcp x.x.x.64 0.0.0.31 any eq ftp-data

permit tcp x.x.x.64 0.0.0.31 any eq ftp

permit tcp x.x.x.64 0.0.0.31 any eq www

permit tcp x.x.x.64 0.0.0.31 any eq 443

permit ip 192.168.90.0 0.0.0.255 172.19.3.0 0.0.0.255

logging trap warnings

logging facility local4

logging source-interface Ethernet0

access-list 50 permit x.x.x.66

access-list 101 permit ip 172.19.3.0 0.0.0.255 any

dialer-list 1 protocol ip permit

!

line con 0

no modem enable

line aux 0

line vty 0 4

access-class 50 in

exec-timeout 0 0

login local

length 0

!

scheduler max-task-time 5000

sntp server 158.43.128.33

!

end

Richard Burts Mon, 07/23/2007 - 06:27

Andy

Thanks for posting the config. It helps to see what the router is doing. To answer your specific question about access list 101, I note that access list 101 is used in the crypto map. Its function in the crypto map is to identify traffic to be protected by IPSec. To that extent there is no relationship between access list 101 and the issue of ICMP timestamp request and response. If you want to address that issue you would need to put 2 statements into access-list extended inbound to deny those ICMP messages.

I also note that Cisco recommends that access lists used in crypto maps generally not use "any" as one of the address specifications. Your access list 101 does this. You might want to think about re-writing that part of the config.

HTH

Rick

whiteford Mon, 07/23/2007 - 06:29

Thanks Rick, can you give me an example to the 2 statements I need to add, sorry it's all a bit new to me, I have a couple of routers to apply this to before I send out.

Thanks

Richard Burts Mon, 07/23/2007 - 11:19

Andy

Under ip access-list extended inbound you should add:

deny icmp any any timestamp-request

deny icmp any any timestamp-reply

you should be sure that these lines are inserted before the statement for permit icmp any any otherwise they will not work.\

HTH

Rick

whiteford Mon, 07/23/2007 - 23:17

Thank before I do this, I need to be able to ping the inside IP of the router to tell if the router is up (Monitoring software), will this effect that?

Richard Burts Tue, 07/24/2007 - 06:27

Andy

The changes that I suggested only affect the timestamp request and timestamp response. They should have no impact on ability to ping the inside interface.

HTH

Rick

whiteford Tue, 07/24/2007 - 11:17

Great I will try this and let you know and rate.

Many thanks

whiteford Wed, 07/25/2007 - 06:10

Hi,

I added:

deny icmp any any timestamp-request

deny icmp any any timestamp-reply

But they appear after the permit icmp any any, how can I change this?

Richard Burts Wed, 07/25/2007 - 12:53

Andy

New statements in an access list are added at the bottom of the access list (unless you are using the feature which numbers lines in the access list). So what you would need to do is to delete the access list and then recreate the access list with the new statements in the right position. Or you could leave the existing access list, create a new access list with the new statements in the right order and then assign the new access list on the interface.

HTH

Rick

whiteford Wed, 07/25/2007 - 21:59

Hi, just a couple of questions regarding this.

If I delete the access list won't I lose connection as I'm remotely connected? Or will this only happen if I do a wr mem?

If commands are only added in the order I out them, couldn't I just delete the permit ICMP any any and add the 2 deny ICMP rules then re-add the permit ICMP any any?

Richard Burts Thu, 07/26/2007 - 07:24

Andy

If you are telnetted to the router and then make changes on the access list assigned to that interface then yes there is a good chance that you may lose your connection. This would be a good reason to use the approach that I suggested of creating a new version of the access list with a new name, put the statements in the order that you need them, and then change the access-group on the interface. If you do this it should not impact your telent session.

HTH

Rick

whiteford Sat, 07/28/2007 - 05:17

To make sure I am doing this right, what is the name of my current access-list, I have jsut uploaded this config from another router to this one? and once I've created a new list what areas should I change to make this access list the one to use so I can delete the other one?

Also if I do all this and don't do a "wr mem" and someone restarts the router will it go back to the earlier settings? Just a backup plan.

Richard Burts Sat, 07/28/2007 - 16:42

Andy

I suggest that you use this. It should work.

Yes you are correct that if you paste this into the config and you do not do a write mem (or a copy run start) and if the router restarts it will go back to the old settings for the ACL.

!

ip access-list extended inbound_acl

permit udp any any eq isakmp

permit esp any any

deny icmp any any timestamp-request

deny icmp any any timestamp-reply

permit icmp any any

permit udp any any eq ntp

permit tcp x.x.x.64 0.0.0.31 any eq telnet

permit tcp x.x.x.64 0.0.0.31 any eq 22

permit tcp x.x.x.64 0.0.0.31 any eq ftp-data

permit tcp x.x.x.64 0.0.0.31 any eq ftp

permit tcp x.x.x.64 0.0.0.31 any eq www

permit tcp x.x.x.64 0.0.0.31 any eq 443

permit ip 192.168.90.0 0.0.0.255 172.19.3.0 0.0.0.255

!

interface Dialer1

ip access-group inbound_acl in

!

Give this a try and let us know how it works.

HTH

Rick

whiteford Sat, 07/28/2007 - 22:56

Then just delete the old config?

Also is it easy to update the firmware remotely?

whiteford Sun, 07/29/2007 - 00:32

...Also if I add "ip access-group inbound_acl in" will this remove my old one straight away or can you have 2 access groups running? I was think of adding the new access list first then the last part I will change the access group to inbound_acl

If it goes wrong and I lose connection I'll get someone to restart the router.

Richard Burts Sun, 07/29/2007 - 18:07

Andy

If you do add "ip access-group inbound_acl in" it will immediately remove the old access-group and begin using the new access-group. You may have only a single IP access-group per direction per interface.

One advantage of this approach is that it immediately begins using the new access-group but leaves the old access-list in place so that you can go back to it if there is a problem with the new access-list.

Another aspect to consider is to consider scheduling a reload before you make the config change to change the access-group. There is an option of the reload command to schedule a reload of the router. So you could use:

reload in 30

to schedule a reload in 30 minutes (or pick whatever time interval you want). This will schedule a reload in 30 minutes. So you would schedule a reload, then you make the config change. If there is a problem with the config change and you lose connectivity to the router you wait for the reload. Since your config change was not saved to NVRAM the reload rverts to the original config and you have access again (without needing to call someone at the remote site). If the config change was good and there are no problems, then you use the command:

reload cancel

sometime before the scheduled reload and then you save your config change.

I would suggest that when you make this kind of config change that you leave the original access-list in the config for some period of time (just in case you need to revert back). And then after some period of time you remove the old access-list from the config.

Whether it is easy to update the firmware remotely depends a bit on your environment. (Just to clarify I assume that when you refer to update firmware that you are refering to updating the image code that the router is running and not referring to updating the bootrom or something) Depending on the plarform most routers store their image in flash. If your flash has enough capacity to store 2 images then it is fairly easy to copy a new image to flash, resulting in 2 images in flash. You then put commands into the config file to boot from the new image and to use the old image if there is a problem in booting the new image. This is fairly straightforward and easy. If there is room in flash for only a single image then you need to erase the old image before copying the new image. This can be done remotely but does have a somewhat higher degree of risk.

HTH

Rick

whiteford Sun, 07/29/2007 - 21:57

Thanks Rick.

Some really good tips for someone new like me.

I created the new access list and added it to the dialer and stayed connected I then ran a vulnerability test and that vulnerability has gone! I have removed the. Old access list but have try to wr to mem. Wish I'd waited for your post.

I have one last vulnerability on another Cisco 837 but will create a new post.

I have a tftp server that's it, I really don't know where to start on updating it. I think I mean image or ios. I find newer 837 are much better for snmp stuff than older ones, hope you can help.

whiteford Mon, 07/30/2007 - 00:04

The outbound access list is bound to the ethernet 0, what is it's job?

Forgot to say this si the show version:

Cisco Internetwork Operating System Software

IOS (tm) C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

Synched to technology version 12.3(1.6)T

TAC Support: http://www.cisco.com/tac

Copyright (c) 1986-2003 by cisco Systems, Inc.

Compiled Fri 08-Aug-03 05:58 by ealyon

Image text-base: 0x800131E8, data-base: 0x80B8F3D8

ROM: System Bootstrap, Version 12.2(8r)YN, RELEASE SOFTWARE (fc1)

ROM: C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

fl1tw1ck uptime is 1 week, 3 days, 18 hours, 33 minutes

System returned to ROM by power-on

System restarted at 12:49:07 UTC Thu Jul 19 2007

System image file is "flash:c837-k9o3y6-mz.123-2.XA.bin"

CISCO C837 (MPC857DSL) processor (revision 0x500) with 44237K/4915K bytes of memory.

Processor board ID AMB08160J61 (2211829433), with hardware revision 0000

CPU rev number 7

Bridging software.

1 Ethernet/IEEE 802.3 interface(s)

1 ATM network interface(s)

128K bytes of non-volatile configuration memory.

12288K bytes of processor board System flash (Read/Write)

2048K bytes of processor board Web flash (Read/Write)

Configuration register is 0x2102

fl1tw1ck#$O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

IOS (tm) C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELE^ASE SOFTWARE (fc1)

Richard Burts Mon, 07/30/2007 - 05:50

Andy

The access list used on the Ethernet interface is used in conjunction with these ip inspect commands which are part of your configuration:

ip inspect name outbound tcp

ip inspect name outbound udp

ip inspect name outbound ftp

ip inspect name outbound http

ip inspect name outbound icmp

The IP inspect looks at traffic originating from end stations on the Ethernet interface and creates dynamic entries in the ACL on the outside interface to create entries allowing response traffic. This is part of providing an enhanced security implementation on your router.

HTH

Rick

whiteford Mon, 07/30/2007 - 05:56

Thanks Rick, you said:

Whether it is easy to update the firmware remotely depends a bit on your environment. (Just to clarify I assume that when you refer to update firmware that you are refering to updating the image code that the router is running and not referring to updating the bootrom or something) Depending on the plarform most routers store their image in flash. If your flash has enough capacity to store 2 images then it is fairly easy to copy a new image to flash, resulting in 2 images in flash. You then put commands into the config file to boot from the new image and to use the old image if there is a problem in booting the new image. This is fairly straightforward and easy. If there is room in flash for only a single image then you need to erase the old image before copying the new image. This can be done remotely but does have a somewhat higher degree of risk.

This is my "show Version", it seems newer routers we by are much better on SNMP for monitoring, I just want to update the old one sliek this:

Cisco Internetwork Operating System Software

IOS (tm) C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

Synched to technology version 12.3(1.6)T

TAC Support: http://www.cisco.com/tac

Copyright (c) 1986-2003 by cisco Systems, Inc.

Compiled Fri 08-Aug-03 05:58 by ealyon

Image text-base: 0x800131E8, data-base: 0x80B8F3D8

ROM: System Bootstrap, Version 12.2(8r)YN, RELEASE SOFTWARE (fc1)

ROM: C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

fl1tw1ck uptime is 1 week, 3 days, 18 hours, 33 minutes

System returned to ROM by power-on

System restarted at 12:49:07 UTC Thu Jul 19 2007

System image file is "flash:c837-k9o3y6-mz.123-2.XA.bin"

CISCO C837 (MPC857DSL) processor (revision 0x500) with 44237K/4915K bytes of memory.

Processor board ID AMB08160J61 (2211829433), with hardware revision 0000

CPU rev number 7

Bridging software.

1 Ethernet/IEEE 802.3 interface(s)

1 ATM network interface(s)

128K bytes of non-volatile configuration memory.

12288K bytes of processor board System flash (Read/Write)

2048K bytes of processor board Web flash (Read/Write)

Configuration register is 0x2102

fl1tw1ck#$O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

IOS (tm) C837 Software (C837-K9O3Y6-M), Version 12.3(2)XA, EARLY DEPLOYMENT RELE^ASE SOFTWARE (fc1)

Richard Burts Mon, 07/30/2007 - 06:24

Andy

Cisco routers certainly support remote update/upgrade of the software image. To know whether it is easy or not we need some additional information: how much flash do you have, how much flash is currently used, how much flash is available, how much flash is needed for the new image (how big is the image)? If you post the output of show flash on this 837 we will get answers to the first several questions, and if you have the desired new image on a tftp server (or on another existing router) you can find what size the new image is.

HTH

Rick

whiteford Mon, 07/30/2007 - 06:28

I have yet to find or download the new version, my account for some reason doesn't have access (speak to my account manager):

System flash directory:

File Length Name/status

1 6171780 c837-k9o3y6-mz.123-2.XA.bin

[6171844 bytes used, 6148924 available, 12320768 total]

12288K bytes of processor board System flash (Read/Write)

Richard Burts Mon, 07/30/2007 - 07:18

Andy

Based on this information I believe that we can guess that the remote upgrade will be possible but with some risk. The flash appears to be 12 MB size. Of the available space 6171844 is used for the existing image file and 6148924 is available. Since the available space is slightly less than the existing image and since the new image is likely to be larger than the existing image, it is a safe guess that there is not enough room in flash for both images. So to do the upgrade you will need to erase the existing image in flash, and then copy the new image into flash. The router will still run with the image erased in flash, but if the router reloads for any reason before you get the new image into flash then you would have a broken router.

As I see it you have several options:

- accept the risk and do the remote upgrade.

- go to where the router is located and do the upgrade as a local upgrade.

- if you have a spare 837, you could put the new image on the spare 837, use that router to replace the 837 in the remote location, and bring that 837 back to where you are to do a code upgrade on it.

Which of these choices is best depends on you and your organization and your acceptance of a degree of risk.

HTH

Rick

whiteford Mon, 07/30/2007 - 07:22

Thanks Rick,

If I do a local upgrade, what commands will I need to use?

Richard Burts Mon, 07/30/2007 - 10:00

Andy

The commands you use to do the upgrade would be the same whether it was a local upgrade or a remote upgrade. You access the router (via telnet or via console if you are local) and "copy tftp: flash:" to copy the new image into flash. The copy process will prompt you for the address of the tftp server, the file name of the image file, and whether to erase the content of flash, and then will do the copy. The thing about doing it as a local upgrade is that if something goes wrong in the upgrade process that you still have local access to the router to recover from the problem. Also if you are doing it as a local upgrade it is advantageous to have the image file on the hard drive of your PC and to have a tftp server installed on your PC so that you can do the tftp copy as a local LAN copy rather than using the wide area network to do the copy.

HTH

Rick

whiteford Mon, 07/30/2007 - 10:57

Hi Rick, once its been copied across do I need to execute to be installed?

Thanks

Richard Burts Mon, 07/30/2007 - 11:03

Andy

Once the new image has been copied into flash (and assuming that it is the only image in flash) you do not have to do anything else. When the router restarts (from reload command, or from power cycle, or from some other cause) the router will load and execute the new image code.

HTH

Rick

whiteford Mon, 07/30/2007 - 13:00

Great Rick, if there isn't enough space, do I need to delete what's already in the flash memory?

Richard Burts Mon, 07/30/2007 - 13:49

Andy

In general yes if there is not enough space you would delete what is already in flash to make room. From one of your earlier postings this is what is in your flash:

System flash directory:

File Length Name/status

1 6171780 c837-k9o3y6-mz.123-2.XA.bin

[6171844 bytes used, 6148924 available, 12320768 total]

12288K bytes of processor board System flash (Read/Write)

and it indicates that the image file is the only thing in flash. The copy process can take care of that, so I would not suggest that you manually attempt to delete anything.

HTH

Rick

whiteford Mon, 07/30/2007 - 21:40

Thanks Rick, ill give that a go.

It seems no one uses the adsm GUI on these 837's, since getting one out of the box and making so many changes I can't get back on the adsm is this normal0and is the adsm updated Ruth a newer image?

Actions

This Discussion