IPF and Tomcat on Solaris 9

[cod3fr3ak]

I have a Solaris 9 server running IPF version 3.4.35, and Tomcat version 5.x.

I need to place this server in the DMZ in place of an ailing Apache/mod_jk/Tomcat server.

Tomcat runs on port 8080 and 8443, in order to facilitate webadmins shutting down and restarting the server.

here is a copy of my ipnat.conf:

# ipnat.conf - 080905

# Redirect port 80 to 8080
rdr eri0 x.x.x.137/32 port 80 -> x.x.x.137 port 8080 tcp

# Redirect port 443 to 8443
rdr eri0 x.x.x.137/32 port 443 -> x.x.x.137 port 8443 tcp

Here is the ipf.conf:

# ipf.conf - 080905

# Deny all incoming
block in all

# inbound traffic - http, https
pass in quick on eri0 proto tcp from any to x.x.x.137 port = 8080 flags S keep state
pass in quick on eri0 proto tcp from any to x.x.x.137 port = 8443 flags S keep state

# Allow all outgoing
pass out quick on eri0 from any to any keep state

Is this correct? This works but it leaves the proxy ports open. I'd prefer that cleints not
have direct access to 8080, only 80.

After working with PF for so long, working with IPF is really a pain, not mention
I have been unable to compile the lastest source, in order to upgrade.

[frisco]

In pf you would be looking to do something like this:

rdr eri0 x.x.x.137/32 port 80 -> 127.0.0.1 port 8080 tcp
and:
pass in quick on eri0 proto tcp from any to x.x.x.137 port = 80 flags S keep

does that work in ipf?

[Strog]

Redirecting on the host itself makes it trickier. You could also redirect 8443 and 8080 to a closed port to prevent access but that's kinda hackish. Block the port you redirect to and the normal ports should (I spend all my time with pf so take with a grain of salt) continue to work fine since filtering is done after the translation of a NAT/rdr.

Have you looked at actually running Tomcat on port 80? http://www.klawitter.de/tomcat80.html

[cod3fr3ak]

hey thanks frisco. I think I'll try that. since the 127 traffic won't show up in Nessus scans - which is the reason i ran into this issue in the first place. I think i might have tried it before and ipnat.conf didn't like the 127 entry but i'll try again since its been a while.

Strog, I looked into creating my own Tomcat startup script when I was trying to chroot it (never finished working on that), and I thought it was a real pain. I can't run it on port 80 due to security issues within my organization. Currently my prod server is running like this, and i have sudo setup to allow the webadmins to stop it and start it. But I have until April to get a non-root/non-port 80 solution in place. :-(

[cod3fr3ak]

heres what I got:

root@rudy># ipfboot reload
Set 1 now inactive
filter sync'd
0 entries flushed from NAT table
2 entries flushed from NAT list
localhost as destination not supported
7: syntax error in "rdr"
/etc/opt/ipf/ipnat.conf: parse error (-1), quitting
/root/scripts/ipfboot: load of /etc/opt/ipf/ipnat.conf failed

when I made this change:
rdr eri0 x.x.x.137/32 port 80 -> 127.0.0.1 port 8080 tcp

Doing a little googling, I found that Solaris 8 and 9 have some kind of mojo in the IP stack that prevents the above rdr line from working.
http://marc2.theaimsgroup.com/?l=ipf...9814104996&w=4

I am still doing more research.

[cod3fr3ak]

I upgraded to the lastest ipfilter - 4.1.10, and now ipnat.conf will accepts 127.0.0.1; but there is another problem.

the redirect works according to this:

List of active MAP/Redirect filters:
rdr eri0 x.x.x.137/32 port 80 -> 127.0.0.1 port 8080 tcp

List of active sessions:
RDR 127.0.0.1 8080 <- -> x.x.x.137 80 [x.x.x.28 1897]
RDR 127.0.0.1 8080 <- -> x.x.x.137 80 [x.x.x.28 1896]

and I can use tcpdump to watch packets go back and forth.

the Web page banner show up at the top of the window but the page never shows up. Its like it just gets stuck. Strange. As soon as I switch it back to the original config the webpage displays just like normal.

I think i might just have to do a vulnerability writeup and let the big-wigs deal with it.

[frisco]

Doublecheck you aren't blocking lo0 anywhere. If it still doesn't work, i'll see if i can try this on one of my test machines.

[cod3fr3ak]

hmmm blocking lo0... So I guess I need to explicitly tell it to allow that stuff in. I thought if the packet made it through the rdr it would be considered internal. Okay. Let me check that.