I'm having some trouble setting up SunScreen as a host-based
firewall and have had a lot of frustration trying to get help
through Sun's support.
I've been using the Sun BluePrint, "Securing Systems with Host-
Based Firewalls - Implemeneted With SunScreen Lite 3.1 Software,"
http://www.sun.com/blueprints/0901/sunscreenlite.pdf
I am actually using full-blown SunScreen 3.2 on Solaris 9. But
I figured the BluePrint would be close enough. I don't know if
Lite versus full-calorie version issues is the problem.
I have a very simple ruleset,
1 "*" "harbor-gocc" "*" ALLOW LOG SUMMARY COMMENT "open GOCC interface out"
2 "*" "*" "harbor-gocc" ALLOW LOG SUMMARY COMMENT "open GOCC interface in"
3 "backup-out" "harbor-backup" "backup-net" ALLOW LOG SUMMARY COMMENT "out to
backup clients"
4 "netbackup-in" "backup-net" "harbor-backup" ALLOW LOG SUMMARY COMMENT "in
from backup clients"
5 "*" "*" "*" DENY LOG SUMMARY COMMENT "log drops"
What is going on here is that we have a multihomed host,
a backup server. We want to restrict access to the host on
the interface connected to the backup network. Right now,
I'm just trying to understand how SunScreen works; the
interface on the backup network isn't even connected.
The "harbor-gocc" object is just an "ADDRESS" for the host's
interface on the internal network, 172.19.217.141/27. Now, the
naive child that I am expects firewall, security software
to only do exactly what its told. It shouldn't make
Microsoft-style assumptions about what the administrator
really means. Afterall, this is secuity software, we fail
on the side of security rather than ease-of-use, right?
But then I started to see this in the logs,
2 hme0 (pass) 14.95339 172.19.217.136 -> 172.19.217.191 UDP
D=9002 S=9002 LEN=287
3 hme0 (pass) 14.95499 172.19.217.136 -> 172.19.217.191 UDP
D=9002 S=9002 LEN=287
4 hme0 (pass) 14.96346 172.19.217.136 -> 172.19.217.191 UDP
D=9002 S=9002 LEN=343
5 hme0 (pass) 14.96406 172.19.217.136 -> 172.19.217.191 UDP
D=9002 S=9002 LEN=342
6 hme0 (pass) 14.96450 172.19.217.136 -> 172.19.217.191 UDP
D=9002 S=9002 LEN=287
That is, traffic to the broadcast address of the internal
network is being passed! I never said anything about passing
traffic to broadcast addresses. Where is this getting passed?
First I learned that SunScreen has no ability to associate
a pass or deny with rules in the ruleset. That's quite a
misfeature, IMHO. Next, after weeks and a dozen or two emails
to Sun support, they pointed to the following information
about the internal rule compilation (ssadm lib/screeninfo),
/*RULE "*-Broadcast" "* - Other" "Broadcast Routing" ALLOW LOG SUMMARY
COMMENT "open GOCC interface in"*/
/* Output:0 */
/* Source: 0.0.0.0 - 172.19.217.140 172.19.217.142 - 255.255.255.255 */
/* Destination: 172.19.217.191 172.19.217.128 0.0.0.0 255.255.255.255 224.0.0.0
- 239.255.255.255 */
if (match(IP_dstaddr, addr_7)) {
if (match(IP_srcaddr, addr_6)) {
pmap_nis_fwd(svc_20, 8, 1, Filter_20, Policy_2, 0x0)
pmap_udp_fwd(svc_21, 8, 1, Filter_21, Policy_2, 0x0)
udp_datagram_fwd(svc_22, 7, 1, Filter_22, Policy_2, 0x0)
icmp_fwd(svc_23, 7, 1, Filter_23, Policy_2, 0x0)
ipmobile_fwd(svc_24, 10, 1, Filter_24, Policy_2, 0x0)
}
}
So what it looks like is happening is that when I specify "*"
as a service, it includes what SunScreen considered "BROADCAST"
services. And when you include a rule with a broadcast service,
SunScreen automagically allows traffic to the broadcast
addresses! Not just the address or addresses you've specified in
the rule.
Now I think that would be a pretty cool feature _iff_ there are
BIG RED FLASHING WARNINGS telling you about it AND there exist
a knob or knobs to turn this behavior off. I have been unable
to get this information yet, waiting for the days to weeks
turnaround from Sun support. Anyone know of workarounds besides
just avoiding "BROADCAST" services? I'm also trying to figure
out which service would allow port 9002/udp broadcasts. I think
it has something to do with "udp_datagram_fwd," but I'm not
sure how to correlate that to a SunScreen service.
I should also mention that I would like to do all administration
of this firewall from the CLI. Any advice on how to "correctly"
kill off the Apache server and other stuff that supports the
GUI?
(BTW, there is also more "behind-the-scenes" handling of RIP, DNS,
and CDP, but I got some hints from the support correspondence on
how to actually turn that off.)
--
Crist J. Clark | cjclark@alum.mit.edu
