Karena situs aslinya malah sudah tutup, saya share lagi, sayang ilmunya:
Windows 2000 as well as Windows XP Professional both allow the end user to construct a IPSec Firewall without having to rely on canned or “for purchase” third-party solutions. I myself am amazed when paging through industry journals that spend most of their time painting most Firewall systems as half-baked because those systems only prevent ingress packets and not egress packets. I must admit that after witnessing Windows XP’s sorry excuse for Firewalling (this indeed is half-baked), I was heartened to see that Microsoft left the IPSec functionality alone while upgrading Windows. The only sin Microsoft is guilty of in this regard is burying the IPSec system so very deep in the system, where in Windows 2000 it’s nearly at the surface. Windows 9x is completely helpless in this regard and Linux uses a different system altogether so this is primarily going to just concentrate on Windows IPSEC Firewall security.
IPSec Firewalling begins at a blank MMC console:

From here, we will click these items in order:
- Console
- Add/Remove Snap-in
- Add
- Select “IP Security Policy Management”
- Add
- Finish
- Close
- Ok
To get to our starting screen:

Alternately, there is a faster way within Windows XP (maybe also 2000) and that is: Start, Run, secpol.msc. Thanks for the comments, sorry that the MMC intro is a little labyrinthine, Win2k (when I wrote this page initially) didn’t have a lot in the way of guides.
Windows 2000 initially ships with all these nifty MMC extensions and snap-ins to make your life easier, and it’s one of the most overlooked “cool features” that Microsoft never really hyped enough when they initially released Windows 2000. IPSec lacks some defaults, but this lack of attention on Microsofts part is easily patched over. IPSec lacks the ability to block any ports, even though blocking is something that you can eventually establish for rules and such, I’ve found adding to the IPSec Filter Actions an entry called “Block” makes life much easier later on. To establish a “Block” Filter Action, follow these steps:
- Click on the “plus symbol” next to “IP Security Policies…” under the Console Root folder in the left-hand pane
- Right-click on “IP Security Policies…” in the left-hand pane
- Click “Manage IP Filter Lists and Filter Actions”
- Click on the tab “Manage Filter Actions”
- Click Add
- Click Next
- Set Name field to “Block” and set the description to “Block Access”
- Click Next
- Click the radio-button next to “Block” in the “Filter Action” dialog box
- Click Next
- Click Finish
This will be how it looks when you are done with establishing a Blocking rule:

Microsoft has never explained why they included “Permit”, “Request Security (Optional)”, and “Require Security” in this by default but never even gave a thought to including “Block” when it seems to be an obvious default to include, but, that’s Redmond Logic for ya. In the beginning we start with this screen:

|
The firewall we will design will be a member in the right-hand pane of this window, and because I couldn’t think of anything better to call it, I refer to it as “Firewall”. I don’t change any of the other entries and it’s good advice to follow when I say ignore anything about Kerberos. Mostly because I’ve yet to see anyone seriously use it and frankly I think Microsoft has done naughty things making their little private extensions to the Kerberos standard, oh well, they don’t call it the Beast of Redmond for nothing.
Moving on…
|
We start our firewall off by these steps:
- Right-clicking on the “IP Security Policies on…” item in the left-hand pane
- Click on “Create IP Security Policy”
- Click Next
- In the Name field, type in “Firewall”, and in Description type in “Firewall”
- Click Next
- Click Next (the default will do fine)
- Click Next (the default will do fine)
- If you are not part of a domain, like me, a Warning will pop up, ignore it, if it doesn’t, then ignore this line. Click Yes if you get it.
- Click Finish
This screen is now were we concentrate our activities, you’ll have to uncheck “Use Add Wizard” because I found it tacky and slow, and you might too! Anyhow, the screenshot:

|
For my firewall I ignore the <Dynamic> rule.
I’ve defined several rules that I found very useful and I’ll detail them all below, following some examples I set here to show how to insert them and make them work for you.
First lets create a basic rule that denies all TCP/IP traffic and all ICMP traffic. We build the firewall with the idea of a leperous network, as many protocols that we can turn off the better, and blocking protocol types is the best place to start because at least in the case of TCP/IP it terminates egress and ingress on ALL PORTS from 0 to 65,535. To achieve this follow these steps below:
|
- Click Add
- Two Filter Lists come predefined, All IP Traffic and All ICMP Traffic
- Click the round circle to the left of “All IP Traffic” and then click on the tab named “Filter Action” and click the circle to the left of “Blocked”
- Click OK.
- Click Add
- Click on the tab named “IP Filter List”
- Click the round circle to the left of “All ICMP Traffic” and then click on the tab named “Filter Action” and click the circle to the left of “Blocked”
- Click on the tab named “IP Filter List”
- Click OK.
These steps effectively block all IP and ICMP traffic from both egress and ingress to your system once the “Firewall” package has been assigned. At this point in the game, your computer is almost as good as unconnected to the network, no port scanning on your IP address will reveal any ports open and as an added bonus, since you’ve also cut off ICMP traffic as well, all port scanning to your IP Address will behave as if it is a TCP/IP black hole, packets get sent out but they never get accepted or refused right out, so the scanner will have to wait for timeouts to pass for each scanned port, that seriously slows any scanning program right down, good for you and the WH, bad for the BH.
However, in this state it does suck for the user. Since no traffic can enter or leave based on IP or ICMP protocols it’s just as if we had unplugged the poor person from the network. This basic firewall is a great way to deny a user a path to the Internet while still allowing them the benefit of knowing the Ehternet cable is plugged into their NIC. At this point we have to start poking holes in our firewall to let the ports we know pass through in the ways we wish.
The general form that I follow depends on what filter definition you use, these shots coming up will show how to limit a popular port, like 80/tcp by ingress, or egress, or just from a particular subnet. Then at the end I’ll discuss what ports I do let through and why.
To Allow Port 80/tcp ingress (Opening your Webserver)
Starting from the top:

I’ve already created an “Example Firewall” and stocked it with all the options in order to achieve the objective, wihch is to provide 80/tcp ingress. The definition on the “Example Firewall” on the left, and when you double-click on “Example”, you see the screen on the right:

|

|

|
So far, we have a IP Filter List that we’ve selected, and also allowed for it’s traffic to pass by selecting Permit in the “Filter Action” screen. Next we will go back to the IP Filter List called “Example” and show in a series of shots how to create a hole in our firewall (covered above) so that the HTTP port, 80/tcp is allowed open and given the rights for ingress, so that a webserver on our machine can be seen on the general internet. Note that this example doesn’t make use of the subnet rules to define sections of network as friendly or unfriendly. Examples follow…
|
Essentially that is all there is to it, beyond being particular about subnetting and deciding ports and protocols the rest of the firewalling is up to you, the administrator. If you prepare a system like I have then you eventually find yourself developing a firewall that protects people while still allowing them to use the services they have come to depend on without risking ingress or egress on any other port that might eventually become useful to a BH agent. I simply leave ICMP totally alone except for opening it up to the local LAN, this provides ICMP messages (ping and tracer) information to flow across my LAN with ease but prevents any other ICMP packets from actually being processed by any of the Windows 2000 systems on my LAN. More of course, is coming up as I describe the ports and the why’s behind my selections.
Firewall Port Selection
Previously I stated that having the basic no-traffic-allowed firewall was the simplest to implement, it was also the most impossible to use. Because no packets can egress or ingress at all, no services that use network components ultimately fail. Items such as Netscape Navigator, Internet Explorer, DNS, NetBIOS, and even the Novell Client32 cannot work properly under these conditions. I faced this exact question when I first started working on this firewalling project. Initially I wanted only to provide firewall holes for services I knew about and I knew my users would absolutely need for core business processes. Because Windows 2000 IPSec firewalling prevents egress as well as ingress, I realized an unforseen benefit from employing these firewalls, unauthorized software that is internet enabled and uses unique TCP/IP ports are rendered useless without the user requesting help, and with slightly educated users, help with turning on ports, which leads to questions and a very useful way to protect people from their own shortsightedness. Anyhow, on with the Parade of Ports:
Service Name
|
Port Numbers Used
|
Notes/Comments
|
Ingress/Egress
|
HTTP
|
80/tcp
|
|
Egress
|
DNS
|
53/tcp & 53/udp
|
Only Allowed for 192.168.0.0
|
Egress
|
Wins (TCP)
|
42/tcp & 42/udp
|
|
Egress
|
NNTP
|
119/tcp
|
|
Egress
|
Network Time Protocol
|
123/udp
|
|
Egress
|
Groupwise (IMAP)
|
143/tcp
|
Only Allowed to IMAP server alone
|
Egress
|
Server Location (TCP)
|
427/tcp & 427/udp
|
|
Egress
|
SSL (TCP)
|
443/tcp
|
|
Egress
|
Hi-Wins
|
1512/tcp & 1512/udp
|
|
Egress
|
Groupwise
|
1677/tcp
|
Only allowed for 192.168.0.0
|
Egress
|
NetMeeting Gate Discovery
|
1718/tcp & 1718/udp
|
|
Egress
|
NetMeeting Gate Stats
|
1719/tcp & 1719/udp
|
|
Egress
|
NetMeeting Host Call
|
1720/tcp & 1720/udp
|
|
Egress
|
NetMeeting Connector
|
1503/tcp & 1503/udp
|
|
Egress
|
NetMeeting MSICCP
|
1731/tcp & 1731/udp
|
|
Egress
|
VNC
|
5800/tcp & 5801/tcp
|
|
Egress
|
VNC
|
5900/tcp & 5901/tcp
|
|
Egress
|
NetMeeting IN
|
1503/tcp & 1503/udp
|
|
Ingress
|
NetMeeting IN
|
1718/tcp & 1718/udp
|
|
Ingress
|
NetMeeting IN
|
1719/tcp & 1719/udp
|
|
Ingress
|
NetMeeting IN
|
1720/tcp & 1720/udp
|
|
Ingress
|
NetMeeting IN
|
1731/tcp & 1731/udp
|
|
Ingress
|
FTP
|
21/tcp
|
|
Egress
|
FTP Datastream
|
20/tcp
|
|
Egress
|
Netware
|
213/tcp
|
|
Egress
|
Netware
|
396/tcp
|
|
Egress
|
Netware
|
524/tcp
|
|
Egress
|
Real Time Streaming Proto
|
554/tcp
|
|
Egress
|
RealPlayer
|
7070/tcp
|
|
Egress
|
RealPlayer
|
6970/udp
|
|
Egress
|
Novell Portal
|
8008/tcp
|
|
Egress
|
Novell Portal
|
8009/tcp
|
|
Egress
|
Defrag
|
3090/tcp
|
|
Egress
|
Defrag
|
139/tcp
|
|
Egress
|
Defrag
|
445/tcp
|
|
Egress
|
Telnet
|
23/tcp
|
|
Egress
|
Wins
|
135/tcp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
NetBIOS-NS
|
137/udp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
NetBIOS-DGM
|
138/udp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
NetBIOS-SSN
|
139/tcp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
SMB over TCP
|
445/tcp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
ICMP Ports for LAN
|
all/icmp
|
Only allowed for 192.168.1.0 & 192.168.2.0
|
Ingress
|
All other TCP/IP and ICMP ports are left closed, and all NetBIOS ports (nee, read SMB) are specifically closed to all network locations except for 192.168.1.0 and 192.168.2.0 class subnets. I spend extra time defining SMB protections because after analyzing the Windows 2000 logs I detected an inordinate amount of browsing going on thru Network Neighborhood in relationship to a popular subnetwork of ours called ResNet. While I cannot estimate how many of these browsers were bent for some BH purpose, my task was very clear, block everyone except those that must have SMB abilities from engaging in any activities related to SMB. The most sensitive ingress points are likewise protected by the extra definition of the subnet filter, no machine on our LAN outside of our two common subnets may engage these ingress points. The proof comes in the logs, the amount of detected browsing has sharply fallen off and those that do are local users for which I have implicit trust. The only technically unprotected ingress points are those surrounding NetMeeting, however Microsoft provides certificate and username/password controls on NetMeeting so I am not as greatly concerned about protecting those ingress points with so many rules – that and I prefer to leave those particular ingress points free so that I may have the convenience of connecting from remote locations off of our 192.168.0.0 home network.
Download Example Firewall IPSEC file here. (Hint: Use “Save Link As…” or “Save Target As…” to download this file)
Download Basic Example Firewall IPSEC file here.
How to Install *.IPSEC files:
The file isn’t meant for MMC console, instead it’s meant for the IP Security Policy snap-in. Follow these steps:
- Open MMC
- Click on File
- Click on Add/Remove Snap-In, add the IP Security Policy snap-in, click ok.
- When back to the MMC console, click the plus to the left of “IP Security Policies on Local Computer” in the left-hand pane, then click on “IP Security Policies on Local Computer” itself, in the left-hand pane.
- Right click on the IP Security Policy icon and click “All Tasks” then click on “Import Policies”, then find the firewall.ipsec file and click ok.
Updated: 6/15/2007