Hi Guys,
My file server has been infected by w32.svich and it creates about hundreds of thousands of this foldername.exe file. How can I delete these files automatically and how can I prevent my server from this virus again? I already did this http://www.symantec.com/security_response/writeup.jsp?docid=2007-062911-2859-99&tabid=3 so please give a better one. My current version is SEP 11 without NTP.
Regards,
N
Hello
I have not found the version of 11.x which compitble for Win-8. Kindly some one confirm that one.
Hi,
I am using symantec endpoint protection 12.1. I need that cd/dvd can read only, user cannot write data to cd/dvd via copy paste or third party applications like nero demon tools etc.
Thanks
Jimesh Makawana
non of default or user defiend content filtering rules working , Content filtering feature is enable.
no error message in Windows Events or SMSMSE logs.
SMSMSE 7 installed on all Servers with Trial License.
Vmware Workstation 9.0.2
Exchange 2010 SP3 / WS 2008 R2 SP1
DAG with 2 MB Server , 2 NLB nodes ( CAS-HT)
Hello experts. I am new on this forum. how to install pgp on windows system.
Dear Sir/Madam,
I run below command but don't understand why it displayed an error "invalid date" even I typed the correct date format. Please advise how to fix the error.
pgp --set-expiration-date MYKEY --expiration-date 2018-06-01 --passphrase TESTING
Thanks & Regards,
Florence
Hello symantec team.
what are the different browsers that symantec vontu DLP support.
please provide me solution.
thanks in advance.
My Vodafone 3G dongle (a Huawei K3770) works fine on my Lenovo laptop, which runs Windows 7 - but only if Network Protection in Symantec Endpoint Protection is disabled. As soon as Network Protection in SEP is enabled, the 3G stops working: I can log on and off from the service, but I cannot access any websites using IE, Firefox or Chrome, cannot ping any sites or servers, and cannot log on to my company VPN. All these things work fine if Network Protection is disabled.
I'm using the latest version of Vodafone Mobile Connect (10.3.401.43721) and SEP version 11.0.7101.1056. SEP shows that the Vodafone Mobile Connect is 'allowed' and incoming and outbound traffic is enabled. I've put every IP address I can think of in the SEP Firewall as 'trusted sites' but have not put any additional information in the TCP or UDP slots.
I've uninstalled and reinstalled Symantec Endpoint Protection, Vodafone Mobile Connect, and ThinkAdvantage Access Connections several times, programs I thought might be clashing with the Vodafone service. I've tried pointing the Vodafone connection to the Google DNS servers instead of Vodafone's. None of this works.
Please do any of you clever people out there have any suggestions on how I might be able to overcome this ?
Many thanks in advance for any feedback !
hi, I am using an win7 64-bit laptop with i7 cpu, but when I try to deploy a 12.1.1 client with SEPMC, it failed.
And when I export a setup package to install, a dialog box shows up with some sort of "time remaining 0 min" then the box just disappear.
And then I run the setup again, it asks me to reboot my laptop, but after I restart it, same thing happens.
Could anyone help me with this issue? Thanks!
We have installed Symantec/Vontu DLP 11.6 on a Windows server 2008 (x64) R2 box and I'm trying to figure out how to search through/capture unauthorized downloads.
Hello:
We are using LiveUpdate Administrator 2.3.1 {due to security policies} to pull in updates from Symantec which then distributes the updates to 3 SEPMs. Clients then receive updates via the SEPMs or the LUA. Within the past few days, I noticed that the following log file grows to Gigs in size. So much so, that it ate up the remaining 25gigs of space on the drive over the weekend.
C:\Program Files\Symantec\LiveUpdate Administrator\tomcat\logs\local_access_log.2013-xx-xx.txt
Contents of log file include items such as:
[IP Address] -- [Date/Time] "GET /clu-prod/1376697804jtun_sepc130814011-130816011.x86
Is there a way to control this type of logging?
Also, is it safe to delete older entries of these file types in the ...\tomcat\logs folder?
Thank you,
Anthony
We have upgraded our SEPM server to 12.1 and all is well. All our clients and GUPs are 11.0.7.
Should we upgrade GUPs first so they can pull the AV defs, and will they pull both 12 and 11 AV defs?
and at the end after it updated the catalogs, i pressed next more than once, as it was stuck...and it blew through the last 1 or 2 dialog screens...
one of which said to make sure i installed something somewhere...thinking it might have been the endpoint client on the sepm server?
can someone from symantec tell me what it was warning me about...
Hi,
My company purchased Symantec Endpoint protection 12.1 Server with 1000 clients licenses I am responsible for the deployment in my environment so I need to know the following points:
1.How to identify what kind of services we can get from our license document for e.g Technical support in case of any issue we have pre & post installation of the Antivirus server. in terms of what are the primary point of conatcts and their details and the process to follow for creating Tickets.
2.Contact details of Global support and in India as well please mention any relevant document through which I can get the information regarding the process to follow for geting services from symantec.
Regards
Geekgadget
Contributor: Sujay Kulkarni
The Ashes Test cricket series, one of most popular Test series in cricket, is played between England and Australia. It is played alternately in England and Australia and is the oldest test rivalry between these two sides. Cricket fans are glued to the TV and their online devices to watch this riveting series.
In the current Ashes series England is leading 3-0 and is on the cusp of creating history against Australia—if they beat them hands down in the last test match, which now is a real possibility. However, what is making the rounds is not Scholes, Carrick, or Robin Van Persie, but Captain Cook and his elite squad waiting to steamroll Australia.
This interesting scenario has got scammers smacking their lips. They have come up with a trick to lure you into sending them your personal information over email because your email address has won "242,500,000 USD in the 2013 ASHES SERIES".
Here is the catch, you have one obligation to fulfill by replying back to the scammer with your "personal details". Well, that would set the ball rolling for the scammer, wouldn't it?
In a typical 419 spam, the scammer mentions in the email that you have won—an award of $50,000 USD for example—and asks you to reply back with your personal details, immediately to claim the money.
Symantec customers should take the following precautionary measures to stay safe:
Enjoy the ongoing the Ashes Test cricket series without getting bowled over by any Spammer’s googly.
A few weeks ago at Black Hat 2013 in Las Vegas, there was a particularly interesting presentation entitled, “The Factoring Dead: Preparing for the Cryptopocalypse.” Here at Symantec, we found the topic particularly interesting. Tthe presentation touched on a key topic that we would like to highlight. RSA is a tried and true algorithm and pervasive throughout the ecosystem and there is no reason to mistrust it. This year the industry is moving from RSA 1024-bit certificates to 2048-bits based on NIST recommendations, as the compute power available to bad actors makes a brute force attack on 1024 bit keys increasingly practical. However, what the article mentioned was that recent advances in technology and mathematics have questioned whether this natural balance of bit length versus compute power has a third variable that could make RSA more vulnerable to factoring within 2-5 years. The presenters indicated that the Elliptic-curve cryptography, or the ECC algorithm, is the best replacement should it become apparent that RSA shouldn’t be used.
Fortunately, the presenters have pointed out one thing we’ve known here at Symantec for quite some time – that the SSL landscape is changing and will continue to evolve, and that algorithm agility (or diversity) is a key element in making the entire ecosystem stronger. Earlier this year, we introduced the DSA and ECC algorithms in addition to the RSA algorithm. We are currently the only Certificate Authority to offer a choice of algorithms with every certificate (and yes, you can choose all three at once). We are also the only CA to offer a pure ECC implementation, meaning all certificates in the chain, including the roots, use ECC keys and not RSA keys. These are production certificates with good root ubiquity that are currently being deployed by our customers.
We have the solution to the Cryptopocalypse ready to install today, even if this scenario remains in the realm of theoretical academia for the foreseeable future.
Hi People,
Does SEP 12.1.3 can now supports the Agentless VM scanning and protection by leveraging VMware vSphere 4.1 and above technology to protect multiple Windows Server 2003 & 2008 VM ?
so that I do not have to deploy and manage the agent for more than 500 VMs across 45 ESX and ESXi servers.
Any thoughts and comment would be greatly appreciated.
Thanks,
Hi,
I am currently running on SSIM 4.7.3 and would wish to configure SNMP to monitor all my SSIM services and OS.
Is SSIM able to achieve this?
Thanks
Hi,
I have a Lan Enforcer Appliance running on version 12.1. I would like to configure it for SNMP monitoring.
Does Lan Enforcer appliance have the capability to fulfill this?
Thanks
ZeroAccess has always distributed its malicious payloads to infected computers using a peer-to-peer protocol. The use of a peer-to-peer protocol removes the need to maintain centralized command-and-control (C&C) servers to distribute malicious payloads. In 2011, ZeroAccess’ peer-to-peer protocol communicated over TCP, but in the second quarter of 2012 the protocol was modified to use UDP. This was the last significant update to the ZeroAccess peer-to-peer protocol until June 29, 2013.
Symantec has been closely monitoring the ZeroAccess peer-to-peer networks since its discovery. On June 29, 2013, we noticed a new module being distributed amongst ZeroAccess peers communicating on the UDP-based peer-to-peer network that operates on ports 16464 and 16465. ZeroAccess maintains a second UDP-based network that operates on ports 16470 and 16471. ZeroAccess peers communicate to other peers connected to the same network; peers do not communicate across networks.
The module discovered on June 29 modifies the peer-to-peer functionality of ZeroAccess to make its peer-to-peer network more robust and resilient against outside manipulation. The following is a summary of the key code changes made on June 29, 2013, affecting ZeroAccess peer-to-peer functionality:
In addition to the code update being available on the UDP 16464/16465 peer network for existing peers, after June 29, 2013, we have observed new ZeroAccess installers for the UDP 16464/16465 network which infect computers with ZeroAccess also contain the new peer-to-peer protocol and code changes.
Interestingly, the ZeroAccess UDP 16470/16471 network has not yet received the code update. The new ZeroAccess installer samples for the UDP 16470/16471 network also do not contain the new code. In the past, both the UDP 16464/16465 and UDP 16470/16471 networks generally received new features and code modifications at approximately the same time.
Most of the code changes made by the ZeroAccess authors in this update seem to be in response to published research on ZeroAccess or other perceived weaknesses the authors found in the code. These changes are also further evidence that ZeroAccess continues to be actively developed and remains a threat. Symantec expects development of ZeroAccess to continue and will actively monitor the threat for those changes.
The following sections provide further technical details on the peer-to-peer protocol and related code changes made to ZeroAccess.
Modified peer-to-peer protocol
When discovered in 2012, ZeroAccess’ UDP-based peer-to-peer protocol supported three message types: getL, retL, and newL. A number of security researchers have described the messages and pointed out flaws in the protocol, especially regarding the newL message type. The newL message type is used by ZeroAccess to share directly routable IP addresses (often called super nodes or super peers) amongst its peers. When a peer receives a newL message it adds the included IP address within the newL message type into its internal peer list. The peer also forwards the newL message to other peers it knows about, magnifying the message’s effect. Prior to June 29, by crafting a newL message and sending it to a ZeroAccess peer it was possible to introduce a rogue IP address into an infected ZeroAccess peer’s internal peer list and have that rogue newL message distributed to other ZeroAccess peers.
The new peer-to-peer protocol removes the newL message type, allowing the botnet to filter out rogue peer IPs.
Expanded internal peer-list
Another flaw previously identified regarding ZeroAccess’ peer-to-peer protocol is the fixed internal peer list size. Prior to the June 29 update, a ZeroAccess’ internal peer list was capped at 256 peers. After June 29, a secondary peer list was added and memory reserved to hold up to 16 million peer IP addresses. The list of 256 peers continues to be the “working set” of peers that are periodically contacted. The secondary peer list is used for redundancy purposes.
When the peer list was only 256 peers in length it was feasible that a significant ZeroAccess clean-up action could cut off ZeroAccess peers from the peer-to-peer network because none of their 256 known peers were online. It also became theoretically feasible to replace a ZeroAccess peer’s 256 internal peer list with rogue IP addresses. The secondary peer list makes both of these actions more difficult.
The secondary peer list is written to disk, along with the 256 peer working set. Previous to June 29, the 256 peers from the internal peer list were stored in a file named "@". After June 29, the @ file still exists and continues to contain 256 peer IP addresses from the working set of peers. The secondary peer list, containing up to 16 million IP address, is stored as an NTFS alternate data stream of the @ file. The NTFS alternate data stream also uses the @ filename.
Altered run-time peer contact behavior
Prior to June 29, one of the peers from the 256 peers in ZeroAccess’ internal peer list would be contacted using a getL each second to ask for any data on new malicious modules and new ZeroAccess peer IP addresses. This behavior continues after June 29. However, for any remote peer that responds to a message, that responding peer’s IP address and response time-stamp will be added to the secondary peer list.
The IP’s in the secondary contact list are also contacted when ZeroAccess first starts up. At startup, as many as 16 IPs from the secondary peer list will be contacted each second. This secondary peer list communication will continue until at least 16 remote peers have responded to the infected host. Once an infected peer has been contacted by 16 remote peers, peers from the secondary list will not be contacted until the infected computer is restarted. The secondary peer list will continue to be added to and updated as remote peers respond as part of the normal periodic contact with the 256 peers from the working set. This behavior allows a ZeroAccess client to keep a large list of previously contacted peers for redundancy and still operate with a small working set of 256 peers in order for malicious payloads to be quickly distributed throughout the ZeroAccess network.
Another runtime peer-contact behavior change is the keeping of a contacted-peer state table. ZeroAccess peers continue to send unsolicited getL messages to remote peers and expect to receive retL messages in response. The retlL responses contain malicious payload metadata as well as new peer IP addresses. Prior to June 29, an infected peer would accept any UDP message from any IP address, regardless of whether the infected host had contacted that remote IP address before or not. After June 29, a ZeroAccess peer will continue to accept getL messages from any remote IP, but will only accept a retL message from an IP address that the receiving peer had previously sent a getL message to. Basically, when a ZeroAccess peer sends a getL message to a remote IP address it will add that remote IP address to a table in memory. When a ZeroAccess peer receives a retL message, it will scan its table of IP addresses that it previously sent a getL message to, if the peer’s IP address that sent the retL message does not appear in the table the ZeroAccess peer that received the retL message will disregard it. This change ensures that unsolicited retL messages are ignored and makes using retL messages as a means of introducing rogue IP addresses (like newL messages could be used in the previous protocol) more difficult.
Improved payload file transfer resiliency
A ZeroAccess peer already contains checks to ensure it does not download a rogue payload file from a remote host. A payload file’s metadata in retL messages is digitally signed and cannot be easily forged. In addition, the malicious payload files themselves are digitally signed, the signature is checked after the file is downloaded. The digital signatures prevent a rogue peer from introducing an arbitrary executable module into the peer-to-peer network. The June 29 code change adds checks to ensure that TCP file transfers are not taking too long to complete. These changes seem to be designed to protect against a kind of denial-of-service attack where a rogue peer attempts to trick a ZeroAccess peer into downloading a large number of files from a rogue peer that would deliver the file data too slowly. Using this attack it would be possible to occupy all TCP ports on an infected computer, not allowing it to download the intended malicious payloads.