Unleashed v1.4
[unleashed.git] / share / man / man5 / ipfilter.5
blob7478a2701e406b7cf300b6fca68e3d14f8a6ed1d
1 '\" te
2 .\" To view license terms, attribution, and copyright for IP Filter, the default path is /usr/lib/ipf/IPFILTER.LICENCE. If the Solaris operating environment has been installed anywhere other than the default, modify the given path to access the file at the installed
3 .\" location.
4 .\" Portions Copyright (c) 2009, Sun Microsystems Inc. All Rights Reserved.
5 .\" Portions Copyright (c) 2014, Joyent, Inc. All Rights Reserved.
6 .TH IPFILTER 5 "Oct 7, 2014"
7 .SH NAME
8 ipfilter \- IP packet filtering software
9 .SH DESCRIPTION
10 .LP
11 IP Filter is software that provides packet filtering capabilities on a Solaris
12 system. On a properly setup system, it can be used to build a firewall.
13 .sp
14 .LP
15 Solaris IP Filter is installed with the Solaris operating system. However,
16 packet filtering is not enabled by default. See \fBipf\fR(8) for a procedure
17 to enable and activate the IP Filter feature.
18 .SH HOST-BASED FIREWALL
19 .LP
20 To simplify IP Filter configuration management, a firewall framework is created
21 to allow users to configure IP Filter by expressing firewall policy at system
22 and service level. Given the user-defined firewall policy, the framework
23 generates a set of IP Filter rules to enforce the desired system behavior.
24 Users specify system and service firewall policies that allow or deny network
25 traffic from certain hosts, subnets, and interface(s). The policies are
26 translated into a set of active IPF rules to enforce the specified firewall
27 policies.
28 .LP
29 Note -
30 .sp
31 .RS 2
32 Users can still specify their own ipf rule file if they choose not to take
33 advantage of the framework. See \fBipf\fR(8) and \fBipf\fR(4).
34 .RE
35 .SS "Model"
36 .LP
37 This section describes the host-based firewall framework. See svc.ipfd(8) for
38 details on how to configure firewall policies.
39 .sp
40 .LP
41 In a given zone, a three-layer approach with different precedence levels helps
42 the user achieve the desired behaviors.
43 .sp
44 .ne 2
45 .na
46 \fBGlobal Default\fR
47 .ad
48 .sp .6
49 .RS 4n
50 Global Default - Default system-wide firewall policy. This policy is
51 automatically inherited by all services unless services modify their firewall
52 policy.
53 .RE
55 .sp
56 .ne 2
57 .na
58 \fBNetwork Services\fR
59 .ad
60 .sp .6
61 .RS 4n
62 Higher precedence than Global Default. A service's policy allows/disallows
63 traffic to its specific ports, regardless of Global Default policy.
64 .RE
66 .sp
67 .ne 2
68 .na
69 \fBGlobal Override\fR
70 .ad
71 .sp .6
72 .RS 4n
73 Another system-wide policy that takes precedence over the needs of specific
74 services in Network Services layer.
75 .RE
77 .sp
78 .in +2
79 .nf
80 Global Override
81       |
82       |
83 Network Services
84       |
85       |
86 Global Default
87 .fi
88 .in -2
89 .sp
91 .sp
92 .LP
93 A firewall policy includes a firewall mode and an optional set of network
94 sources. Network sources are IP addresses, subnets, and local network
95 interfaces, from all of which a system can receive incoming traffic. The basic
96 set of firewall modes are:
97 .sp
98 .ne 2
99 .na
100 \fBNone\fR
102 .sp .6
103 .RS 4n
104 No firewall, allow all incoming traffic.
108 .ne 2
110 \fBDeny\fR
112 .sp .6
113 .RS 4n
114 Allow all incoming traffic but deny from specified source(s).
118 .ne 2
120 \fBAllow\fR
122 .sp .6
123 .RS 4n
124 Deny all incoming traffic but allow from specified source(s).
127 .SS "Layers in Detail"
129 The first system-wide layer, Global Default, defines a firewall policy that
130 applies to \fBany\fR incoming traffic, for example, allowing or blocking all
131 traffic from an IP address. This makes it simple to have a policy that blocks
132 all incoming traffic or all incoming traffic from unwanted source(s).
135 The Network Services layer contains firewall policies for local programs that
136 provide service to remote clients, for example, \fBtelnetd\fR, \fBsshd\fR, and
137 \fBhttpd\fR. Each of these programs, a network service, has its own firewall
138 policy that controls access to its service. Initially, a service's policy is
139 set to inherit Global Default policy, a "Use Global Default" mode. This makes
140 it simple to set a single policy, at the Global Default layer, that can be
141 inherited by all services.
144 When a service's policy is different from Global Default policy, the service's
145 policy has higher precedence. If Global Default policy is set to block all
146 traffic from a subnet, the SSH service could be configured to allow access from
147 certain hosts in that subnet. The set of all policies for all network services
148 comprises the Network Service layer.
151 The second system-wide layer, Global Override, has a firewall policy that also
152 applies to any incoming network traffic. This policy has highest precedence and
153 overrides policies in the other layers, specifically overriding the needs of
154 network services. The example is when it is desirable to block known malicious
155 source(s) regardless of services' policies.
156 .SS "User Interaction"
158 This framework leverages IP Filter functionality and is active only when
159 \fBsvc:/network/ipfilter\fR is enabled and inactive when \fBnetwork/ipfilter\fR
160 is disabled. Similarly, a network service's firewall policy is only active when
161 that service is enabled and inactive when the service is disabled. A system
162 with an active firewall has IP Filter rules for each running/enabled network
163 service and system-wide policy(s) whose firewall mode is not \fBNone\fR.
166 A user configures a firewall by setting the system-wide policies and policy for
167 each network service. See svc.ipfd(8) on how to configure a firewall policy.
170 The firewall framework composes of policy configuration and a mechanism to
171 generate IP Filter rules from the policy and applying those rules to get the
172 desired IP Filter configuration. A quick summary of the design and user
173 interaction:
174 .RS +4
176 .ie t \(bu
177 .el o
178 system-wide policy(s) are stored in \fBnetwork/ipfilter\fR
180 .RS +4
182 .ie t \(bu
183 .el o
184 network services' policies are stored in each SMF service
186 .RS +4
188 .ie t \(bu
189 .el o
190 a user activates a firewall by enabling \fBnetwork/ipfilter\fR (see
191 \fBipf\fR(8))
193 .RS +4
195 .ie t \(bu
196 .el o
197 a user activates/deactivate a service's firewall by enabling/disabling that
198 network service
200 .RS +4
202 .ie t \(bu
203 .el o
204 changes to system-wide or per-service firewall policy results in an update to
205 the system's firewall rules
207 .SS "In-Zone and Global Zone Controlled firewalls"
209 Each non-global zone in the system can potentially have two firewalls
210 configured: the in-zone firewall and the Global Zone controlled (GZ-controlled)
211 firewall. The in-zone firewall can be controlled and observed inside the zone
212 using the framework detailed above, or from the Global Zone. The GZ-controlled
213 firewall can only be controlled and observed from the Global Zone. The
214 GZ-controlled firewall is always "outermost" with respect to the zone.
217 For inbound traffic (from an external source to the zone), the traffic flow looks
218 like the following diagram. Traffic blocked by the GZ-controlled firewall will
219 not be processed by the in-zone firewall.
221 .in +2
223   External Source
224         |
225         |
226 GZ-controlled Firewall
227         |
228         |
229   In-Zone Firewall
230         |
231         |
232       Zone
234 .in -2
237 For outbound traffic (from the zone to an external destination), the traffic
238 flow looks like the following diagram. Traffic blocked by the in-zone firewall
239 will not be processed by the GZ-controlled firewall.
241 .in +2
243       Zone
244         |
245         |
246   In-Zone Firewall
247         |
248         |
249 GZ-controlled Firewall
250         |
251         |
252  External Destination
254 .in -2
257 Either of the in-Zone or GZ-controlled firewalls can be enabled, or both at the
258 same time.
261 The Global Zone does not have a GZ-controlled firewall, only an
262 in-zone firewall.  For inbound traffic (from an external source to the global
263 zone), the traffic flow therefore looks like the following diagram.
265 .in +2
267   External Source
268         |
269         |
270   In-Zone Firewall
271         |
272         |
273       Zone
275 .in -2
278 For outbound traffic (from the global zone to an external destination), the
279 traffic flow looks like the following diagram.
281 .in +2
283       Zone
284         |
285         |
286   In-Zone Firewall
287         |
288         |
289  External Destination
291 .in -2
293 .SH ATTRIBUTES
295 See \fBattributes\fR(5) for a description of the following attributes:
300 box;
301 c | c
302 l | l .
303 ATTRIBUTE TYPE  ATTRIBUTE VALUE
305 Interface Stability     Committed
308 .SH SEE ALSO
310 \fBsvcs\fR(1), \fBipf\fR(8), \fBipnat\fR(8), \fBsvcadm\fR(8),
311 \fBsvc.ipfd\fR(8), \fBipf\fR(4), \fBipnat\fR(4), \fBattributes\fR(5),
312 \fBsmf\fR(5)
315 \fISystem Administration Guide: IP Services\fR
316 .SH NOTES
318 The \fBipfilter\fR service is managed by the service management facility,
319 \fBsmf\fR(5), under the service identifier:
321 .in +2
323 svc:/network/ipfilter:default
325 .in -2
330 Administrative actions on this service, such as enabling, disabling, or
331 requesting restart, can be performed using \fBsvcadm\fR(8). The service's
332 status can be queried using the \fBsvcs\fR(1) command.
335 IP Filter startup configuration files are stored in \fB/etc/ipf\fR.