Search This Blog

Subscribe to this blog

Follow by Email

McAfee fails to secure!

Up to couple of weeks ago I have always used Symantec for my antivirus software. But in the last two weeks I decided to try McAfee AntiVirus, which comes as part/component of the McAfee SecurityCenter and provided for free to Comcast subscribers. So, I installed it on some of the machines I have at home.

A side note about my home network. I have couple of mid-towers, couple of laptops and a server. I use VNC to remote into the machines. For those of you who do not know what VNC is. It is an application used to remotely view the screen of another computer and have full control of it, almost as if you were there. I say almost, because the user has only software control and is not able to do anything physical to the machine, like a hard reboot for example. Hens â€œremoteâ€ :).

Back to McAfee. McAfee AntiVirus has a security feature called PUP â€“ Potentially Unwanted Program. On each box I installed the antivirus, VNC was recognized as a PUP shortly after the installation was completed. Now, one would only expect that if the antivirus software recognized an application as potentially harmful to the user it will quarantine the application and disable its ability to interact with the computer until further action from the user. Well, it did NOT!

I was able to set McAfee to trust VNC through VNC. In other words, if I was an attacker I would have been able to set the antivirus software to trust my invasive program and I would have maintained my control of the victim's computer.

McAfee SecurityCenter â€“ secure ... uhhhhh ..... only on the out side.

I suppose McAfee's excuse would be - â€œwell you did not install other components of the SecurityCenter. Like for example the McAfee Firewall.â€ Oh yeah? Well, if that's the case why do you even have a feature like PUP in your antivirus software? Response: â€œuhhh ... sell more of our software products?! Hopefully.â€

Popular posts from this blog

I am currently working on a project which will allow users to register their Wi-Fi enabled, non-web browser enabled, devices on the network. These are devices like printers, Apple TV, and Xbox*. One of the data points that have to be collected from the user is the device MAC address. The project customer wants that address to be properly formatted when they see it in the support ticket.

We have several options. We can format the address either on the back-end after the form has been submitted. Or we can format it on the front end via a separate text field for each character pair, but that is too many fields to handle. A better solution is to use a single field and format the user input at the time of input or upon submit. In those cases, the former is better because the data will already be formatted when the overall form input is being validation after the user clicks the “Submit” button.

We are going to format the user input as it is being provided, thus having proper data when vali…

Setting up a new site in Coda 2 and cloning a GitHub remote repository is not that big of a deal. Where you will most likely run into problems is when you try to push your changes to the GitHub remote repository. Below I will show you how to update the Git config file in your local repository so you do not run into one of the following errors:git push failed remote: Remote anonymous access to repository deniedgit push origin master Username: fatal: Could not read passwordThe GitHub repository address I am going to use is that of Source Code DNA: https://github.com/thetitan/sourcecodedna.git. I will assume that you have already setup your Coda 2 site profile and cloned your repository, you have made some changes, and now you are ready to push those changes to your projects GitHub repo.

If you have a WordPress based blog, or otherwise use WordPress as a CMS for your website, you are either getting a lot of bad user accounts being created or noticing a lot of knocking on your wp-login.php page. WordPress has a nice feature which allows you to install WordPress in a directory other than the root one. For example, your site is served from http://blog.example.com, but WordPress can be installed in http://blog.example.com/wpcms. In past versions of WordPress, prior to 3.8 or maybe be older than that, unless you knew the exact path to where WordPress was installed you could not get to the dashboard. That has changed! Now even if WordPress is installed in some random directory, if you navigate to http://blog.example.com/wp-login.php you will be redirected to the actual WordPress login page. Convenient, but not helpful when dealing with SPAM bots.