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
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.
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?
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.
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
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...