how to secure an ftp with ipsec

leprechaun

Anyone know know how to secure an ftp with ipsec...doing some studying here but cant seem to get it right..
ej.

royal

You can use ipsec policies through group policy or through a local policy if you are using a Windows machine.

http://www.petri.co.il/configuring_ipsec_policies_through_gpo.htm
http://technet2.microsoft.com/WindowsServer/en/library/9333ed11-48bc-449e-accf-54eb62d1d5f31033.mspx?mfr=true

sprkymrk

Wow, that's actually a loaded question. IPSec is a great tool that goes largely unused due to it's seeming complexity. Keatron and I even talked about this and he described to me that he has seen a poor implementation of IPSec bring down entire networks and I can certainly understand why.

IPSec has many pieces to it, but the first piece is the "policy". You can create your own or use one of the built in policies. If we were going to take your example, we could simply use the default "Secure Server" policy which means that the server will always require security using Kerberos. Your clients can use the Client (Respond Only) policy. This alone now means that your FTP traffic is protected with 3DES and SHA1 for integrity and privacy (encryption) if you leave the defaults - which you can view by double clicking the "Secure Server", then the General Tab, Advanced button and finally the Methods button.

But you can make this rule more granular to actually protect the server, rather than just the traffic. Assuming you only need FTP, you can actually create your own IP Filter Rule to a policy, and stepping through the wizard you would select the appropriate settings for FTP - for instance make the source address to your client's IP or the entire client subnet. (Note - remember that in this example of IPSec we are using the MS implementation of Kerberos which will be limited to the AD domain itself). Make the Destination to "My IP Address". On the Protocol screen select a protocol type TCP.

Select "From any port" (clients will open a random high port as the source) and change the "To any port" to "To this port" and enter 21 (FTP). Configure this filter to require security and accept the packets, then create another filter for all other communications and set the filter action to "block".

It would litterally take about 3 pages to walk you through the settings, but the links provided by icroyal should give you a good start. I'm sorry I faded out toward the end there, but I realized I was probably boring people and liable to make a mistake without a professional technical editor to second guess me.

However, if you still have problems post back and I'll try to help. A good IPSec policy is something you "set and forget", which is what I apparently have done - I am going to have to review my stuff now that you brought up the subject...

keatron

I'll add a little to what Mark has already suggested.

1. Mark mentioned policy first and that's a good idea, because if you don't fully understand the policies you're doomed for failure before you get started. We need to not forget that we're talking about Microsoft's implementation of IPSec. Not that it's a bad thing, but it's not the generic IPSec standard implementations we often get it confused with. There are several enhancements to the 2003 version of IPSec over the 2000 version. But do understand that some of the enhancements ARE 2003 server boxes.

The Windows 2000 and Windows XP implementations of IPSec supported Diffie-Hellman groups 1 and 2. The group numbers refer to the number of bits of keying material, which ultimately affect the strength of the key itself. Groups 1 and 2 are 768 and 1024 bits, respectively. However, with Windows 2003, Microsoft has included a 2048-bit Diffie-Hellman algorithm. The 2048-bit algorithm is exponentially more secure than the 1024-bit algorithm, but it does have some negatives. First, a 2048-bit algorithm takes longer to compute (resource usage might spike here) than a 1024-bit algorithm. The other problem is that it is only compatible with Windows Server 2003. The strongest algorithm that can be used in communications between Windows 2000, XP, and 2003 is Diffie-Hellman group 2 (1024-bit). So please stick with group 1 or 2 for now. I bring this up because I've read a few articles by "experts" saying to go with 3 to take advantage of the 2048 bit algorithm. Only to see the author get flamed by angry readers who did as suggested and couldn't figure out why they could only communicate with other 2003 Server machines.

Keep the following things in mind since you're securing FTP communications; There is some overhead in the IKE negotiation (5 round trips for full new SA setup and 2 round trips for a re-key). CPU usage on the clients may be a problem, especially if the client is doing a decent sized transfer. Microsoft says this "CPU on servers can be a problem but it can be mitigated by using IPSEC offload cards from vendors like 3COM". Ahhh, my experience is you don't even want to go there. I tell you these things so that you can be aware, I'm certainly not saying don't do it. I just want you to be prepared and plan accordingly for any resource overhead you might experience.

One of the best features of the 2003 implementation of IPSec is NAT traversal support. Try IPsec'ing between two hosts across a NAT device with versions previous to 2003....painful.

Keep in mind when you enable Secure Server (Require Security), ANY device that is not IPSec enabled will fail to communicate with this server (not really but, at higher layer protocols it will appear this way).

Probably my most important piece of advice is this; Become very familiar with IP Security Monitor. Without this you're fighting blind. There is a IPSec extension to the group policy RSOP tool and it's almost as useful.

Also, don't over estimate IPSec security. By default in Windows 2000 implemenations, there are these errr things known as default exceptions. Microsoft lists these. Kerberos, Broadcast traffic, multicast traffic, and RSVP (Resource Reservation Protocol) traffic. But the truth of the matter is this; any traffic that MS IPSec can't classify, it will not encrypt and it WILL NOT apply any filter rules to that traffic. I expressed this concern before and I was basically told this Kerberos is itself a security protocol that does not need to be secured by IPSec. The Kerberos exemption is basically this: If a packet is TCP or UDP and has a source or destination port = 88, permit. Interesting. So all it takes is some nifty packet crafting and ahhhh that traffic is permitted to pass, by default. Here my point. These default exemptions can be easily used to bypass IPSec security. But behold, there is a solution. If you're using Windows 2000 server or Professional or XP, modify this registry key NoDefaultExempt=0 to be NoDefaultExempt=1. If it's Windows 2003 it's set to 1 by default.

There could be volumes of books written on IPSec alone (I've composed quiet a few articles alone), so it definitely requires some reading and testing before deploying. If you have a test lab this would be a good place to start. If you don't have one, build yourself one with VMWare or Virtual PC and test away. IPSec is based on rules that depend on LAYER 3 AND ABOVE information, all of which can be forged.

Now I was tempted to go off on a tangent about how to use bogus IPSec traffic to bypass firewalls, but I just realized I wasn't posting in the Security Forums.

Keep us posted on your progress.

sprkymrk

keatron wrote:

Also, don't over estimate IPSec security. By default in Windows 2000 implemenations, there are these errr things known as default exceptions. Microsoft lists these. Kerberos, Broadcast traffic, multicast traffic, and RSVP (Resource Reservation Protocol) traffic. But the truth of the matter is this; any traffic that MS IPSec can't classify, it will not encrypt and it WILL NOT apply any filter rules to that traffic. I expressed this concern before and I was basically told this Kerberos is itself a security protocol that does not need to be secured by IPSec. The Kerberos exemption is basically this: If a packet is TCP or UDP and has a source or destination port = 88, permit. Interesting. So all it takes is some nifty packet crafting and ahhhh that traffic is permitted to pass, by default. Here my point. These default exemptions can be easily used to bypass IPSec security. But behold, there is a solution. If you're using Windows 2000 server or Professional or XP, modify this registry key NoDefaultExempt=0 to be NoDefaultExempt=1. If it's Windows 2003 it's set to 1 by default.

This was something I only noticed last night after clicking around in the IPSec Policies. I thought it was strange and put the thought in the back of my mind for future research. However, you already read my mind and confirmed my suspicions and saved me the trouble of googling.
Thanks for the registry tip.

Another method for controlling access (although you can't do it with Group Policies) to the same FTP server in the OP's example is to use TCP/IP Filtering in conjunction with IPSec policies. You can filter by slelcting "Permit Only" TCP Ports 21 and 20 (and whatever else you may need - a sniffer works good here) and then "Permit Only" Ip Protocols 50 (and maybe 51). This would create a very "network hardened" FTP server, one that you would have to manage at the console if you didn't create even more exceptions.

Keatron, I have a question while we are on the topic of IPSec - I realize that IPSec is used primarily because IPv4 was not built with security in mind. Will IPSec still be needed/useful in a fully IPv6 environment?

leprechaun

ok did a setup with vmware.. and win dows 2003 server..i ran the the ftp and ipsec but having a hellish time time securing it.when i gointo and check the logs i get an exclamation mark staing that it wont recognize the security. there i get it reset. and the same logs keep comming up.. just wondering if i am figuring this thing right...this all has to do with a project i am doing for school.Maybe the ports are wrong ...mmmmmHELP!!!!!

sprkymrk

leprechaun wrote:

ok did a setup with vmware.. and win dows 2003 server..i ran the the ftp and ipsec but having a hellish time time securing it.when i gointo and check the logs i get an exclamation mark staing that it wont recognize the security. there i get it reset. and the same logs keep comming up.. just wondering if i am figuring this thing right...this all has to do with a project i am doing for school.Maybe the ports are wrong ...mmmmmHELP!!!!!

Can you give us a little more (not a lot, but at least a little more) detail on what you mean by "ran the ftp and ipsec"? Also, can you quote or copy/paste the errors? Thanks.

leprechaun

will do

leprechaun

Ok figured this out..but would some imput on this issue..as why it still would work.
i had to do a reverse and forward lookup.
and add some security measures ....i did assign and use a digital certificate ( dont know why).
might i be missing something here..

sprkymrk

What was it that did or did not work? The IPSec, the FTP, something else? Were they on the same LAN and Windows domain? Any intervening devices?