[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 347
  • Last Modified:

Problems using portupgrade with ipfilter running

I can't get portupgrade to work properly on my FreeBSD server because of the ipfilter table running on it.
The solution sounds simple enough, to just change the table, but it doesn't seem that simple.

Portupgrade downloads various source code tarballs off the internet when various ports get upgraded. Portupgrade does this by using either ftp or http. Now here's the problem: I opened port 80 on the out -> in port, and packages that are fetched by http are getting in.

Here's the rule:- (xxx is just there to hide my global IP address)
pass out quick proto tcp from xxx.xxx.xxx.xxx/32 to any port = 80 keep state group 250

Now, when I make a similar rule to allow ftp:-

pass out quick proto tcp from xxx.xxx.xxx.xxx/32 to any port = 21 keep state group 250

FTP still fails.
A look at tcpdump shows that the server is actually connecting to the freebsd ftp servers using weird destination ports in the 1024+ range, but they are all random. No sight of port 21 to be seen. What's going on there?
I still managed to get portupgrade to work by simply disabling the packet filtering, but this isn't an optimal solution.

Can anyone tell me how I can adjust my ipfilter settings to make portupgrade go seamlessly without dropping packet filtering entirely?
0
Neo-Rio
Asked:
Neo-Rio
  • 6
  • 5
1 Solution
 
gheistCommented:
FTP is more complicated protocol.... You do not seem to understand it.
There is nothin weird in it, it works as designed, your stupid firewall configuration messes things up.

first you add ipmon_enable="YES" in /etc/rc.conf to get logs from your firewall, dumpig packets is more dangerous than disabling firewall.

normally ftp consists of control and data connections, and you deny later ones, so you get no files, portupgrade still works as expected - does not install unfetchable ports....

At first you connect to port 21 of ftp server
then either
1) you get connection to some port of your host from server port 20
1a) >1023 ...> 1023
2) you connect to ports >1023 on server

...

RFC959 and RFC1579 for more reference on breaking standard protocols
0
 
Neo-RioAuthor Commented:
Isn't there a way to create a rule in ipfilter to accept an FTP data connection, based on the state of the control conenction?
0
 
gheistCommented:
ipfilter accepts no connections
system accepts connection whenever ipfilter alows

there is no such facility.

the nat transparent proxy mechanism is different.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Neo-RioAuthor Commented:
gaaahh.... just about had it with this

I've got these rules in my fw scripts. I've tried what the FreeBSD handbook said in relation to this problem.

so far I've got this in my FW
pass out quick proto tcp from (my ip adress) to any port = 21 flags S keep state group 250

(group 250 is the group for all outgoing, tied to the ethernet interface I'm using)

Then, I enabled ipnat and did this in the config file:-

map bge0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp

Now, that than get a "No route to host" error message.... ftp just tries to connect and then times out. Obviously ftp is getting out now, but it sure as hell isn't coming back in.

0
 
Neo-RioAuthor Commented:
Actually I'm looking at the logs in ipmon, and I'm not seeing any action whatsoever.
ftp just times out with those new rules, and the ipf firewall isn't giving me any info as to why.

system log is no help either

a look in tcpdump shows that requests to the ftp domain are fine, and that port 21 is getting out of the machine. However, no packets are coming back in.

....and if I disable packet filtering thigns go ok, but I can't do that of course.


0
 
gheistCommented:
ftp proxy connects via notmal socket, so you nat it back to it self, and ride into inetd flood protector.
i do not see your ipf rules make anything into logs
0
 
Neo-RioAuthor Commented:
OK, I've fixed the problem now. We're currently in the process of shifting over to a different FW system and the server was pointing at the old one - which is wherre the problem was.

On an unrelated note, I need some help with the ipf daemon on one of my servers. I shutdown the ipf daemon with ipf -D and now it won't start up after port upgrade. I get an "ioctl(FIONREAD): Operation not supported by device" error when I try and re-enable it with "ipf -Fa -f /etc/ipf.ruletable" and if I use "ipf -E", the daemon simply shuts off all network activity entirely.

Any idea how to fix this? Will I just have to reboot it, or is this fixable on the fly?



0
 
gheistCommented:
ipf is not daemon, it is kernel module or device driver.
why you filter when you do not have any understanding of application you filter???

Most likely you attempt to disable kld version of ipf, this will not work, you need "kldunload ipf" instead

or maybe
ipf -IFa # flush inactive ruleset
ipf -Ifv /etc/ipf.rules # check syntax of your ruleset against inactive ruleset
ipf -s # swap rulesets

do not blame FreeBSD ports or system applications for your fireswall's operators lack of required skill.
0
 
Neo-RioAuthor Commented:
Flushing the inactive ruleset doesn't work either. Just spits out the same "ioctl(SIOCIPPFFL): Operation not supported by device"

Trying to check the ruleset against the inactive ruleset results in "ipf: fopen(v) failed: No such file or directory" ......wtf? The ipf rule file is definitely where I said it was.

ipf -s also spits put another error: "ioctl(SIOCSWAPA): operation not supported by device"

Seems like no matter what I try and do, something is Very Bad (tm) at a kernel level.
0
 
gheistCommented:
then you never loaded any ipf ruleset (and ipf kernel module)

it expects ruleset to  be in /etc/ipf.rules
and /etc/rc.conf set up this way:

ipfilter_enable="YES"
# ipnat_enable="YES"
ipmon_enable="YES"
0
 
Neo-RioAuthor Commented:
funny you should mention that, because those lines are already in rc.conf, and the firewall was working OK before something happened to it.

I think I'll just reboot
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now