Reset Local and Group Policy on a Windows PC

I have found myself in many situations where I needed to run this command in order to start with a clean slate in regard to policy.  Putting it here on the blog will ensure I can find the command the next time that I need it.   In short, there are times when you move machines from domain to domain or you have done a series of policy edits over time and your RSOP (Resultant Set of Policy) just doesn’t seem to be accurate.  When I find myself in this situation, I run the command below:

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

After running this command I reboot the machine, log back in, and run a  “gpupdate /force” to pull the policy back down.  I then check the RSOP again to see where I stand.  I have found that this command is very helpful in troubleshooting RSOP while cleaning up the trash.

Opera Files Antitrust Suit Against Microsoft

I really hope this gains some ground. I know the dev geeks are all sick and tired of Microsoft strong-arming with IE. I have to admit that IE7 was a little better in regards to web standards and the ease of cross-browser compatibility. However, they are still throwing their weight around.

Opera Files EU Antitrust Suit Against Microsoft

AV for Linux….Interesting

On my CentOS VPS:

wget http://free.grisoft.com/filedir/inst/avg75flr-r49-a1130.i386.rpm
yum install pygtk2
yum install pygtk2-libglade
rpm -ivh avg75flr-r49-a1130.i386.rpm
avgupdate -o
avgscan /

Results:

Tested: 7733 files, 0 sectors
Infections: 0
Errors: 0

Imagine that!

I think I could of wrote this AV program myself in about 2 seconds with with Python give or take.

print “No viruses found”

Brute Force Attack Prevention Mistake 4: Blocking the IP

So you have decided to start developing your brute force prevention system and you have decided to take my advice. You are going to use a database to keep up with failed authentication requests (instead of a Session) and you have chosen the IP address as the only identifier. You have decided to block the IP address from being able to make authentication requests after there has been X failed login attempts from that IP. Unfortunately, what you may not know is that you are setting yourself up for an additional brute force prevention mistake.

By using the IP as the only identifier you are setting yourself up for a new type of attack against your website. This attack is known as Denial of Service (DoS). To understand how someone can purposely or accidentally perform a DoS on your website with IP blocking in place, you must first understand Network Address Translation (NAT). NAT is a computer networking process that allows multiple hosts on a network to access the internet via a single IP address. This is a very common practice among many businesses, universities, government facilities, etc. With this in mind, lets look at a real world example:

Lets say that you are a local bank and and you are developing brute force prevention with IP blocking for your online banking services. Many of your local customers are students at the local University. The students take advantage of your free checking and other banking services. Most of these students live on campus and use computers on campus to access their online banking services. The Information Technology department at the University also uses NAT on their network to avoid the cost and complications of reserving public IP addresses. A few days after you implement the new brute force prevention for your bank website you start getting a flood of phone calls from thousands of angry students who are unable to access their online banking services. It is clear that you are experiencing a Denial of Service attack. What happened?

Scenario 1 (Accidental): A student realizes that he may have bounced a check and he runs into a computer lab on campus to login to his online banking services. He attempts to login a few times with no success. He tries one last time and receives a message from the site that that he has been blocked for to many failed login attempts. Your website blocks the IP of the request. Unfortunately, this is the same IP that all computers on campus use when accessing the internet due to NAT and thus you have now blocked the entire campus (DoS) from being able to access the site.

Scenario 2 (Malicious): A visitor on campus finds a computer that has been left logged in and uses it to access the internet. He visits www.whatismyip.com which quickly returns the NAT’ed IP address of the campus. He then writes down this IP for safe keeping. He returns home (off campus) and decides to use IP Spoofing techniques to perform a DoS attack on your bank website. By using IP Spoofing he can make authentication attempts on the website while making it look like it is coming from the NAT’ed IP address of the campus. This also conceals his identity. After a few failed attempts he receives a message that he has been blocked for to many failed login attempts. Your website blocked the IP of the malicious request. Unfortunately, this is the same IP that all computers at the local University use when accessing the internet due to NAT and thus you have now blocked the entire campus (DoS) from being able to access the site.

As you can see, Blocking the IP can definitely be a brute force attack prevention mistake.

Solution: Don’t use the IP as the only identifier. All authentication attempts must be made with a username and a password. This means that you could store failed attempts in your database based on the IP address and the username. If you receive X failed attempts for a given username from a given IP then block authentication requests for that username from that IP. This will ensure that you are only blocking what is absolutely necessary to protect your system from a brute force attack. This will also keep you from being vulnerable to a DoS attack due to the common use of Network Address Translation (NAT). Please keep in mind that this technique will allow the attacker to try a few attempts on multiple accounts. However, this attack will not result in a successful brute force as long as you have implemented strong passwords coupled with simple authentication responses.

PS: When you block authentication requests, you may block the actual owner of the account. This can happen if a user forgets their password and makes to many failed login attempts. With this being said, you must provide a way for the actual owner to unlock the account. Remember, you are trying to protect the user’s account from a brute force attack while still providing them a service. We will be taking a look at this and more common mistakes in upcoming posts.

Brute Force Attack Prevention Mistake 3: Using A Session

One of the first steps in developing custom brute force prevention is keeping track of failed login attempts. You then decide how many failed attempts you will allow before attempting to prevent any more unauthorized attempts. You realize that you must come up with a way to store the failed attempts so you decide to use a session variable (a common choice).

PHP BASIC SESSION EXAMPLE

session_start();
if ($_SESSION['logged_in'] == ‘failed’) {
$_SESSION['failed_attempts'] = $_SESSION['failed_attempts'] + 1;
if ($_SESSION['failed_attempts'] == 5) {
$query = “INSERT INTO `blocked_users` ( `block_id` , `user_id` , `date` ) VALUES (”, ‘$user_id’, ‘$date’)”;
$insert = mysql_query($query);
echo ‘This Account Has Been Locked Out’;
}
}

From the simple code example above, you can see that it stores failed attempts in a $_SESSION variable. Once it reaches 5 failed login attempts, it makes a database entry to block or lock the account. Unfortunately, this is a huge brute force prevention mistake. Sessions are primarily stored in one of two locations. They are stored in a cookie that resides on the client side or they reside in the URL. With this being said, your largest brute force threat is a brute force script or program. These brute force tools do not create and store cookies. Each authentication attempt is made with a unique request. This means that the brute force tool does not hold open a session and therefore every new request is assigned a new session. This means that the script can send countless authentication attempts and it will never get blocked. By using a session your are only protecting yourself against the malicious user who sits and manually makes authentication attempts. This user can still make 4 attempts, close their browser or clear their cookies, and then reopen the page to try again and they will never get blocked. As you can see, using a session to store failed login attempts is a big mistake.

Solution: Use a database to store your failed login attempts. When an authentication request is made, that request can be uniquely identified by several characteristics. One common identifier is the IP address of the request. You can use these identifiers or a combination of identifiers to track failed authentication attempts in a database. Using a database will allow you to track failed attempts for any user, script, or tool.