[Firehol-support] Extending complex service FTP

[Costa Tsaousis]

Hi Andre,

> I am currently trying to extend/recreate the FTP service definitions. I
> have a router R and two machines M1 and M2 behind the router. 
> 
> I have http running on M1 and ftp on M2. My ftp server is setup to
> listen on ports 2500:2520 (one port for each virtual ftp domain).
> 
> 2 Questions:
> 1) With the setup I have below it is not possible to do passive FTP to
> the FTP server and my definition is too simple to allow for conntrack to
> work. Is it possible to modify the existing FTP server definition in an
> easy way  to gain full FTP functionality with different ports?

The FTP service needs an FTP conntrack module, which allows the random
socket connection made for the data transfer by the FTP server/client,
to be matched as RELATED to the initial request. I don't think that this
module will understand ports 2500:2520 as FTP requests, and therefore it
will not allow either active or passive data connections RELATED to
these ports.

I think it would be better to have either multiple IPs on your machine
and bind one FTP server to each IP, or use an FTP server with virtual
domains support (if I remember correctly, ProFTPd is one of those).
If you use either of these two methods, FireHOL's FTP service will
operate as expected.

If however you cannot use any of the above, I suggest to use this for a
safe Active FTP server (ONLY ACTIVE FTP AND ONLY SERVER):

---

# Custom FTP Server Control socket
server_myftpc_ports="tcp/2500:2520"
client_myftpc_ports="default"

# Customer FTP server Data socket
server_myftpd_ports="tcp/1024:65535"
client_myftpd_ports="default"


interface ...
	# Our custom FTP server
	server myftpc accept
	client myftpd accept

---

DO NOT REVERSE server/client FOR AN FTP CLIENT OF THIS FTP VARIATION.
IT WILL BE A HUGE SECURITY HOLE.


> 2) I have only set up one router and was wondering what the best/most
> elegant solution is to split traffic up depending on the type of
> traffic? Define multiple routers with destination ip addresses set for
> each service or one router with the service destination IP addresses
> set?

I like to think with the concept of "zones". A "zone" (for me) is a
subnet of machines they are related to each other, and which I am
willing to protect.

Normally you are going to face a situation similar to this:

Servers A, B, C on subnet S1 form ZONE1, connected on interface I1
Servers D, E, F on sunbet S2 form ZONE2, connected on interface I2
Then there is the Internet (of course), on interface I3

I1 and I2 might be the same, but not necessarily.

Here is what I do:

# Internet - to - Zone1 (and vice versa)
router i2z1 inface I3 outface I1 src not "${UNROUTABLE_IPS}" dst S1
	server x accept dst A
	server y accept dst B
	server z accept dst C
	...
	
	client x1 accept src A
	client y1 accept src B
	client z1 accept src C
	...

# Internet - to - Zone2 (and vice versa)
router i2z2 inface I3 outface I2 src not "${UNROUTABLE_IPS}" dst S2
	server x accept dst D
	server y accept dst E
	server z accept dst F
	...
	
	client x1 accept src D
	client y1 accept src E
	client z1 accept src F
	...

In the above, INPUT (inface/src) is the Internet and OUTPUT
(outface/dst) is the zone to be protected. Given that, I then "think" of
all the rules as if I was the machine(s) protected from the Internet
(i.e. same concept with the interface rules).

Then, if there is need for routing traffic between the zones, I prefer
to do this (for clarity, since both sides are to be protected from each
other):


# Zone 1 to Zone 2
router Z1toZ2 inface I1 outface I2 src S1 dst S2
	route x accept src A dst D
	route y accept src B dst E
	...

# Zone 2 to Zone 1
router Z2toZ1 inface I2 outface I1 src S2 dst S1
	route x accept src D dst A
	route y accept src E dst B
	...

These are unidirectional routers (in concept) and state very clearly
what can be requested by clients running on the INPUT, from servers
running on the OUTPUT.

Remember that inface/outface/src/dst match the REQUEST, not the REPLY.


Costa