lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <12180965.1079615806@[10.3.62.6]> From: pbieringer at aerasec.de (Dr. Peter Bieringer) Subject: Trend Micro has problems with their activeupdate server Hi, sure interesting for administrators of Trend Micro Interscan Viruswall or IMSS. In general, pattern update server should be very reliable, especially in case of need for pattern updates because of a new worm is spreading... Since longer we have problem on a customers installation with reliability of the pattern update process. E.g. on Interscan Virus Wall Linux 3.8 "prescan.cgi" (triggered by cron) reports "error 28". This error is caused by a missing file on the Akamai servers (TM is using them for distributing updates): http://isux-t.activeupdate.trendmicro.com/activeupdate/server.ini sometimes returns: HTTP/1.0 404 Not Found BTW: another administrator (using IMSS) reports me that HTTP error 500, 502 and 504 also occurs sometimes. isux-t.activeupdate.trendmicro.com is directed to an Akamai server: isux-t.activeupdate.trendmicro.com. 496 IN CNAME trendmicro.georedirector.akadns.net. BTW: for ISVW, if you want to retrieve information, why your update process fails, enable debugging: 1. Edit aucfg.ini 2. Look for [debug] then set the following parameters level=1 log_mode=2 Debug file /etc/iscan/Au_log/tmudump.txt contain the full HTTP header lines of request and reply. After a long time of discussion with the support of TM (they longer wanted to convince me that the problem is on client side...I didn't believed that after I looked in the debug log for the first time), I finally got a *clear answer* from Trend Micro support, in short they told me, it can happen that an update fails with HTTP error 404 (sure, the debug log tells this also...). Support told me also that this can happen if many new patterns are published in short time range, which overloads (?) the activeupdate server. Mho: Either Akamai has a synchronisation problem here (does anybody know how they sync) or TM delete the file, Akamai syncs (which removes the file temporary), TM pushes the file again, Akamai syncs again. Support told me also, as a workaround I should reduce the cycles for pattern check to e.g. each 10 minutes (easy to do by modifiying the crontab entry). Mho: if everyone does this, the pattern server will have next problems, namely request overloads... Looks like this problem can't be really solved shortly by TM, so users of at least the Linux/Unix products of Trend Micro running pattern update cycles per server have to live with this issue for now. Any comments or same experience on that issue by anyone else? BTW: common known is update server overload problems to full hour times (many Unix/Linux boxes are synced via NTP), any admin should replace "0" in crontab by a "random" value between "1" and "59" for process "prescan.cgi". File "/var/spool/cron/root" eg. 11 * * * * /etc/iscan/prescan.cgi instead of 0 * * * * /etc/iscan/prescan.cgi Peter -- Dr. Peter Bieringer Phone: +49-8102-895190 AERAsec Network Services and Security GmbH Fax: +49-8102-895199 Wagenberger Stra?e 1 Mobile: +49-174-9015046 D-85662 Hohenbrunn E-Mail: pbieringer@...asec.de Germany Internet: http://www.aerasec.de
Powered by blists - more mailing lists