I've recently setup my first server here, and after perusing these forums, decided to setup RRAS and IPSec to limit access to the minimum required. However, while I found some good how-tos on RRAS setup, there was not as much on IPSec. I found one script which was helpful, but ended up making several more. So I figured other might find this helpful. (And thanks to the first scripter out there, these are all based on that one)

I've attached a zip file containing a number of scripts. First (for the wise amongst you) check them out to ensure that the code is what I said it is.
Then run SetupIPSec.bat, with 3 command line arguments:
1- The primary IP Address of the server
2- Your IP address you normally administer the server from
3- The X.X.X.0 subnet of your address (i.e. if your admin from 123.123.123.123, enter 123.123.123.0) I'll explain this bizarre entry later.

This script will then setup an IPSec policy containing everything I've scripted. You won't want to choose them all, so open the IPSec management snap-in (see elsewhere on forum if unsure how to do this) and go through each one and customize it for your needs

Each script can be run on it's own if you want.

A summary of the items setup is as follows:
1- It blocks all traffic not otherwise allowed
2- It enables port 1248 and ICMP for ServerMatrix
3- It enables Remote Desktop ONLY for ServerMatrix and your Admin IP (this is critical I believe)
4- It enables HTTP + HTTPs for all your IP Addresses
5- It enables SMTP for your server
6- It enables Outboung HTTP (including DNS) so you can web browse while logged in (to download a Microsoft patch directly for instance)
7- It enables Active + Passive FTP only to your admin address
8- It enables Active FTP only to all addresses
9- It enables Streaming Media (RTSP/MMS TCP + UDP) access to all addresses
10- It enables Urchin access for your admin IP
11- It enables Urchin access for all IP Addresses

Like I said, obviously you don't need all these enabled, but you can simply select which you want from your IPSec control panel once they are loaded. And when there are some examples in front of you, modifying them or making new filters becomes more apparent. For instance, I haven't done a POP3 one yet (since I don't need it), but it should probably be in here

FTP was a real bear, and that filter is bit strange (it's the one that requires the 3 octet submask). I didn't enable Passive FTP for the public access version as that would have required opening all inbound TCP ports which defeats the whole point of IPsec. If someone comes up with a better way of doing Passive FTP, please let me know.

Finally, but quite important, running this script will only load the policy, it is NOT active afterwards. This is good because you can check it over before you assign it and potentially lock yourself out if you got the address wrong or whatever.

One last note of caution for those new out there. 'Your' IP address is the public IP address the server will see, not your pre-NAT IP address. Basically, if you are thinking about entering 192.168.X.X as your admin address, that's probably the wrong address and you are about to lock yourself out.

I hope some people find this useful. It's a starting point to check out if nothing else. And personally I recommend running RRAS over top of this, it stealths all your admin ports and gives 'defense in depth'.

Geof

Oh yes, the link: http://70.85.92.50/SetupIPSec.zip
(link edited)

Well, the link doesn't works for me !...

man I was looking forward to see this script but your link doesn't work here either

Me neither. Looks like he blocked port 80 in one of his scripts

Whoops,

A leeeetle DNS problem (I hadn't moved over this domain to point to the new server). Sorry. The link should work now, but if your DNS has cached the old value, try this link instead http://70.85.92.50/SetupIPSec.zip

Geof

This is great, thanks for posting it

With passive FTP you typically need to assign a port range to your FTP application, then open up those ports in the firewall. You can do this with MSFTP under IIS6, or really any other FTP server product. I currently use Serv-u on 60000-60005 and open up those six ports in the firewall.

I tried to set the PassivePortRange for MSFTP using the adsutil command (and triple verified it was done with metabase explorer), but IIS seemed to ignore the settings. I put in 5501-5503, but when I connected via passive FTP, the PASV command resulted in a return port usually between 5000-5100. (192,168,0,101,19,204)

Using netstat on the server, it looked like the server was attempting to open 5501-5503, but the command reply being received indicated a totally different port was open and I was unable to connect using LeapFTP or AceFTP in passive mode with just those ports open.

However, when I opened all ports up, it connected fine.

I suspect the problem is with MSFTP, as I haven't tried another FTP server program. It could also be the ALG on the server or NAT firewall on my client end I suppose doing some helpful port translation for me.

Geof

Hmm, something vague is tickling the back of my mind. I seem to remember having a problem as well, but I can't remember what it is at the current moment. I remember there was something non-obvous that I also had to do. Is it possible there's another entry in the metabase somewhere else?

The metabase in IIS6 is a plain XML text file so you should be able to open it up in a text editor and double check there isn't any setting that's being missed.

Sorry, I got too frustrated with MS-FTP on other levels, mainly ease of customization and the way the frontpage extensions clobber all my FTP permissions, and switched to Serv-U. Sure it costs money, but time is valuable and I didn't want to mess with it anymore.

Hi All,

I also combine all the IPSec knowledge on this forum and some external links and thusly compiled myself a nice IPSec profile with all of the more common services in both server and client options. No RRAS or ICF needed! You can download it here

It is an IPSec export and thus you can simply do this:


The ones I have picked for my server are:


This then means you DENY ALL traffic except those explicitly PERMITTED.

NOTE: "SciBit" is my own company's ADSL IPs, granting unlimited access, as is the case for the "SM" rule. So you might want to rename this SciBit-rule to reflect your company name, and update the IP range to your IPs which you use to admin your server. For example, so that you can do Remote Desktop without enabling it for the whole internet.

NOTE: The advantage of using the Spirus rule is this; usually your domain will need a secondary MX DNS record as a backup or so that other SMTP servers can check that your domain is a valid one and has valid MX records and not see you as a spammer. This however leaves your SMTP open to be accessed by the sending SMTP server (which might indeed be a spammer), i.e. directly to your IP, instead of via the Spirus incoming que. So, using the Spirus rule will disallow all incoming SMTP connections to your machine, except from a Spirus server. Thus a best of both worlds, you can have your MX record but also force all incoming mail to go through your primary MX server, i.e. Spirus. The disadvantage is that the Spirus IPs can of course change, so be careful and make sure the Spirus IPs are still the same, especially if you one day see you have no emails.

After you have picked your rules, you can simply rightclick the policy in the MMC and Assign it. Only one policy can be assigned at a time. No restart is needed and it takes one second. If something is wrong, you can just as easily unassign it. Also, after it is assigned can you disable your ICF (if it was enabled on your NICs). If you keep ICF enabled, then your symptoms will reflect the following sequence:

Server -> All Services -> IPSec -> ICF -> Internet

For example, with ICF kept enabled, you will still be blocking SM even if IPSec allows all their IPs. With ICF disabled, can IPSec work its magick and you'll have the full advantages, e.g. the following sequences:

Server -> Min. Services -> IPSec -> Internet
Server -> Avg. Services -> IPSec -> SM
Server -> Max. Services -> IPSec -> Your Admin IPs

Thus, everyone can have a different view of your server.

To check what is visible on your webserver from the internet, use the following from your server's webbrowser:
http://www.grc.com, click on the ShieldsUp logo, on the next page scroll waaaay down until you see the ShieldsUp link, then click and then do a Common Ports scan on the next page.

What is nice about this setup is that even though my server runs FTP, SMTP, HTTP, HTTPS, IMAP, POP3, MySQL, etc etc... only HTTP & HTTPS are visible to the general internet. The rest are only visible to SM and myself, which leaves me fully capable of FTPing new files, connecting to my MySQL, Remote Desktop etc.

NOTE: In general it is not a good idea to allow full access to a subnet of IPs which are dynamically assigned each day. Someone on the subnet can then still hack away, all be it that the hacker would be limited to 65536 or even just 256 IPs to try from, which is less than 0.00001% of the internet. But just to play it save, you can allow your remote desktop/terminal service server (port 3389) open, so if the IP range change one day without you knowing beforehand, you can still get to your server. If you don't want to do this, can you also simply setup a lockout on your remote user account for a 3 strike situation with an auto-unlock after a predetermined time. In a worse case scenario you can always ask the helpful SM personel to login using Remote Desktop and enabling the Remote Desktop for all IPs so that you can login again. Keep a Policy Profile desktop icon handy for this scenario so that they don't need to go searching!

As second tier protection (on top of the IPSec), can you also enable specific services' restrictions, e.g. my FTP service and remote MySQL username is limited to range of specific IPs. So even though my local IPs and SM's have full access to the server, some services will not allow a SM IP range login.

Regards, J

The link isn't working for me: http://70.85.92.50/SetupIPSec.zip

It gives "Bad Request (Invalid Hostname)" error.

Well, the last post was March 2005; over 18 months ago.

And that address is an IP address so he could have moved the site to a different IP or upgraded to a new server over that period of time.

Perhaps, you have to put he link with a domain name instead of the IP to prevent moving server in the future ! . . .