↓ Skip to main content
Andrew Healey

Part 3: Blocking Bad Hosts - Blocking Them, Easily (CLI Edition)

·3 mins
Technology Ipsec Security Tutorial

In part two, I showed you how to use the Local Security Policy GUI to block the bad guys. There were a lot of pretty pictures for those that prefer the GUI. In this version, I’ll show you how to accomplish the same thing from the command line. This is my preferred method.  It is much simpler to automate and explain.

By following the steps below, you will be able to create a new policy and manage the filter lists and actions. The goal here will be to put all these pieces together into a nice tidy package that is fully automated.

The policy you create in this tutorial will not be applied to the system until you “Assign” the policy in Step 6. As long as the policy is not assigned, you can safely edit, add, remove, etc. rules and sets to the policy without affecting the system. Note: double and triple check your sets to ensure you do not block legitimate traffic before assigning the policy.

To begin this tutorial, open the command prompt. If you don’t know how, you probably shouldn’t be doing this. All commands meant to be typed are in italics.

Step 1: Create IP Security Policy
#

netsh ipsec static add policy description="This policy blocks all traffic to hosts/nets associated with it."

Step 2: Create an IP Filter List
#

netsh ipsec static add filterlist description="This filter list contains hosts and networks known to host malware, criminal activity, etc."

Step 3: Create IP Filters and Associate them with the Filter List (Repeat this step until all hosts you wish to block have been entered)
#

Single IP (10.254.254.254/32)

netsh ipsec static add filter filterlist="Bad Hosts" **srcaddr=10.254.254.254** dstaddr=any description="John Smith. 12/31/2015. Brute force logon attempts to: SERVER01"

Subnet (10.254.254.0/24)

netsh ipsec static add filter filterlist="Bad Hosts" **srcaddr=10.254.254.0** dstaddr=any **srcmask=24** description="John Smith. 12/31/2015. Brute force logon attempts to: SERVER01"

Network Range (10.254.254.2-10)

netsh ipsec static add filter filterlist="Bad Hosts" **srcaddr=10.254.254.2-10.254.254.15** dstaddr=any description="John Smith. 12/31/2015. Brute force logon attempts to: SERVER01"

Step 4: Create a Filter Action
#

netsh ipsec static add filteraction description="This action blocks all traffic." action=block

Step 5: Create Policy Rule to apply Filter Action to Filter List
#

netsh ipsec static add rule policy="Blocked Traffic" filterlist="Bad Hosts" filteraction="Block All Traffic" activate=yes

Step 6: Assigning (and un-assigning) the Policy
#

This step will apply all the settings you have created up to this point. Double and triple check that you did not enter a valid host or network or it will be blocked. If fact, if you have any doubts in your mind, do not do this step until another person (who knows what they are doing) looks over your work too! Note: This is one place MS will not give you a little “are you sure you want to do this” type of warning. As soon as you assign the policy, it is done.

Assign

netsh ipsec static set policy name="Blocked Traffic" assign=yes

Un-assign

netsh ipsec static set policy assign=no

Related

Part 2: Blocking Bad Hosts - Blocking Them, Easily (GUI Edition)

·4 mins
Technology Ipsec Security Tutorial
In part two, I want to show how you can quickly setup an ipsec policy to block the bad hosts you identified in part one. While many methods can be used to block hosts, using the Local Security Policy (secpol.msc) and ipsec is a simple method which can be fully automated. By following the steps below, you will be able to create a new policy and manage the filter lists and actions. In part three, I will explain how this can be done from the command line for all you CLI warriors. This tutorial should be accurate for: Windows XP, Vista, 7 and Server 2003, 2008, 2008R2 (possibly even 2000).

Part 1: Blocking Bad Hosts - Finding Them, Easily

·5 mins
Technology Event-Log Tutorial Vbscript Windows
While troubleshooting some issues on an OWA Front-End server, I went over to the security log to see if the authentication attempts were getting past this box. The problem I found was the log was so full of failed logon attempts it was difficult to filter out what I was looking for. In a twelve hour period, there were thousands of 529 events in the security log. Now, I know this is nothing new, but I found a few patterns. I manually exported the log to a CSV, parsed out all the source ip addresses and opened it up in Excel. What I found was that 98.7% of failed logon attempts were made by just four different ip addresses. (I recommend using MaxMind’s GeoIP Address Locator for help in determining where the source addresses are located.)