Windows update and AVG removal

Posted at 4:53:11 PM in Security (4)

I've run into several PCs that have AVG installed on them and after the Windows update, it can't be removed. I tried downloading the removal utility from AVG's site and it doesn't work either. I did find a removal utility made by avast that will remove AVG. I assume this was created in order to install Avast in place of AVG, not sure. I can't find it right now.

But what I did find out about this particular PC I'm working on today is that the Windows update and the user caused the problem. Here's how it works.

When the system was originally installed, the user did not use an email and Microsoft account to setup the PC. They didn't even use a password. When the recent Windows Update, I believe it was the Creative update, Windows asks again if you want to setup a Microsoft account. This time the user used an email address. After the update, the desktop appears the same, but we can't remove AVG. Even worse, AVG took over the firewall, I believe it was a 30 day trial of Internet Security, and blocked access to name servers. The PC was effectively locked out from the internet. We couldn't do anything about the firewall. The windows control panel access to the firewall services were locked out stating that we had to use AVG to make adjustments. Trying to remove AVG just didn't work with any of the recommendations I could find on the internet.

I finally  into windows > Settings > Accounts and selected sign-in with a local account reverting to the original name that was already used with the same password they had before and I was able to remove AVG using the Control panel Programs and Features. Everything is now back to normal.

Written by Leonard Rogers on Wednesday, July 26, 2017 | Comments (0)

IADB whitelist still worthless

Posted at 6:54:31 PM in Security (4)

The IADB whitelist just passed a list of diesel engine parts as surplus inventory to my CPA client. Here's the score:

	* -0.0 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
	*      [208.75.123.201 listed in iadb.isipp.com]
	* -0.0 RCVD_IN_IADB_LISTED RBL: Participates in the IADB system
	* -0.0 RCVD_IN_IADB_VOUCHED RBL: ISIPP IADB lists as vouched-for sender
	* -0.0 RCVD_IN_IADB_SPF RBL: IADB: Sender publishes SPF record
	* -0.0 RCVD_IN_IADB_SENDERID RBL: IADB: Sender publishes Sender ID record
	* -0.0 RCVD_IN_IADB_DK RBL: IADB: Sender publishes Domain Keys record
	* -0.0 RCVD_IN_IADB_RDNS RBL: IADB: Sender has reverse DNS record
	* -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
	*      [208.75.123.201 listed in wl.mailspike.net]

 On my server, I've marked all of these to a very low score to see what kind of spam actually comes through. For the most part, IADB passes junk mail. It is a paid for whitelist that has no management or testing facilities to ensure the email from servers they whitelist are actually legit.

Written by Leonard Rogers on Thursday, October 16, 2014 | Comments (0)

OpenSSL client certificate expires in 30 days

Posted at 9:30:24 PM in Security (4)

In my previous discussion on this topic, I listed a link that I thought was very helpful. In creating the server certificate, there is an option -days 3650, but that option is omitted when creating the postgresql.crt file. The default OpenSSL expiration is 30 days meaning the client certificates would expire forcing me to recreate new ones.

The solution is simple. From the howtoforge site change this:

openssl x509 -req -in /tmp/postgresql.csr -CA root.crt -CAkey server.key -out /tmp/postgresql.crt -CAcreateserial

and add the -days option

openssl x509 -req -in /tmp/postgresql.csr -CA root.crt -CAkey server.key -out /tmp/postgresql.crt -CAcreateserial -days 3650

You can test the dates by issuing this command:

openssl x509 -noout -dates -issuer -subject -in postgresql.crt

Your out put should be something like this:
 
notBefore=Oct  1 00:10:46 2013 GMT
notAfter=Sep 29 00:10:46 2023 GMT
 

Written by Leonard Rogers on Tuesday, October 1, 2013 | Comments (0)

Creating an SSH key for Putty

Posted at 3:19:03 AM in Security (4)

I thought the process for creating an SSH certificate would require SSL as well, but it doesn't. Creating a key for Key Based SSH logins is all performed with the tools associated with Putty. Here is a good step by step tutorial for creating the certificate and a means of preventing logins through regular passwords. This will help prevent Brute force login attempts, however; as the author notes, if you lose your keys, you will not be able to login.

I don't know if disabling logins also disables the console, but I don't have access to my server to test it. The article is in four parts, hyperlinked at the bottom of each article. After creating the initial key pairs (public and private) you can copy the private key to any other machine that needs access to the server. You do not have to generate a new key pair unless the login for the new person does not have access to the public key on the server.

I would suggest creating a ridiculously long password using this site. Instead of disabling logins altogether. This leaves that door open of course, but creating a 32 to 128 character password and changing it as the need arises should make it very very difficult for even a brute force attack.

Written by Leonard Rogers on Monday, August 26, 2013 | Comments (0)