Thanks for all the help and not telling me to RTFM or "Google it" which is likely what my response would've been to my question.
I find the sigtool not very helpful at times, piping the find-sigs to --decode-sigs gives little information, I've only gotten things like: ERROR: decodesig: Invalid or not supported signature format TOKENS COUNT: 3 or something that only spits back out the signature but labels it VIRUS NAME. It would be nice if sigtool would spit out something like, "This is a Trojan.Dropper exploit" but that's likely due to the signature submitter and not clamAV and I get that. Is there anything more on sigtool, I tried to find information on getting useful information from FOUND matches against the VSD? Also, is there any significance to which database a signature was matched against, e.g. someone stated that Win.Trojan.Agent-793284 matches the main.mdb but another Win.Trojan.Ramnit-6152 matches the daily.mdb so other than telling me that a daily match might be a more recent signature, any other information you can glean from that distinction? Thanks, Brad On Thu, Feb 9, 2017 at 1:20 PM, G.W. Haywood <[email protected]> wrote: > Hi there, > > On Thu, 9 Feb 2017, Brad Scalio wrote: > > Clamscan found a PE "visor.exe.svn-base" ... Win.Trojan.Agent-793284 FOUND. >> ... >> 11 of 56 scanners detect a signature, however the file in question is on a >> linux system, and hasn't been touched since 2010, and so I am not too >> worried as ... >> > > It would have helped to know what you think this file is, and where. > > On points of order, firstly, how do you know that the file hasn't been > touched since 2010? If you just looked at the output of 'ls' that > doesn't tell you as much as you might think it does. If I were going > to compromise a Linux box, I'd take great care to hide what I'd done. > Amongst other things I'd save the 'last access', 'last modification' > and other information about any files that I intended to modify, and > afterwards change the timestamps back to what they were before I did > my dirty work on them. However there are tools like 'Tripwire' which > will actually read all the files on the machine and store a protected > database of information about them, so that you can say for sure if a > file has or has not been tampered with. Secondly, do you know what > the file is doing there? If it's something that a 'customer' (however > you define 'customer') has put there, is this customer either abusing > your services or perhaps even at risk from them? Don't be complacent. > On the other hand, be rational. I haven't seen a compromised Linux > box since the 20th century, although I might need to get out more. > > it's a homogeneous local LAN of all linux systems, it's just the >> first time we've ran a clamscan on this box. >> > > If you think there's any risk, there are many more useful things you > might do on Linux boxes than installing ClamAV, such as installing a > few tools (if they aren't there already), like 'iptables', 'tcpdump', > 'ntop', and 'p0f'. And 'Tripwire' of course, and maybe 'rkhunter'. > Take a keen interest in your network traffic. Monitor it for changes > in patterns, unusual traffic, traffic from unusual locations, etc. > Take a keen interest in firewall configurations. Review them often. > Keep logs. Look at them. I spend probably ten percent of my working > day looking at traffic logs. Some box in Romania tried to get into > one of my networks 195 times today until I tarpitted it: > > iptables -A dynamic_tarpit -j TARPIT -p tcp -s 89.46.82.78 # extremely > persistent blood sucker > > Is there a way, or an online tutorial, or some other information to >> decompose the signature and the file easily to determine if it's a false >> positive or not? I realize this is a complete science ... >> > > It depends very much (*) on what the file is and where it is, but I'm > guessing that unless you're storing data for Windows users there's not > much chance that it's anything other than false positive. Rather than > being left where it is, I guess that the file could probably have been > moved to a 'quarantine' location, with little or no adverse impact, > until you've investigated. But see (*) above once again. > > but I am looking for a way for our tier 0 folks to quickly discern >> if they need to wake up the whole enterprise at 3am in the future. >> > > They likely don't need to do that unless there's been an earthquake. > > You need to train the people who will be monitoring your systems how to > react to what they find. They certainly don't need to do call 911 for > anything that ClamAV finds on a Linux box. If you exercise reasonable > care, you can probably forget about scanning Linux systems with ClamAV > unless you're using the systems to store data from Windows boxes, and > in that case you'll need a lot more than just ClamAV. In my experience > ClamAV is only marginally useful for scanning Windows files and useless > for scanning Linux boxes. > > -- > > 73, > Ged. > > _______________________________________________ > clamav-users mailing list > [email protected] > http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml > _______________________________________________ clamav-users mailing list [email protected] http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
