Shorewall installazione e configurazione
lunedì, dicembre 8 2008 - 112 Visualizzazioni
Shorewall (Shoreline Firewall) è un firewall che si appoggia al sistema Netfilter (iptables/ipchains) del kernel Linux, per una più semplice gestione di avanzate
# apt-get remove --purge firestarter
# apt-get install shorewall shorewall-common shorewall-shell shorewall-doc dash
1) Partiamo con la configurazione del file interfaces:
# gedit /etc/shorewall/interfaces
all’interno copiamo questo:
# Shorewall version 3.0 - Sample Interfaces File for one-interface configuration. # # /etc/shorewall/interfaces # # You must add an entry in this file for each network interface on your # firewall system. # # Columns are: # # ZONE Zone for this interface. Must match the name of a # zone defined in /etc/shorewall/zones. You may not # list the firewall zone in this column. # # If the interface serves multiple zones that will be # defined in the /etc/shorewall/hosts file, you should # place "-" in this column. # # If there are multiple interfaces to the same zone, # you must list them in separate entries: # # Example: # # loc eth1 - # loc eth2 - # # INTERFACE Name of interface. Each interface may be listed only # once in this file. You may NOT specify the name of # an alias (e.g., eth0:0) here; see # http://www.shorewall.net/FAQ.htm#faq18 # # You may specify wildcards here. For example, if you # want to make an entry that applies to all PPP # interfaces, use ‘ppp+’. # # There is no need to define the loopback interface (lo) # in this file. # # BROADCAST The broadcast address for the subnetwork to which the # interface belongs. For P-T-P interfaces, this # column is left blank.If the interface has multiple # addresses on multiple subnets then list the broadcast # addresses as a comma-separated list. # # If you use the special value "detect", the firewall # will detect the broadcast address for you. If you # select this option, the interface must be up before # the firewall is started, you must have iproute # installed. # # If you don’t want to give a value for this column but # you want to enter a value in the OPTIONS column, enter # "-" in this column. # # OPTIONS A comma-separated list of options including the # following: # # dhcp - Specify this option when any of # the following are true: # 1. the interface gets its IP address # via DHCP # 2. the interface is used by # a DHCP server running on the firewall # 3. you have a static IP but are on a LAN # segment with lots of Laptop DHCP # clients. # 4. the interface is a bridge with # a DHCP server on one port and DHCP # clients on another port. # # norfc1918 - This interface should not receive # any packets whose source is in one # of the ranges reserved by RFC 1918 # (i.e., private or "non-routable" # addresses. If packet mangling or # connection-tracking match is enabled in # your kernel, packets whose destination # addresses are reserved by RFC 1918 are # also rejected. # # routefilter - turn on kernel route filtering for this # interface (anti-spoofing measure). This # option can also be enabled globally in # the /etc/shorewall/shorewall.conf file. # # logmartians - turn on kernel martian logging (logging # of packets with impossible source # addresses. It is suggested that if you # set routefilter on an interface that # you also set logmartians. This option # may also be enabled globally in the # /etc/shorewall/shorewall.conf file. # # blacklist - Check packets arriving on this interface # against the /etc/shorewall/blacklist # file. # # maclist - Connection requests from this interface # are compared against the contents of # /etc/shorewall/maclist. If this option # is specified, the interface must be # an ethernet NIC and must be up before # Shorewall is started. # # tcpflags - Packets arriving on this interface are # checked for certain illegal combinations # of TCP flags. Packets found to have # such a combination of flags are handled # according to the setting of # TCP_FLAGS_DISPOSITION after having been # logged according to the setting of # TCP_FLAGS_LOG_LEVEL. # # proxyarp - # Sets # /proc/sys/net/ipv4/conf/<interface>/proxy_arp. # Do NOT use this option if you are # employing Proxy ARP through entries in # /etc/shorewall/proxyarp. This option is # intended soley for use with Proxy ARP # sub-networking as described at: # http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet # # routeback - If specified, indicates that Shorewall # should include rules that allow # filtering traffic arriving on this # interface back out that same interface. # # arp_filter - If specified, this interface will only # respond to ARP who-has requests for IP # addresses configured on the interface. # If not specified, the interface can # respond to ARP who-has requests for # IP addresses on any of the firewall’s # interface. The interface must be up # when Shorewall is started. # # arp_ignore[=<number>] # - If specified, this interface will # respond to arp requests based on the # value of <number>. # # 1 - reply only if the target IP address # is local address configured on the # incoming interface # # 2 - reply only if the target IP address # is local address configured on the # incoming interface and both with the # sender’s IP address are part from same # subnet on this interface # # 3 - do not reply for local addresses # configured with scope host, only # resolutions for global and link # addresses are replied # # 4-7 - reserved # # 8 - do not reply for all local # addresses # # If no <number> is given then the value # 1 is assumed # # WARNING — DO NOT SPECIFY arp_ignore # FOR ANY INTERFACE INVOLVED IN PROXY ARP. # # nosmurfs - Filter packets for smurfs # (packets with a broadcast # address as the source). # # Smurfs will be optionally logged based # on the setting of SMURF_LOG_LEVEL in # shorewall.conf. After logging, the # packets are dropped. # # detectnets - Automatically taylors the zone named # in the ZONE column to include only those # hosts routed through the interface. # # upnp - Incoming requests from this interface # may be remapped via UPNP (upnpd). # # WARNING: DO NOT SET THE detectnets OPTION ON YOUR # INTERNET INTERFACE. # # The order in which you list the options is not # significant but the list should have no embedded white # space. # # Example 1: Suppose you have eth0 connected to a DSL modem and # eth1 connected to your local network and that your # local subnet is 192.168.1.0/24. The interface gets # it’s IP address via DHCP from subnet # 206.191.149.192/27. You have a DMZ with subnet # 192.168.2.0/24 using eth2. # # Your entries for this setup would look like: # # net eth0 206.191.149.223 dhcp # local eth1 192.168.1.255 # dmz eth2 192.168.2.255 # # Example 2: The same configuration without specifying broadcast # addresses is: # # net eth0 detect dhcp # loc eth1 detect # dmz eth2 detect # # Example 3: You have a simple dial-in system with no ethernet # connections. # # net ppp0 - # # For additional information, see # http://shorewall.net/Documentation.htm#Interfaces # ############################################################################### #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs #LAST LINE — ADD YOUR ENTRIES BEFORE THIS ONE — DO NOT REMOVE
Attenzione:Se al posto del router abbiamo un modem cambiare eth0 con ppp0. In ogni caso cercare di adattarlo alle nostre esigenze e configurazione.
2) Configurazione del file policy:
# gedit /etc/shorewall/policy
all’interno copiamo questo:
# Shorewall version 3.0 - Sample Policy File for one-interface configuration. # # /etc/shorewall/policy # # THE ORDER OF ENTRIES IN THIS FILE IS IMPORTANT # # This file determines what to do with a new connection request if we # don’t get a match from the /etc/shorewall/rules file . For each # source/destination pair, the file is processed in order until a # match is found ("all" will match any client or server). # # INTRA-ZONE POLICIES ARE PRE-DEFINED # # For $FW and for all of the zoned defined in /etc/shorewall/zones, # the POLICY for connections from the zone to itself is ACCEPT (with no # logging or TCP connection rate limiting but may be overridden by an # entry in this file. The overriding entry must be explicit (cannot use # "all" in the SOURCE or DEST). # # Columns are: # # SOURCE Source zone. Must be the name of a zone defined # in /etc/shorewall/zones, $FW or "all". # # DEST Destination zone. Must be the name of a zone defined # in /etc/shorewall/zones, $FW or "all" # # POLICY Policy if no match from the rules file is found. Must # be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE". # # ACCEPT - Accept the connection # DROP - Ignore the connection request # REJECT - For TCP, send RST. For all other, # send "port unreachable" ICMP. # QUEUE - Send the request to a user-space # application using the QUEUE target. # CONTINUE - Pass the connection request past # any other rules that it might also # match (where the source or # destination zone in those rules is # a superset of the SOURCE or DEST # in this policy). # NONE - Assume that there will never be any # packets from this SOURCE # to this DEST. Shorewall will not set # up any infrastructure to handle such # packets and you may not have any # rules with this SOURCE and DEST in # the /etc/shorewall/rules file. If # such a packet _is_ received, the # result is undefined. NONE may not be # used if the SOURCE or DEST columns # contain the firewall zone ($FW) or # "all". # # If this column contains ACCEPT, DROP or REJECT and a # corresponding common action is defined in # /etc/shorewall/actions (or # /usr/share/shorewall/actions.std) then that action # will be invoked before the policy named in this column # is enforced. # # LOG LEVEL If supplied, each connection handled under the default # POLICY is logged at that level. If not supplied, no # log message is generated. See syslog.conf(5) for a # description of log levels. # # Beginning with Shorewall version 1.3.12, you may # also specify ULOG (must be in upper case). This will # log to the ULOG target and sent to a separate log # through use of ulogd # (http://www.gnumonks.org/projects/ulogd). # # If you don’t want to log but need to specify the # following column, place "-" here. # # LIMIT:BURST If passed, specifies the maximum TCP connection rate # and the size of an acceptable burst. If not specified, # TCP connections are not limited. # # See http://shorewall.net/Documentation.htm#Policy for additional information. # ############################################################################### #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPT net all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE — ADD YOUR ENTRIES ABOVE THIS LINE — DO NOT REMOVE
3) Creazione del file di configurazione zones:
# gedit /etc/shorewall/zones
all’interno copiamo questo:
# Shorewall version 3.0 - Sample Zones File for one-interface configuration. # # /etc/shorewall/zones # # This file determines your network zones. # # Columns are: # # ZONE Short name of the zone (5 Characters or less in length). # The names "all" and "none" are reserved and may not be # used as zone names. # # Where a zone is nested in one or more other zones, # you may follow the (sub)zone name by ":" and a # comma-separated list of the parent zones. The parent # zones must have been defined in earlier records in this # file. # # Example: # # #ZONE TYPE OPTIONS # a ipv4 # b ipv4 # c:a,b ipv4 # # Currently, Shorewall uses this information only to reorder the # zone list so that parent zones appear after their subzones in # the list. In the future, Shorewall may make more extensive use # of that information. # # TYPE ipv4 - This is the standard Shorewall zone type and is the # default if you leave this column empty or if you enter # "-" in the column. Communication with some zone hosts # may be encrypted. Encrypted hosts are designated using # the ‘ipsec’option in /etc/shorewall/hosts. # ipsec - Communication with all zone hosts is encrypted # Your kernel and iptables must include policy # match support. # firewall # - Designates the firewall itself. You must have # exactly one ‘firewall’ zone. No options are # permitted with a ‘firewall’ zone. The name that you # enter in the ZONE column will be stored in the shell # variable $FW which you may use in other configuration # files to designate the firewall zone. # # OPTIONS, A comma-separated list of options as follows: # IN OPTIONS, # OUT OPTIONS reqid=<number> where <number> is specified # using setkey(8) using the ‘unique:<number> # option for the SPD level. # # spi=<number> where <number> is the SPI of # the SA used to encrypt/decrypt packets. # # proto=ah|esp|ipcomp # # mss=<number> (sets the MSS field in TCP packets) # # mode=transport|tunnel # # tunnel-src=<address>[/<mask>] (only # available with mode=tunnel) # # tunnel-dst=<address>[/<mask>] (only # available with mode=tunnel) # # strict Means that packets must match all rules. # # next Separates rules; can only be used with # strict.. # # Example: # mode=transport,reqid=44 # # The options in the OPTIONS column are applied to both incoming # and outgoing traffic. The IN OPTIONS are applied to incoming # traffic (in addition to OPTIONS) and the OUT OPTIONS are # applied to outgoing traffic. # # If you wish to leave a column empty but need to make an entry # in a following column, use "-". # # THE ORDER OF THE ENTRIES IN THIS FILE IS IMPORTANT IF YOU HAVE NESTED OR # OVERLAPPING ZONES DEFINED THROUGH /etc/shorewall/hosts. # # See http://www.shorewall.net/Documentation.htm#Nested ############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
4) Configurazione del file rules.
# gedit /etc/shorewall/rules
all’interno copiamo questo:
# Shorewall version 3.0 - Sample Rules File for one-interface configuration. # # /etc/shorewall/rules # # Rules in this file govern connection establishment. Requests and # responses are automatically allowed using connection tracking. For any # particular (source,dest) pair of zones, the rules are evaluated in the # order in which they appear in this file and the first match is the one # that determines the disposition of the request. # # In most places where an IP address or subnet is allowed, you # can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to # indicate that the rule matches all addresses except the address/subnet # given. Notice that no white space is permitted between "!" and the # address/subnet. #—————————————————————————— # WARNING: If you masquerade or use SNAT from a local system to the internet, # you cannot use an ACCEPT rule to allow traffic from the internet to # that system. You *must* use a DNAT rule instead. #—————————————————————————— # # The rules file is divided into sections. Each section is introduced by # a "Section Header" which is a line beginning with SECTION followed by the # section name. # # Sections are as follows and must appear in the order listed: # # ESTABLISHED Packets in the ESTABLISHED state are processed # by rules in this section. # # The only ACTIONs allowed in this section are # ACCEPT, DROP, REJECT, LOG and QUEUE # # There is an implicit ACCEPT rule inserted # at the end of this section. # # RELATED Packets in the RELATED state are processed by # rules in this section. # # The only ACTIONs allowed in this section are # ACCEPT, DROP, REJECT, LOG and QUEUE # # There is an implicit ACCEPT rule inserted # at the end of this section. # # NEW Packets in the NEW and INVALID states are # processed by rules in this section. # # WARNING: If you specify FASTACCEPT=Yes in shorewall.conf then the # ESTABLISHED and RELATED sections must be empty. # # Note: If you are not familiar with Netfilter to the point where you are # comfortable with the differences between the various connection # tracking states, then I suggest that you omit the ESTABLISHED and # RELATED sections and place all of your rules in the NEW section. # # You may omit any section that you don’t need. If no Section Headers appear # in the file then all rules are assumed to be in the NEW section. # # Columns are: # # ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE, # LOG, QUEUE or an <action>. # # ACCEPT — allow the connection request # ACCEPT+ — like ACCEPT but also excludes the # connection from any subsequent # DNAT[-] or REDIRECT[-] rules # NONAT — Excludes the connection from any # subsequent DNAT[-] or REDIRECT[-] # rules but doesn’t generate a rule # to accept the traffic. # DROP — ignore the request # REJECT — disallow the request and return an # icmp-unreachable or an RST packet. # DNAT — Forward the request to another # system (and optionally another # port). # DNAT- — Advanced users only. # Like DNAT but only generates the # DNAT iptables rule and not # the companion ACCEPT rule. # SAME — Similar to DNAT except that the # port may not be remapped and when # multiple server addresses are # listed, all requests from a given # remote system go to the same # server. # SAME- — Advanced users only. # Like SAME but only generates the # NAT iptables rule and not # the companion ACCEPT rule. # REDIRECT — Redirect the request to a local # port on the firewall. # REDIRECT- # — Advanced users only. # Like REDIRET but only generates the # REDIRECT iptables rule and not # the companion ACCEPT rule. # # CONTINUE — (For experts only). Do not process # any of the following rules for this # (source zone,destination zone). If # The source and/or destination IP # address falls into a zone defined # later in /etc/shorewall/zones, this # connection request will be passed # to the rules defined for that # (those) zone(s). # LOG — Simply log the packet and continue. # QUEUE — Queue the packet to a user-space # application such as ftwall # (http://p2pwall.sf.net). # <action> — The name of an action defined in # /etc/shorewall/actions or in # /usr/share/shorewall/actions.std. # <macro> — The name of a macro defined in a # file named macro.<macro-name>. If # the macro accepts an action # parameter (Look at the macro # source to see if it has PARAM in # the TARGET column) then the macro # name is followed by "/" and the # action (ACCEPT, DROP, REJECT, …) # to be substituted for the # parameter. Example: FTP/ACCEPT. # # The ACTION may optionally be followed # by ":" and a syslog log level (e.g, REJECT:info or # DNAT:debug). This causes the packet to be # logged at the specified level. # # If the ACTION names an action defined in # /etc/shorewall/actions or in # /usr/share/shorewall/actions.std then: # # - If the log level is followed by "!’ then all rules # in the action are logged at the log level. # # - If the log level is not followed by "!" then only # those rules in the action that do not specify # logging are logged at the specified level. # # - The special log level ‘none!’ suppresses logging # by the action. # # You may also specify ULOG (must be in upper case) as a # log level.This will log to the ULOG target for routing # to a separate log through use of ulogd # (http://www.gnumonks.org/projects/ulogd). # # Actions specifying logging may be followed by a # log tag (a string of alphanumeric characters) # are appended to the string generated by the # LOGPREFIX (in /etc/shorewall/shorewall.conf). # # Example: ACCEPT:info:ftp would include ‘ftp ‘ # at the end of the log prefix generated by the # LOGPREFIX setting. # # SOURCE Source hosts to which the rule applies. May be a zone # defined in /etc/shorewall/zones, $FW to indicate the # firewall itself, "all", "all+" or "none" If the ACTION # is DNAT or REDIRECT, sub-zones of the specified zone # may be excluded from the rule by following the zone # name with "!’ and a comma-separated list of sub-zone # names. # # When "none" is used either in the SOURCE or DEST # column, the rule is ignored. # # When "all" is used either in the SOURCE or DEST column # intra-zone traffic is not affected. When "all+" is # used, intra-zone traffic is affected. # # Except when "all[+]" is specified, clients may be # further restricted to a list of subnets and/or hosts by # appending ":" and a comma-separated list of subnets # and/or hosts. Hosts may be specified by IP or MAC # address; mac addresses must begin with "~" and must use # "-" as a separator. # # Hosts may be specified as an IP address range using the # syntax <low address>-<high address>. This requires that # your kernel and iptables contain iprange match support. # If you kernel and iptables have ipset match support # then you may give the name of an ipset prefaced by "+". # The ipset name may be optionally followed by a number # from 1 to 6 enclosed in square brackets ([]) to # indicate the number of levels of source bindings to be # matched. # # dmz:192.168.2.2 Host 192.168.2.2 in the DMZ # # net:155.186.235.0/24 Subnet 155.186.235.0/24 on the # Internet # # loc:192.168.1.1,192.168.1.2 # Hosts 192.168.1.1 and # 192.168.1.2 in the local zone. # loc:~00-A0-C9-15-39-78 Host in the local zone with # MAC address 00:A0:C9:15:39:78. # # net:192.0.2.11-192.0.2.17 # Hosts 192.0.2.11-192.0.2.17 in # the net zone. # # Alternatively, clients may be specified by interface # by appending ":" to the zone name followed by the # interface name. For example, loc:eth1 specifies a # client that communicates with the firewall system # through eth1. This may be optionally followed by # another colon (":") and an IP/MAC/subnet address # as described above (e.g., loc:eth1:192.168.1.5). # # DEST Location of Server. May be a zone defined in # /etc/shorewall/zones, $FW to indicate the firewall # itself, "all". "all+" or "none". # # When "none" is used either in the SOURCE or DEST # column, the rule is ignored. # # When "all" is used either in the SOURCE or DEST column # intra-zone traffic is not affected. When "all+" is # used, intra-zone traffic is affected. # # Except when "all[+]" is specified, the server may be # further restricted to a particular subnet, host or # interface by appending ":" and the subnet, host or # interface. See above. # # Restrictions: # # 1. MAC addresses are not allowed. # 2. In DNAT rules, only IP addresses are # allowed; no FQDNs or subnet addresses # are permitted. # 3. You may not specify both an interface and # an address. # # Like in the SOURCE column, you may specify a range of # up to 256 IP addresses using the syntax # <first ip>-<last ip>. When the ACTION is DNAT or DNAT-, # the connections will be assigned to addresses in the # range in a round-robin fashion. # # If you kernel and iptables have ipset match support # then you may give the name of an ipset prefaced by "+". # The ipset name may be optionally followed by a number # from 1 to 6 enclosed in square brackets ([]) to # indicate the number of levels of destination bindings # to be matched. Only one of the SOURCE and DEST columns # may specify an ipset name. # # The port that the server is listening on may be # included and separated from the server’s IP address by # ":". If omitted, the firewall will not modifiy the # destination port. A destination port may only be # included if the ACTION is DNAT or REDIRECT. # # Example: loc:192.168.1.3:3128 specifies a local # server at IP address 192.168.1.3 and listening on port # 3128. The port number MUST be specified as an integer # and not as a name from /etc/services. # # if the ACTION is REDIRECT, this column needs only to # contain the port number on the firewall that the # request should be redirected to. # # PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p", # "ipp2p:udp", "ipp2p:all" a number, or "all". # "ipp2p*" requires ipp2p match support in your kernel # and iptables. # # DEST PORT(S) Destination Ports. A comma-separated list of Port # names (from /etc/services), port numbers or port # ranges; if the protocol is "icmp", this column is # interpreted as the destination icmp-type(s). # # If the protocol is ipp2p, this column is interpreted # as an ipp2p option without the leading "–" (example # "bit" for bit-torrent). If no port is given, "ipp2p" is # assumed. # # A port range is expressed as <low port>:<high port>. # # This column is ignored if PROTOCOL = all but must be # entered if any of the following ields are supplied. # In that case, it is suggested that this field contain # "-" # # If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the CLIENT PORT(S) list below: # 1. There are 15 or less ports listed. # 2. No port ranges are included. # Otherwise, a separate rule will be generated for each # port. # # CLIENT PORT(S) (Optional) Port(s) used by the client. If omitted, # any source port is acceptable. Specified as a comma- # separated list of port names, port numbers or port # ranges. # # If you don’t want to restrict client ports but need to # specify an ORIGINAL DEST in the next column, then # place "-" in this column. # # If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the DEST PORT(S) list above: # 1. There are 15 or less ports listed. # 2. No port ranges are included. # Otherwise, a separate rule will be generated for each # port. # # ORIGINAL DEST (0ptional) — If ACTION is DNAT[-] or REDIRECT[-] # then if included and different from the IP # address given in the SERVER column, this is an address # on some interface on the firewall and connections to # that address will be forwarded to the IP and port # specified in the DEST column. # # A comma-separated list of addresses may also be used. # This is usually most useful with the REDIRECT target # where you want to redirect traffic destined for # particular set of hosts. # # Finally, if the list of addresses begins with "!" then # the rule will be followed only if the original # destination address in the connection request does not # match any of the addresses listed. # # For other actions, this column may be included and may # contain one or more addresses (host or network) # separated by commas. Address ranges are not allowed. # When this column is supplied, rules are generated # that require that the original destination address # matches one of the listed addresses. This feature is # most useful when you want to generate a filter rule # that corresponds to a DNAT- or REDIRECT- rule. In this # usage, the list of addresses should not begin with "!". # # See http://shorewall.net/PortKnocking.html for an # example of using an entry in this column with a # user-defined action rule. # # RATE LIMIT You may rate-limit the rule by placing a value in # this colume: # # <rate>/<interval>[:<burst>] # # where <rate> is the number of connections per # <interval> ("sec" or "min") and <burst> is the # largest burst permitted. If no <burst> is given, # a value of 5 is assumed. There may be no # no whitespace embedded in the specification. # # Example: 10/sec:20 # # USER/GROUP This column may only be non-empty if the SOURCE is # the firewall itself. # # The column may contain: # # [!][<user name or number>][:<group name or number>][+<program name>] # # When this column is non-empty, the rule applies only # if the program generating the output is running under # the effective <user> and/or <group> specified (or is # NOT running under that id if "!" is given). # # Examples: # # joe #program must be run by joe # :kids #program must be run by a member of # #the ‘kids’ group # !:kids #program must not be run by a member # #of the ‘kids’ group # +upnpd #program named upnpd (This feature was # #removed from Netfilter in kernel # #version 2.6.14). # # Example: Accept SMTP requests from the DMZ to the internet # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # ACCEPT dmz net tcp smtp # # Example: Forward all ssh and http connection requests from the # internet to local system 192.168.1.3 # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # DNAT net loc:192.168.1.3 tcp ssh,http # # Example: Forward all http connection requests from the internet # to local system 192.168.1.3 with a limit of 3 per second and # a maximum burst of 10 # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # # PORT PORT(S) DEST LIMIT # DNAT net loc:192.168.1.3 tcp http - - 3/sec:10 # # Example: Redirect all locally-originating www connection requests to # port 3128 on the firewall (Squid running on the firewall # system) except when the destination address is 192.168.2.2 # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # REDIRECT loc 3128 tcp www - !192.168.2.2 # # Example: All http requests from the internet to address # 130.252.100.69 are to be forwarded to 192.168.1.3 # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 # # Example: You want to accept SSH connections to your firewall only # from internet IP addresses 130.252.100.69 and 130.252.100.70 # # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # ACCEPT net:130.252.100.69,130.252.100.70 $FW \ # tcp 22 ################################################################ #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP
# Reject Ping from the "bad" net zone.. and prevent your log from being flooded..
Ping/REJECT net $FW
# Permit all ICMP traffic FROM the firewall TO the net zone
ACCEPT $FW net icmp
#LAST LINE — ADD YOUR ENTRIES BEFORE THIS ONE — DO NOT REMOVE
In questo file vengono settate le regole di accesso, quindi è qui che a secondo delle esigenze di ognuno di noi vanno aperte le porte per i programmi che noi utilizziamo. Facendo degli esempi con Amule, Deluge, Ftp, prima dell’ultima riga:
#LAST LINE — ADD YOUR ENTRIES BEFORE THIS ONE — DO NOT REMOVE
vanno inserite le regole:
# aMule ACCEPT net $FW tcp 4662 ACCEPT $FW net tcp 4662 ACCEPT net $FW udp 4672 ACCEPT $FW net udp 4672 ACCEPT net $FW udp 4665 ACCEPT $FW net udp 4665
# Ftp modo passivo ACCEPT net $FW tcp 21 ACCEPT $FW net tcp 21 ACCEPT net $FW tcp 50000:50100 ACCEPT $FW net tcp 50000:50100
#deluge ACCEPT net $FW tcp 6881:6889 ACCEPT $FW net tcp 6881:6889
5) Per attivare shorewall all’avvio:
# gedit /etc/default/shorewall
e rimpiazzare "startup=0" con "startup=1"
6) Lanciare shorewall:
# shorewall start
7) Dopo aver fatto qualche modifica:
# shorewall restart
Per moltissime altre info, soprattutto più esaurienti e complete direttamente qua.
Taggato come Applicazioni, Sicurezza, firewall, gnu linux, rete, shorewall, utility
Scritto da edmond
Altri Articoli Interessanti
Gli ultimi dal Social
gabrielbutoeru
Gabriel recupera la password e capisce qualche cosa in più su Chrome OS
@Replica
mcastel
qualche riflessione sul sistema operativo di #Google http://tinyurl.com/laquuc (Qaiku)
@Replica
andreaolivato
Gnome-do 0.8.2 con le Docklets su Gentoo : VIDEO http://bit.ly/UcC8g
@Replica
andreaolivato
Stallman: il software libero non deve dipendere da #Mono http://punto-informatico.it/2657922/PI/News/stallman-liberatevi-mono.aspx
@Replica
trampfox
ha appena finito il post su Linux Feed :) http://trampfox.wordpress.com/2009/06/22/linux-feed/
@Replica
Sito webCompletamente Funzionante
GalleryCompletamente Funzionante
Social NetworkCompletamente Funzionante
Server JabberProblemi liste contatti
Servizio MailCompletamente Funzionante
Servizio di RicercaCompletamente Funzionante















