Category: windows

OSSEC Agent Fails to start

Recently I was adding the OSSEC agent to a windows 2008 r2 machine and ran into a issue where the the agent was failing to start saying [check config!]. Well I had never changed the config so there should not be anything wrong with it. After some searching I found a post suggesting to go to regedit and modify HKLM\system\currentcontrolset\services\OssecSrv ImagePath – c:\program files (x86)\ossec-agent\ossec-agent.exe. Add quotes around “c:\program files (x86)\ossec-agent\ossec-agent.exe” and restart. After restarting I still had no luck. Then it came to me.

I went into regedit again and realized before I got to the regedit screen, I was interupted by the User Acess Control prompting me to lower my settings, or to run regedit as an administrator. Well if the agent is attempting to start, but being interupted by UAC, then this would surely prevent it from reading the config correctly. so here is what I did.

Go to Start >> Run type msconfig into the text field. When the MSConfig utility shows up, click on the “Tools” tab. In the list you should see “Change UAC Setting”. Click on it and select the “Launch” button below. This will give you the UAC windows where you can lower the bar to never notify. After that is done, go ahead and restart. Once restarted, check your OSSEC agent and it should be running!.​

Anyone who knows me probably knows this is one of my biggest pet peaves. I see this happening everyday, but from a large site like LinkedIn.. shame on you. As all of you probably know by now, a post was made to a Russian site of more then 6.5 million passwords from LinkedIn attempting to crack the SHA-1 hashed passwords.

Now for all of you who have gotten into encryption / decryption of sensitive data, I am sure you understand the problem here with just hashing a password with SHA-1 encryption without salting. If a hacker is able to determine the algorithm used to hash the password, then the rest is fairly easy. The simpler passwords can be uncovered fairly quickly, leaving the more difficult ones which when broadcasted to a hacker community, will take no time to be uncovered as well.

Salting a password is a process of adding in random bits into a hashed password. This makes it much more difficult for an attacker to decrypt because they would need to not only be able to hash their dictionary passwords, but then they would have to try each of those passwords with a variations of salts. This can fill up their data and computing power quite fast creating a very expensive and difficult task for a hacker. They would need a large budget along with tons of storage space and computing power to be able to break down a salted and encrypted password. Where as with just a SHA-1 encrypted password, an attacker would only have to Hash each password trial once and compare it to the value of the encrypted password they have. Once the value is not matched they can just move on to the next dictionary hashed value instead of salting variations of the same password.

So as you can see that the time and expense to decrypt salted passwords can be astronomical and even a deterrent for a hacker attempting to grab hold of your data. Now with all the problems these days with information being leaked or stolen, you would think that a site like LinkedIn would have been more mindful of the world we live in and not assume that the password obscurity they are using is “Good Enough”. If in fact the hackers have usernames that are tied to these passwords, then the truth of it is most people re use their usernames and passwords. So if a hacker grabs your information for one site, then they could potential try to use that same combination on other sites you may visit. Thinking that the breach that has happened to LinkedIn is focused solely on that site, is ignorant. Don’t fool yourselves, change your passwords everywhere you use it.

My recommendation to you is to alter your passwords. Try not to reuse a password many times. Come up with a methodology of using your passwords so that if you have to reuse them then you can derive a system of which passwords you use where. This will make it more difficult for someone to attempt to reuse your password to gain access to more of your personal information.

A couple of days ago I had a sudden panic when all of a sudden my Virtual Machines began to shut down. You can only imagine how bad this can be when a fully redundant system, simply fails. As I began looking into the issue, I start to receive errors that some of my LUN’s on my brand new EVA had reached capacity.

Baffled as you can imagine I began to look at my usage in VMware and found that I still had approx 180 Gig available. When I opened up the datastore I noticed that my VM’s had a massive amount of snapshots that have piled up in the directories.

We use a utility called Backup Exec from Symantec to provide a backup utility for our entire production environment. One of the plugins for Backup Exec allows you to make backups of your VMDK’s. When BE makes backups of these files it makes a call to VMware and creates a snapshot of the VM at that moment. If for whatever reason the backup job fails, the snapshot is not deleted and it becomes the current working version of the VM. After several failed jobs this began to pile up for the VM’s and the LUN ran out of room.

Well as you remember I told you that when I looked at the LUN I had 180 Gig available. Well unknown to me that coupled with the fact that my LUN had run out of space but now VMware was not reporting my usage correctly. What this caused was a failure of the alarms triggering to tell me that my LUN utilization was getting high.

After calling VMware to assist me with getting my environment back online and clear out all my snapshots, I found the issue with the alarms not triggering. The recommendation was to edit your datastore alerts and make a change to it in some way so that when you click ok, VCenter server will reset the trigger and start to poll the actual datastore size at that moment.

After all is said and done I have learned and am now passing on to all of you. Always check your backups and make sure that there is no snapshots left behind that were not cleaned up. I have also learned to double check my usage stats and look more closely at VSphere client for anomalies.

Microsoft has released an advisory stating that an inside source has found vulnerabilities for 23 different areas within Microsoft applications.

I thought I would post this to give everyone a heads up out there, this appears to be a significant find. I give kudos to their staff for being diligent in trying to secure their application portfolios. This is not an easy thing to stay on top of and manage to enhance your portfolio in the process.. So finally this being a rare occurrence, but thank you Microsoft for getting this right.

Below is the link to the article in which you will find the story. Check it out!.

%d bloggers like this: