IPS Signature updates from Cisco FTP

Unanswered Question
Mar 31st, 2009

It looks like Cisco stopped posting the new signatures on their FTP in cisco/ciscosecure/ips/6.x/sigup as of the end of Feb. As a result the update script is not updating the IPSs any longer. I could not find any advisory about that on CCO. If someone could shed some light on Cisco's plans to resume the FTP access at some point or shut it down


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
marcabal Wed, 04/01/2009 - 07:11

What update script are you referring to?

Was this a customer built script or was this built within a Cisco product?

I don't have all of the details, but I do know that the update location for files on cisco.com has changed, and the method to access those files through cisco.com has changed.

Cisco products supporting an auto update feature should still continue working with the new file access.

If this is a script within a Cisco supported product that is not working now, then please contact the TAC to alert them to the issue.

If this is a customer created download script, then direct access to the FTP server was not officially supported.

I am not sure if the team handling the download changes was aware that some users might have their own scripts for downloading updates.

I will check with the team to see what their response might be.

What IPS version are you running?

And what are you using for managing the sensors?

IPS version 6.1 supports automatic downloads from cisco.com for signature and engine updates.

And CSM also supports automatic downloads from cisco.com.

dmitry Wed, 04/01/2009 - 19:01

Thanks for your feedback, it is a custom script that use to go to the Cisco's FTP once a day to check for the new signatures (just the directory listing) and only if there was a new one available, would get it and copy it to a local FTP for the sensors to pick up.

IPSs are ASA SSM-20s with 6.2.1.

The script was providing a bit more of the control (it would also download the correspondent README and send it via email to the admins, so if they decide it is ok to have this signature deployed, they will simply reply to the email and the script would make it available to the sensors), there were cases where bad signatures caused traffic interruptions on the inline sensors.

I do not think the sensors would use the same CCO user interface (the new, full of javascripts) to navigate their way to the signature storage, some kind of xmlrpc / soap maybe?

marcabal Thu, 04/02/2009 - 06:55

Correct that the sensors use a different URL for connecting to cisco.com. They connect to cisco.com and pass in information about the sensor, and cisco.com returns a list of URLs for downloading the latest update files.

I am sending out emails internally to see what the download team's response is.

Was there a specific Cisco engineer that you worked with to create this custom script?

tschunk Thu, 04/02/2009 - 04:33

so we are not the only ones having problems

we are using

Cisco Intrusion Prevention System, Version 6.2(1)E3


Realm Keys key1.0

Signature Definition:

Signature Update S378.0 2009-01-22

Virus Update V1.4 2007-03-02

OS Version: 2.4.30-IDS-smp-bigphys

Platform: ASA-SSM-20

IME has this URL included


I also tried this one


but evertime there is HTTP Error 400 or 500

Thank you in advance for your feedback

marcabal Thu, 04/02/2009 - 06:45


I think your problem is separate from Dmitry's issue.

It sounds like your sensors configured for cisco.com auto updates are not able to pull updates from cisco.com; but Dmitry's problem is that his personal scripts (not the sensors) are unable to pull down signature updates because the updates are moved to a different location on cisco.com.

You need to use the default URL for the cisco.com automatic updates. The other one you tried is for the old location of the updates. The files are no longer located at the old location, and the sensors were never coded to check that old location. The output is different for the 2 URLs.

Here are some things you might consider for debugging your autoupdates.

1) Change the configuration so it uses the original default URL for the downloads.

2) Change the download time to be a few minutes after the hour like say 1:13 instead of 1:00. By default all sensors wind up trying the download exactly on the hour. This winds up with thousands of sensors connecting to cisco.com all at the same time. We are starting to see connection issues when this happens. Changing your sensor to connect at an odd time will help prevent your sensor from having connection issues.

3) Ensure that the sensor is actually able to connect directly to cisco.com. Many customers have Proxy servers or web accelerators sitting between the sensor and the internet. The sensor will not work through a proxy, and we have seen web accelerator programs mess up the connection as well.

4) Use your own desktop to connect to cisco.com and download the latest service pack using the same cisco login and password that you configured your sensor to use. This will ensure that the cisco login account has full access to IPS files. If you can't download the latest service pack with that login account, then it can't be used for the auto updates.

5) For more help in troubleshooting you could execute "show statistics host" on your sensor, and paste the output into a Forum post. There may be something in the statistics output that someone else may have seen and be able to offer additional troubleshooting advice.

6) If you can't troubleshoot it with help form the Forum, then you may need to open a TAC case.

dmitry Thu, 04/02/2009 - 19:07

The script was a modified (does not check what sig is on IPS, rather what is the latest on the local FTP) version of the one available at http://www.lhb-consulting.com/pages/apps/IPSUpdate_Tool_article.html, perl based, uses Net::FTP perl module to get the FTP directory listing and download a sig file, with sendmail integration for the signature deployment approval via reply



This Discussion