# PF: can't get ftp to work



## graudeejs (Aug 27, 2009)

I've started learning of, and have manse some simple pf.conf
Everything works, except ftp. I even got torrents to work 
I've read http://www.openbsd.org/faq/pf/ftp.html but somehow I can't get ftp to work....

/etc/pf.conf

```
ext_if = "rl0"
ext_ip = "192.168.128.100"
lo_if = "lo0"
net_type = "inet"

ssh_port = "60386"
torrent_tcp_port = "6890"
torrent_udp_port = "6881"

common_pass = "{ http, https, domain, ftp, ftp-data, imaps, nameserver, nicname, xmpp-client, silc, ntp," $ssh_port "}"
tcp_pass = "{ ircd, ftp-proxy }"
[color="Gray"]#udp_pass = "{ }"[/color]

common_block = "{ ssh, telnet }"
[color="Gray"]#tcp_block = "{ }"
#udp_block = "{ }"[/color]



nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $ext_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 

antispoof log for $ext_if


[color="Gray"]# Block and log everything[/color]
block log all
[color="Gray"]# excetp lo0[/color]
pass quick on $lo_if all
[color="Gray"]# blcok default ssh port and telnet port[/color]
block quick log on $ext_if proto { tcp, udp } from any to any port $common_block


[color="Gray"]# Enable Torrents tcp[/color]
pass in quick on $ext_if $net_type proto tcp from any to $ext_ip port $torrent_tcp_port keep state
pass out quick on $ext_if $net_type proto tcp from $ext_ip port $torrent_tcp_port to any keep state
[color="Gray"]# Enable Torrents udp[/color]
pass in quick on $ext_if $net_type proto udp from any to $ext_ip port $torrent_udp_port keep state
pass out quick on $ext_if $net_type proto udp from $ext_ip port $torrent_udp_port to any keep state
[color="Gray"]# Enable Torrents listen for incoming connections[/color]
pass in on $ext_if $net_type proto tcp from any to $ext_ip port 10000:65000 keep state


[color="Gray"]# Enable services on TCP and UDP[/color]
pass in log on $ext_if $net_type proto { tcp, udp } from any to $ext_ip port $common_pass
pass out log on $ext_if $net_type proto { tcp, udp } from $ext_ip to any port $common_pass

[color="Gray"]# Enable services on TCP[/color]
pass in log on $ext_if $net_type proto tcp from any to $ext_ip port $tcp_pass
pass out log on $ext_if $net_type proto tcp from $ext_ip to any port $tcp_pass
```

/etc/rc.conf

```
ifconfig_rl0="inet 192.168.128.100 netmask 0xffffff00"
defaultrouter="192.168.128.1"
hostname="killasmurf86.homepc"

pf_enable="YES"
pflog_enable="YES"
ftpproxy_enable="YES"
```

Here's what's happening after I try to connect to my ISP ftp server

```
# tcpdump -ttt -n -e -r /var/log/pflog | grep 83.241.1.212             
reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
00:00:00.001914 rule 50/0(match): pass out on rl0: 192.168.128.100.64961 > 83.241.1.212.21: Flags [S], seq 3701767531, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS[|tcp]>
00:00:00.164179 rule 8/0(match): [color="Red"]block out[/color] on rl0: 192.168.128.100.24090 > 83.241.1.212.12912: Flags [S], seq 680468111, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS[|tcp]>
00:00:00.004795 rule 8/0(match): [color="Red"]block out[/color] on rl0: 192.168.128.100.53138 > 83.241.1.212.8637: Flags [S], seq 803526260, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS[|tcp]>
```


Any iseas what did I do wrong? I'm already hitting my head against wall
:OOO

This is my desktop PC behind wireless router.


----------



## vivek (Aug 27, 2009)

Do you want outgoing ftp client or incoming ftp server request?


----------



## vivek (Aug 27, 2009)

Here is what I've my system

```
# Outgoing ftp
pass out on $ext_if inet proto tcp from any to any port ftp
pass out on $ext_if inet proto tcp from any to any port >1023
```


----------



## graudeejs (Aug 27, 2009)

I want outgoing ftp client
I need to download ports


----------



## vivek (Aug 27, 2009)

Did you tried out above rules? They are working for me.. I had exactly same problem you have. make install clean wasn't working coz it cannot download. After adding above two lines it worked out for me.


----------



## graudeejs (Aug 27, 2009)

Yes, that should work, but what's the point of firewalling, if you allow traffic in and out on almost all ports

In your code you allow out, I had to enable traffic in for torrents


----------



## vivek (Aug 27, 2009)

yes, that is main problem with ftp, especially when you don't have dedicated bsd router to do NAT. With nat and proxy it will be more easy as specified in openbsd PF faq.


----------



## graudeejs (Aug 27, 2009)

Well, currently I see only 3 options
1) what you said
2) make script, that would extract list of ftp servers, from ports, and make white list, that would be loged, That is not elegant solution, but it's better, than opening 99+% ports for everyone
3) do what you said + add log to your line, and keep it last rule, other rules, that pass, should be quick

EDIT:
appended text for 2


----------



## gordon@ (Aug 27, 2009)

Use Passive FTP.


```
export FTP_PASSIVE_MODE=true
```


----------



## DutchDaemon (Aug 27, 2009)

It looks like it's already passive, since the client is making all the outgoing connections (see  flags on 'block out' lines).

However, I thought passive FTP always used ports between 49152 and 65535, making much more restrictive rules possible.


----------



## honk (Aug 27, 2009)

You redirect all connections to port 21/tcp on your >>external<< interface. I'm not sure if this works as you redirect on the external interface (back) to loopback.

These are the moments where I miss special "service objects" in pf for protocols like (t)ftp, rpc and so on, where the firewall needs to inspect the communication to allow further communication...

cheers,
honk


----------



## aragon (Aug 28, 2009)

I'm guessing pf's rdr can't redirect packets generated by the local machine.  You can use ipfw's divert and natd's -punch_fw parameter instead.

Or disable passive mode and just permit incoming tcp:20 -> tcp:49152-65535


----------



## FryShadow (Aug 28, 2009)

I have mine something like this, maybe you miss the keep state and anchor


```
nat on $ext_if from !($ext_if) -> ($ext_if:0)

nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"

rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 \
    port 8021

rdr pass on $int_if proto tcp from any to any port www -> 192.168.2.1 port 3128

# Filter
block in

pass out keep state
pass out quick on $int_if from any to any keep state
pass in quick on $int_if from any to any keep state

anchor "ftp-proxy/*"
```


----------



## graudeejs (Aug 28, 2009)

DutchDaemon said:
			
		

> However, I thought passive FTP always used ports between 49152 and 65535, making much more restrictive rules possible.



I don't know, will look in to that



			
				FryShadow said:
			
		

> ```
> # Filter
> block in
> 
> ...



Man you don't block anything at all
Do you have more than 1 network card?
if $int_if doesn't contain lo0, then you're blocking it as well (not a good idea, as far as I understand)


----------



## FryShadow (Aug 28, 2009)

Yes I have 2 network card, allow all at top from $int_if and I have several filtering rule besides that 

block in will block anything coming into $ext_if and as per below rules will pass in my $ext_if :


```
tcp_services="{ ssh, http }"

pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services flags S/SA keep state
```

Some blocking rules that prevent connection from my network to outside :


```
test="{ pop3, pop3s, smtp }"

# Sample block
block out on $ext_if inet proto tcp from any to any port $test
```


----------



## graudeejs (Aug 28, 2009)

I wrote a little, ugly, dirty, slow script, that generated list of ftp servers used in ports...

Had to remove 1 fake entry.... manually (will investigate).
I will improve this script later, when I have better mood


```
#!/usr/bin/perl

system("find /usr/ports -name Makefile -or -name bsd.*.mk > /tmp/file_list");
system("find /usr/ports/Mk -name bsd.*.mk >> /tmp/file_list");
system('for i in `cat /tmp/file_list`; do grep -e \'ftp://\' $i >> /tmp/ftp_list; done');

open(LIST, '<', "/tmp/ftp_list");

my @wlist;
my $i=0;
my $unique;
readitem: while (my $item = <LIST>) {
	unless ($item =~ /^#/) {
		chomp $item;
		$item =~ s/^.*ftp:\/\///;
		$item =~ s/\/.*$//;
		foreach $unique (@wlist) {
			next readitem if ( $item eq $unique );
		}

		print "$item\n";
		push(@wlist, $item);

	}
}
close LIST;

system("rm -f /tmp/file_list /tmp/ftp_list");

exit 0;
```
Ye, it's ugly

save it as and when you run it, redirect output to some file, that will be ftp white list.


I've attached my output....
This white list has 1497 unique ftp servers
I find this way better, than letting everyone out 
IF you use other servers not in ports, you can add them to list, or make additional, list, where you keep them.

Also do you think maintaining such list could be useful? It could installed as port... or maintained by fresh ports....

EDIT:
attachment removed....
see below for new attachment


----------



## graudeejs (Aug 28, 2009)

killasmurf86 said:
			
		

> Well, currently I see only 3 options
> 1) what you said
> 2) make script, that would extract list of ftp servers, from ports, and make white list, that would be loged, That is not elegant solution, but it's better, than opening 99+% ports for everyone
> 3) do what you said + add log to your line, and keep it last rule, other rules, that pass, should be quick



There's 4th option, turn on and of specific rule (for ftp) every time you need it


----------



## honk (Aug 29, 2009)

@killasmurf86: Have you seen /usr/ports/ftp/ftpsesame ? Might help but I don't know how secure the code is (the state engine for parsing the ftp command channel).


----------



## graudeejs (Sep 1, 2009)

```
#!/bin/sh
# Copyright (c) 2009, Aldis Berjoza <killasmurf86@gmail.com>
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# * Redistributions of source code must retain the above copyright
#   notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above
#   copyright notice, this list of conditions and the following disclaimer
#   in the documentation and/or other materials provided with the
#   distribution.
# * Neither the name of the  nor the names of its
#   contributors may be used to endorse or promote products derived from
#   this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# This scrip will create 'wlist' file, that will contain IP of all
#   ftp servers found in ports collection
# You may use this script to generate ftp server whitlist for pf
#
# http://killasmurf86.blogspot.com

find /usr/ports -name Makefile > /tmp/.ftp_list_1
find /usr/ports/Mk -name bsd.*.mk >> /tmp/.ftp_list_1

for i in `cat /tmp/.ftp_list_1`; do 
	grep -e 'ftp://' $i >> /tmp/.ftp_list_2
done

sed 's/#.*$//g' /tmp/.ftp_list_2 | sed 's/^.*ftp:\/\///' | sed 's/\/.*$//' | sort | uniq - /tmp/.ftp_list_3

grep -E -e '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' /tmp/.ftp_list_3 > /tmp/.ftp_list_4

for i in `cat /tmp/.ftp_list_3`; do
	dig +short "$i" | grep -E -e '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' >> /tmp/.ftp_list_4
done

sort /tmp/.ftp_list_4 | uniq - wlist
rm -f /tmp/.ftp_list_[1234]

exit
```

This generates list of ftp servers used in ports.

I've uploaded resulting list of ip's.


----------



## graudeejs (Sep 1, 2009)

DutchDaemon said:
			
		

> It looks like it's already passive, since the client is making all the outgoing connections (see  flags on 'block out' lines).
> 
> However, I thought passive FTP always used ports between 49152 and 65535, making much more restrictive rules possible.




I find this simple and short article pretty good:
http://www.velikan.net/iis-passive-ftp/


http://slacksite.com/other/ftp.html (haven't read yet, but will)


----------



## graudeejs (Sep 1, 2009)

Here's what I came up with:


```
ext_if = "rl0"
table <ext_ip> persist { 192.168.128.100, 192.168.128.99 }
net_type = "inet"

table <ftp_wlist> persist { ftp.some.other, ftp.servers.that.i.use }
table <ftp_ports_wlist> const file "/etc/wlist"

block log all
...
...

# Enable passive ftp
pass out log on $ext_if inet proto tcp from <ext_ip> port >1023 to { <ftp_ports_wlist>, <ftp_wlist> } port { ftp, >1023 } keep state
#pass in log on $ext_if inet proto tcp from { <ftp_ports_wlist>, <ftp_wlist> } port {ftp, >1023} to <ext_ip> port >1023 keep state
```


----------



## vivek (Sep 2, 2009)

```
/etc/wlist
```
/etc/ is for base, for all user needs use /usr/local/etc. This is suggested  practice.


----------



## graudeejs (Sep 2, 2009)

I know I know...


----------



## mamalos (Sep 3, 2009)

Killasmurf,

looking at your code:



			
				killasmurf86 said:
			
		

> Here's what I came up with:
> 
> 
> ```
> ...



I see no reason why you need the second rule,whatsoever. In order to allow outgoing ftp connections from your machine to your white list's ftp servers, the first rule, is adequate. 

The second rule allows incoming traffic from your whitelist's servers having source port {ftp, >1023}, to your machine on port > 1023 (?!?!?!). Why?!!?!? You do not need this rule. If you use it, you just open your firewall with no reason. And this time you *really* open your firewall for incoming connections for all ports > 1023. Your first rule is statefull, so your job is done.

Lastly, if you place a firewall on your personal machine (and not a router or a server), there is no worry to allow outgoing connections statefully. You just block all incoming traffic and allow all outgoing traffic statefully. That is, of course, if you trust your personal machine..


----------



## dennylin93 (Sep 3, 2009)

mamalos said:
			
		

> Lastly, if you place a firewall on your personal machine (and not a router or a server), there is no worry to allow outgoing connections statefully. You just block all incoming traffic and allow all outgoing traffic statefully. That is, of course, if you trust your personal machine..



It is much more convenient this way, but it has a higher risk. Occasionally, some programs will have vulnerabilities, and when they do, someone might take advantage of them and send some nasty stuff.


----------



## mamalos (Sep 3, 2009)

dennylin93 said:
			
		

> It is much more convenient this way, but it has a higher risk. Occasionally, some programs will have vulnerabilities, and when they do, someone might take advantage of them and send some nasty stuff.



Yes, but as we all know, once we're not running win* OSes, the possibility to install trojans and/or viruses/malware on our boxes is extremely low. Moreover, if such a program reaches our boxes, then the traffic it will produce will probably be directed to "legitimate" ports... 

I don't know, when I was younger I used to restrict even my laptop's outgoing traffic to specific ports, and I also used to log my block rules on disk. The more I get older the more I come to the conclusion that I do not gain much from this policy, and tend to leave all outgoing traffic of my external interfaces free (statefully), and block all incoming traffic except from the specific ports I run services on.

...then again, all these are personal opinions..


----------



## graudeejs (Sep 3, 2009)

Thanks, for fixing my firewall rule 
I had wrong understanding of out and in.... I thought it was about traffic, not incoming/outgoing connection


----------



## graudeejs (Sep 3, 2009)

I want to become admin, so sometimes I treat my box as if it was server


----------



## mamalos (Sep 3, 2009)

You are kindly welcome!

You do well that you treat your laptop as a server, this is my approach too. Try using freebsd jails to play with services, and you'll become well acquainted with pf and firewalls as well.

My idea of learning how to build "good" firewalls is to first read a good book about them, even those that refer to older firewall syntaxes (as those not mentioning statefull filtering), because of the fact that you'll have to understand how the traffic flows through them (more rules are written but you get a good understanding of how it works, and statefull firewalls become much easier to develop afterwards). A good old book regarding firewalls is "building internet firewalls" from O'Reilly, but this is not the only one. Most guides and howtos around the Internet are not very strict with the way they teach firewall building. Even the "pf guide" (which is not a tutor's book of course, and is an excellent guide in general) uses "any" in most of its examples instead of using"!$my_pc" or "!$my_external_interface". This allows, under certain conditions only, spoofed packets to pass through these rules. In any case !$my_interface is the "mathematically" correct clause in most cases. 

Once you get a good idea of how the IP suite works, building a firewall in most implementations will become a lot easier (you'll only have to learn the semantics and syntax of each vendor). 

Lastly, one of the things that makes pf my best choice to use for firewalls, is the policy-based filtering that it allows. Try understanding how "tagging" works, and you'll turn out to write very easy to read-and-administer pf.conf's.


----------



## mamalos (Sep 3, 2009)

...ah! and a last rule of thumb, which is valid on most firewall syntaxes:

in and out clauses refer to the interface. In means that the traffic flows your interface's next hop to the specific interface, and out means the opposite. From an to clauses refer to what the packet states as source address and destination address. So even though that these two clauses seem similar, this is not the case (always keep spoofing in mind). In and out refer to the direction of traffic relative to the interface the rule refers to, and from and to refer to the IP headers of the packet traversing the particular interface.

Good luck with your study on firewalls!

PS. Pay a good deal of attention whether you (or your firewall vendor) follow a first-rule-match policy, a last-rule-match or both. As your rulesets grow, many mistakes may arise if you don't keep it in mind, where you don't expect them to.


----------



## mamalos (Sep 3, 2009)

...oops some quick corrections on my previous post:



			
				mamalos said:
			
		

> ..."In" means that the traffic flows from your interface's next hop to the specific interface, and "out" means the opposite. "From" and "to" clauses refer to what the packet states as source address and destination address. So even though that these two clauses seem similar, this is not the case (always keep spoofing in mind). "In" and "out" refer to the direction of traffic relative to the interface the rule refers to, and "from" and "to" refer to the IP headers of the packet traversing the particular interface.


----------



## graudeejs (Sep 3, 2009)

My strategy is to block everything.
Then quick block in/out ssh and telnet

and then allow in/out one by one...


----------



## mamalos (Sep 3, 2009)

killasmurf86 said:
			
		

> My strategy is to block everything.
> Then quick block in/out ssh and telnet
> 
> and then allow in/out one by one...



Your first two rules overlap, canceling your second rule.

You could first block quick all spoofing-traffic on each interface for both directions. So if you have eg. 2 interfaces, you need 4 rules for that. This way you are through with spoofing once and for all. Next you could bock all traffic. After that you may start with quick pass rules to allow access to the services of interest, on each interface and each direction. In very-very advanced setups (where first-rule-match policy fails), you may combine quick pass rules and plain pass rules, but this is very rare. Try keeping the same strategy for your whole setup.


----------



## DutchDaemon (Sep 3, 2009)

Most rules can work without direction, so e.g.


```
antispoof quick for { $ext_if $int_if }
```

and


```
scrub all
```

are entirely functional.


----------



## mamalos (Sep 3, 2009)

This is true, and this is why we usually use "block all" when we start our rulesets. Nevertheless, in your example, the antispoof syntax is ok for our laptops, but is not that "protective" in routers, where specific non-routed networks should be used for each direction. Moreover, in rare scenarios (where one may need to have the same subnet on two interfaces, in a bridge-firewall, with no IP on the specific interfaces. An example which I have come up to), the way "antispoof" works may yield unwanting results (it will block incoming traffic from these hosts on both interfaces).
In general, I use antispoof for simple setups (non-routers setups, and/or sometimes non-servers setups). For the rest of my setups, I keep a list of non routable IPs in one of more files, which is copied to a table when pf starts. The list is updated when IANA changes its list of non routable networks.


----------



## DutchDaemon (Sep 3, 2009)

I don't think antispoof and unroutable networks in general have a lot do with one another; antispoof just forces a particular network to remain 'attached' to a particular interface. 

So if you have 192.168.0.0/24 on interface fxp0, 'antispoof fxp0' stops incoming traffic from 192.168.0.0/24 on any other interface, and the antispoof rule expands to:


```
block drop in quick on ! fxp0 inet from 192.168.0.0/24 to any
```

And whether it's RFC1918 netspace or a publicly routable IP network does not matter. The only difference wrt antispoof is that using it on a public IP network will add an extra rule:


```
block drop in quick on ! re0 inet from public.ip to any
block drop in quick inet from public.ip to any
```

For RFC1918 space, I just use a table on the basis of IANA data, and several 'bogon' sources.


----------



## mamalos (Sep 3, 2009)

DutchDaemon,

by saying antispoof, one thinks what the word says: anti-spoof ; and in particular we mean anti-IP-spoofing. So if I want to use a rule for anti-spoofing I should first consider which would be the spoofed packets that could pass through an interface (different for each direction). These would be all non-routeable networks, along (maybe) with all other networks which I know that shouldn't pass, because they maybe "belong" to some other segment of my network (or interface). So for antispoofing rules, I use the list I told you before. To achieve what antispoof clause stands for, a typical technique would be to use $my_specific_net in the from clause of a pass-in rule, eg.

pass in [quick] on $some_if inet proto $some_proto from $my_specific_net to $blabla[or any] [keep/modulate state]

that way I achieve the same result, by just being more specific with my rules.

If I want to also include the interface's IP (which is what antispoof does when expanded to rules), I could use the following table (not just a list, since it will have completely different results, beware!! the list expands to a sequence of similar rules!):

table <my_specific_net> { 192.168.0.0/24, ! 192.168.0.1}

In this scenario, my interface has the 192.168.0.1 IP, and the network subnet it belongs to is 192.168.0.0/24.

Using this table in the aforementioned example rule, instead of $my_specific_net would replace the use of the antispoof clause, without being more generic than one should.


----------



## DutchDaemon (Sep 3, 2009)

mamalos said:
			
		

> DutchDaemon,
> 
> by saying antispoof, one thinks what the word says: anti-spoof



Sorry, but no. This was and is a thread about PF, and antispoof is a PF concept. So semantics and redefining the subject matter are fine, but we do like to stick to the topic at hand when choosing our words ever so carefully ... So put the goalposts back


----------



## mamalos (Sep 3, 2009)

Ok DutchDaemon, you're the moderator . I just posed my opinion on how understand antispoof..but to be honest, our conversation on antispoofing started from a comment on one of my previous replies which stated that:

"You could first block quick all spoofing-traffic on each interface for both directions...bla bla"

Then you replied with the antispoof-clause alternative. All I was talking about in that message, was antispoofing, not "interface-attaching". Therefore I quoted my last messages, as well as this one.

But as I stated before: ok, you're the moderator


----------



## DutchDaemon (Sep 3, 2009)

I'm giving the mic back to killasmurf86. How's your FTP coming along?


----------



## graudeejs (Sep 3, 2009)

DutchDaemon said:
			
		

> I'm giving the mic back to killasmurf86. How's your FTP coming along?



Works like charm


----------



## FryShadow (Sep 5, 2009)

well done killasmurf86


----------



## vivek (Sep 5, 2009)

So I was right all this time  heh



> want to become admin, so sometimes I treat my box as if it was server


Move your blog to your own server and you will become the admin. Real geeks use wordpress, hosted on their own box


----------



## graudeejs (Sep 5, 2009)

I don't have job to earn money, just to host my blog/mail server


----------



## vivek (Sep 5, 2009)

You can host it on your home server. It can be done one 1M ADSL connection too..are you connected via slow Dialup / Mobile phone?


----------



## graudeejs (Sep 5, 2009)

I have good net (Up/Down: 100Mbs)... the problem will be increased electricity bill 
Besides that I sleep in same room (for now)


----------



## vivek (Sep 7, 2009)

> the problem will be increased electricity bill


 A few years ago I was in same condition and end up building my own router using soekris board. I brought it from eBay. It came preinstalled with GNU/Linux 2.4 kernel. I got rid of Linux and installed FreeBSD. It was a fun project! 

http://people.freebsd.org/~alfred/pxe/en_US.ISO8859-1/articles/pxe/article.html

http://www.soekris.com/net4501.htm

Happy hacking!


----------



## brd@ (Sep 13, 2009)

The correct solution to this problem is to use ftp-proxy. See this link for more info: http://www.openbsd.org/faq/pf/ftp.html


----------

