You are here

OK instalova slackware

trip's picture

OK instalova slackware meqe degjova kaq shume qe flasin mire per kete distro...paska nje tool tip apt-get te debian,por me duket ca me i varfer.bera nje swaret --update dhe upgrade dhe perteriva paketat.por ne momentin qe doja te "perterij"(upgrade nuk di si mund te jte ne shqip)firefox me thote se nuk njeh nje pakete me kete emer :-? nderkohe qe ne ubuntu me apt-get pothuajse gjeje gjithshka...megjithate si paraqitje pare nuk duket keq... ;-) te shohim.pershendetje te gjitheve

Forume: 
laurenti's picture

Për të konfiguruar Shorewall nuk ka nevojë të lexosh të gjithë manualët.Duket i vështirë në vështrimin e parë por, në fakt, është tepër i thjeshtë.Ok, t'a konfigurojmë së bashku:Fillo duke kontrolluar /etc/network/interfaces:Normalisht duhet të kesh tre zëra:# This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).# The loopback network interfaceauto lo eth0 eth1iface lo inet loopbackiface eth0 inet dhcpiface eth1 inet static address 192.168.0.1 netmask 255.255.255.0 network 192.168.0.1        broadcast 192.168.0.255

Ku eth0 -> modem adsl dhe eth1 -> XP

Kontrollo që skedat të ngarkohen si duhet (kur jep komandën ifconfig duhet të rezultojnë interfaqet lo, eth0, eth1, ppp0)Nëse gjithçka në rregull, vazhdo me instalimin e Shorewall :

  • Shkarko shorewall-3.0.5
  • hap pakon dhe kryej instalimin:tar xvfj shorewall-3.0.5.tar.bz2cd shorewall-3.0.5./install
  • Konfiguroje:Futu tek directory e krijuar nga shorewall (zakonisht /etc/shorewall)cd /etc/shorewallcd Samples/two-interfaces/mv * ../../cd ../../lsKonfiguro zonat (/etc/shorewall/zones)## Shorewall version 3.0 - Sample Zones File for two-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 "-".## For more information, see http://www.shorewall.net/Documentation.htm#Zones#################################################################################ZONE TYPE OPTIONS IN OUT# OPTIONS OPTIONSfw firewallnet ipv4loc ipv4#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    Sikurse mund të shohësh nga tre rreshtat e fundit, gjithçka është e qartë :-)

    Në bazë të zonave të mësipërme, mund të përcaktosh rregullat në lidhje me çfarë do të lejosh apo të ndalosh (/etc/shorewall/policy):## Shorewall version 3.0 - Sample Policy File for two-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:BURSTloc net ACCEPT# If you want open access to the Internet from your Firewall# remove the comment from the following line.$FW net ACCEPTnet all DROP info# THE FOLLOWING POLICY MUST BE LASTall all REJECT info#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

    Mund të shtosh rregulla të tjera apo të ndryshosh ekzistueset (loc, fw, net)

    Rregullat mund të përcaktohen edhe tek /etc/shorewall/rules:## Shorewall version 3.0 - Sample Rules File for two-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# PORT PORT(S) DEST LIMIT GROUP## Accept DNS connections from the firewall to the network#DNS/ACCEPT $FW net## Accept SSH connections from the local network for administration#SSH/ACCEPT loc $FW## Allow Ping from the local network#Ping/ACCEPT loc $FW## Reject Ping from the "bad" net zone.. and prevent your log from being flooded..#Ping/REJECT net $FWACCEPT $FW loc icmpACCEPT $FW net icmp##LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

    P.sh. unë tek file im i konfigurimit kam shtuar:

    # Lejo Freeposd#ACCEPT loc $FW tcp 2000##Lejo ISP#ACCEPT          loc             $FW              tcp     81ACCEPT          net             $FW              tcp     81#AllowWeb net fwAllowWeb loc fwAllowMySQL net fwAllowMySQL loc fwDNAT            net             loc:192.168.0.15:2500 tcp     2500*

    e çfarë tjetër të duash

    Më së fundi hap dhe konfiguro file qendror të konfigurimit /etc/shorewall/shorewall.conf:################################################################################  /etc/shorewall/shorewall.conf V3.0 - Change the following variables to#  match your setup##  This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]##  This file should be placed in /etc/shorewall##  (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)##      >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<<##  Most problems associated with upgrades come from two causes:##   - The user didn't read and follow the migration considerations in the#     release notes.##   - The user mis-handled the /etc/shorewall/shorewall.conf file during#     upgrade. Shorewall is designed to allow the default behavior of#     the product to evolve over time. To make this possible, the design#     assumes that you will not replace your current shorewall.conf file#     during upgrades. If you feel absolutely compelled to have the latest#     comments and options in your shorewall.conf then you must proceed#     carefully.##     The new/changed options in shorewall 3.0 are listed below. If you don't#     want to convert to the new 3.0 format for /etc/shorewall/zones and you#     don't want to replace your current rules that use 2.x builtin actions,#     then if you plan to use this copy of shorewall.conf file then you must#     change it as follows:##     - SPECFILE## This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec.# This will indicate that your /etc/shorewall/zones file is in the# pre-3.0 format.##     - FW## This file has FW undefined. If you have named your firewall zone# something other than 'fw' then you must set FW accordingly.##     - MAPOLDACTIONS## This file has MAPOLDACTIONS=No. You want to set it to#       MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin#       actions such as AllowPing to continue to work.################################################################################        S T A R T U P   E N A B L E D################################################################################# Once you have configured Shorewall, you may change the setting of# this variable to 'Yes'#STARTUP_ENABLED=No################################################################################        L O G G I N G################################################################################# General note about log levels. Log levels are a method of describing# to syslog (8) the importance of a message and a number of parameters# in this file have log levels as their value.## These levels are defined by syslog and are used to determine the destination# of the messages through entries in /etc/syslog.conf (5). The syslog# documentation refers to these as "priorities"; Netfilter calls them "levels"# and Shorewall also uses that term.## Valid levels are:## 7 debug# 6 info# 5 notice# 4 warning# 3 err# 2 crit# 1 alert# 0 emerg## For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall# log messages are generated by NetFilter and are logged using facility# 'kern' and the level that you specifify. If you are unsure of the level# to choose, 6 (info) is a safe bet. You may specify levels by name or by# number.## If you have built your kernel with ULOG target support, you may also# specify a log level of ULOG (must be all caps). Rather than log its# messages to syslogd, Shorewall will direct netfilter to log the messages# via the ULOG target which will send them to a process called 'ulogd'.# ulogd is available with most Linux distributions (although it probably isn't# installed by default). Ulogd is also available from# http://www.gnumonks.org/projects/ulogd and can be configured to log all# Shorewall message to their own log file################################################################################# LOG FILE LOCATION## This variable tells the /sbin/shorewall program where to look for Shorewall# log messages. If not set or set to an empty string (e.g., LOGFILE="") then# /var/log/messages is assumed.## WARNING: The LOGFILE variable simply tells the 'shorewall' program where to#    look for Shorewall messages.It does NOT control the destination for#    these messages. For information about how to do that, see##        http://www.shorewall.net/shorewall_logging.html#LOGFILE=/var/log/messages## LOG FORMAT## Shell 'printf' Formatting template for the --log-prefix value in log messages# generated by Shorewall to identify Shorewall log messages. The supplied# template is expected to accept either two or three arguments; the first is# the chain name, the second (optional) is the logging rule number within that# chain and the third is the ACTION specifying the disposition of the packet# being logged. You must use the %d formatting type for the rule number; if# your template does not contain %d then the rule number will not be included.## If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:## LOGFORMAT="fp=%s:%d a=%s "## If not specified or specified as empty (LOGFORMAT="") then the value# "Shorewall:%s:%s:" is assumed.## CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up# to but not including the first '%') to find log messages in the 'show log',# 'status' and 'hits' commands. This part should not be omitted (the# LOGFORMAT should not begin with "%") and the leading part should be# sufficiently unique for /sbin/shorewall to identify Shorewall messages.#LOGFORMAT="Shorewall:%s:%s:"## LOG FORMAT Continued## Using the default LOGFORMAT, chain names may not exceed 11 characters or# truncation of the log prefix may occur. Longer chain names may be used with# log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is# specified then the tag is included in the log prefix in place of the chain# name.#LOGTAGONLY=No## LOG RATE LIMITING## The next two variables can be used to control the amount of log output# generated. LOGRATE is expressed as a number followed by an optional# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum# rate at which a particular message will occur. LOGBURST determines the# maximum initial burst size that will be logged. If set empty, the default# value of 5 will be used.## If BOTH variables are set empty then logging will not be rate-limited.## Example:## LOGRATE=10/minute# LOGBURST=5## For each logging rule, the first time the rule is reached, the packet# will be logged; in fact, since the burst is 5, the first five packets# will be logged. After this, it will be 6 seconds (1 minute divided by# the rate of 10) before a message will be logged from the rule, regardless# of how many packets reach it. Also, every 6 seconds which passes without# matching a packet, one of the bursts will be regained; if no packets hit# the rule for 30 seconds, the burst will be fully recharged; back where# we started.#LOGRATE=LOGBURST=## LOG ALL NEW## This option should only be used when you are trying to analyze a problem.# It causes all packets in the Netfilter NEW state to be logged as the# first rule in each builtin chain. To use this option, set LOGALLNEW to# the log level that you want these packets logged at (e.g.,# LOGALLNEW=debug).#LOGALLNEW=## BLACKLIST LOG LEVEL## Set this variable to the syslogd level that you want blacklist packets logged# (beware of DOS attacks resulting from such logging). If not set, no logging# of blacklist packets occurs.## See the comment at the top of this section for a description of log levels#BLACKLIST_LOGLEVEL=## MAC List Log Level## Specifies the logging level for connection requests that fail MAC# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then# such connection requests will not be logged.## See the comment at the top of this section for a description of log levels#MACLIST_LOG_LEVEL=info## TCP FLAGS Log Level## Specifies the logging level for packets that fail TCP Flags# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then# such packets will not be logged.## See the comment at the top of this section for a description of log levels#TCP_FLAGS_LOG_LEVEL=info## RFC1918 Log Level## Specifies the logging level for packets that fail RFC 1918# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then# RFC1918_LOG_LEVEL=info is assumed.## See the comment at the top of this section for a description of log levels#RFC1918_LOG_LEVEL=info## SMURF Log Level## Specifies the logging level for smurf packets dropped by the#'nosmurfs' interface option in /etc/shorewall/interfaces and in# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""# ) then dropped smurfs are not logged.## See the comment at the top of this section for a description of log levels#SMURF_LOG_LEVEL=info## MARTIAN LOGGING## Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets# that have impossible source IP addresses. This logging may be enabled# on individual interfaces by using the 'logmartians' option in# /etc/shorewall/interfaces.#LOG_MARTIANS=No################################################################################ L O C A T I O N   O F F I L E S   A N D   D I R E C T O R I E S################################################################################# IPTABLES## Full path to iptables executable Shorewall uses to build the firewall. If# not specified or if specified with an empty value (e.g., IPTABLES="") then# the iptables executable located via the PATH setting below is used.#IPTABLES=## PATH - Change this if you want to change the order in which Shorewall# searches directories for executable files.#PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin## SHELL## The firewall script is normally interpreted by /bin/sh. If you wish to change# the shell used to interpret that script, specify the shell here.#SHOREWALL_SHELL=/bin/sh# SUBSYSTEM LOCK FILE## Set this to the name of the lock file expected by your init scripts. For# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't# use lock files, set this to "".#SUBSYSLOCK=/var/lock/subsys/shorewall## KERNEL MODULE DIRECTORY## If your netfilter kernel modules are in a directory other than# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that# directory in this variable. Example: MODULESDIR=/etc/modules.#MODULESDIR=## CONFIGURATION SEARCH PATH## This option holds a list of directory names separated by colons# (":"). Shorewall will search each directory in turn when looking for a# configuration file. When processing a 'try' command or a command# containing the "-c" option or that specifies a configuration directory,# Shorewall will automatically add the directory specified in the command# to the front of this list.## If not specified or specified as null ("CONFIG_PATH=""),# CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed.#CONFIG_PATH=/etc/shorewall:/usr/share/shorewall## RESTORE SCRIPT## This option determines the script to be run in the following cases:## shorewall -f start# shorewall restore# shorewall save# shorewall forget# Failure of shorewall start or shorewall restart## The value of the option must be the name of an executable file in the# directory /var/lib/shorewall. If this option is not set or if it is# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is# assumed.#RESTOREFILE=## OLD ZONE FILE FORMAT## Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.# Beginning with 2.5.0, those files were combined. For users who haven't# converted, we offer this variable that sets the name of the file for ipsec# information. This option must take the value "zones" or "ipsec". If the# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"# is assumed.#IPSECFILE=zones################################################################################ F I R E W A L L   O P T I O N S################################################################################ NAME OF THE FIREWALL ZONE## Name of the firewall zone -- if not set or if set to an empty string, then# you must include a definition of the firewall zone in /etc/shorewall/zones.## Note: If IPSECFILE=zones above then you must NOT set FW and you must define#       the firewall zone in /etc/shorewall/zones.FW=## ENABLE IP FORWARDING## If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you# say "Off" or "off", packet forwarding will be disabled. You would only want# to disable packet forwarding if you are installing Shorewall on a# standalone system or if you want all traffic through the Shorewall system# to be handled by proxies.## If you set this variable to "Keep" or "keep", Shorewall will neither# enable nor disable packet forwarding.#IP_FORWARDING=On## AUTOMATICALLY ADD NAT IP ADDRESSES## If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses# for each NAT external address that you give in /etc/shorewall/nat. If you say# "No" or "no", you must add these aliases youself.## WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added# during processing of the "shorewall restart" command. As a consequence,# connections using those addresses may be severed.#ADD_IP_ALIASES=Yes## AUTOMATICALLY ADD SNAT IP ADDRESSES## If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses# for each SNAT external address that you give in /etc/shorewall/masq. If you# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"# unless you are sure that you need it -- most people don't!!!## WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added# during processing of the "shorewall restart" command. As a consequence,# connections using those addresses may be severed.#ADD_SNAT_ALIASES=No## RETAIN EXISTING ALIASES/IP ADDRESSES## Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall# will first delete the address then re-add it. This is to ensure that the# address is added with the specified label. Unfortunately, this can cause# problems if it results in the deletion of the last IP address on an# interface because then all routes through the interface are automatically# removed.## You can cause Shorewall to retain existing addresses by setting# RETAIN_ALIASES=Yes.#RETAIN_ALIASES=No## ENABLE TRAFFIC SHAPING## If you say "Yes" or "yes" here, Shorewall will use a script that you# supply to configure traffic shaping. The script must be named 'tcstart'# and must be placed in a directory on your CONFIG_PATH.## If you say "No" or "no" then traffic shaping is not enabled.## If you set TC_ENABLED=Internal or internal or leave the option empty then# Shorewall will use its builtin traffic shaper (tc4shorewall written by# Arne Bernin).## See http://shorewall.net/traffic_shaping.htm for more information.TC_ENABLED=Internal## Clear Traffic Shapping/Control## If this option is set to 'No' then Shorewall won't clear the current# traffic control rules during [re]start. This setting is intended# for use by people that prefer to configure traffic shaping when# the network interfaces come up rather than when the firewall# is started. If that is what you want to do, set TC_ENABLED=No and# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That# way, your traffic shaping rules can still use the 'fwmark'# classifier based on packet marking defined in /etc/shorewall/tcrules.## If omitted, CLEAR_TC=Yes is assumed.#CLEAR_TC=Yes## Mark Packets in the forward chain## When processing the tcrules file, Shorewall normally marks packets in the# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set# this to "Yes". If not specified or if set to the empty value (e.g.,# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.## Marking packets in the FORWARD chain has the advantage that inbound# packets destined for Masqueraded/SNATed local hosts have had their# destination address rewritten so they can be marked based on their# destination. When packets are marked in the PREROUTING chain, packets# destined for Masqueraded/SNATed local hosts still have a destination address# corresponding to the firewall's external interface.## Note: Older kernels do not support marking packets in the FORWARD chain and# setting this variable to Yes may cause startup problems.#MARK_IN_FORWARD_CHAIN=No## MSS CLAMPING## Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"# option. This option is most commonly required when your internet# interface is some variant of PPP (PPTP or PPPoE). Your kernel must# have CONFIG_IP_NF_TARGET_TCPMSS set.## [From the kernel help:##    This option adds a `TCPMSS' target, which allows you to alter the#    MSS value of TCP SYN packets, to control the maximum size for that#    connection (usually limiting it to your outgoing interface's MTU#    minus 40).##    This is used to overcome criminally braindead ISPs or servers which#    block ICMP Fragmentation Needed packets.  The symptoms of this#    problem are that everything works fine from your Linux#    firewall/router, but machines behind it can never exchange large#    packets:# 1) Web browsers connect, then hang with no data received.# 2) Small mail works fine, but large emails hang.# 3) ssh works fine, but scp hangs after initial handshaking.# ]## If left blank, or set to "No" or "no", the option is not enabled.## You may also set this option to a numeric value in which case Shorewall will# set up a rule to modify the MSS value in SYN packets to the value that# you specify.## Example:## CLAMPMSS=1400#CLAMPMSS=No## ROUTE FILTERING## Set this variable to "Yes" or "yes" if you want kernel route filtering on all# interfaces started while Shorewall is started (anti-spoofing measure).## If this variable is not set or is set to the empty value, "No" is assumed.# Regardless of the setting of ROUTE_FILTER, you can still enable route# filtering on individual interfaces using the 'routefilter' option in the# /etc/shorewall/interfaces file.#ROUTE_FILTER=No## DNAT IP ADDRESS DETECTION## Normally when Shorewall encounters the following rule:## DNAT net loc:192.168.1.3 tcp 80## it will forward TCP port 80 connections from the net to 192.168.1.3# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is# convenient for two reasons:## a) If the the network interface has a dynamic IP address, the#    firewall configuration will work even when the address#    changes.## b) It saves having to configure the IP address in the rule#    while still allowing the firewall to be started before the#    internet interface is brought up.## This default behavior can also have a negative effect. If the# internet interface has more than one IP address then the above# rule will forward connection requests on all of these addresses;# that may not be what is desired.## By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply# only if the original destination address is the primary IP address of# one of the interfaces associated with the source zone. Note that this# requires all interfaces to the source zone to be up when the firewall# is [re]started.#DETECT_DNAT_IPADDRS=No## MUTEX TIMEOUT## The value of this variable determines the number of seconds that programs# will wait for exclusive access to the Shorewall lock file. After the number# of seconds corresponding to the value of this variable, programs will assume# that the last program to hold the lock died without releasing the lock.## If not set or set to the empty value, a value of 60 (60 seconds) is assumed.## An appropriate value for this parameter would be twice the length of time# that it takes your firewall system to process a "shorewall restart" command.#MUTEX_TIMEOUT=60## FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT## Normally, when a "shorewall stop" command is issued or an error occurs during# the execution of another shorewall command, Shorewall puts the firewall into# a state where only traffic to/from the hosts listed in# /etc/shorewall/routestopped is accepted.## When performing remote administration on a Shorewall firewall, it is# therefore recommended that the IP address of the computer being used for# administration be added to the firewall's /etc/shorewall/routestopped file.## Some administrators have a hard time remembering to do this with the result# that they get to drive across town in the middle of the night to restart# a remote firewall (or worse, they have to get someone out of bed to drive# across town to restart a very remote firewall).## For those administrators, we offer ADMINISABSENTMINDED=Yes. With this# setting, when the firewall enters the 'stopped' state:## All traffic that is part of or related to established connections is still# allowed and all OUTPUT traffic is allowed. This is in addition to traffic# to and from hosts listed in /etc/shorewall/routestopped.## If this variable is not set or it is set to the null value then# ADMINISABSENTMINDED=No is assumed.#ADMINISABSENTMINDED=Yes## BLACKLIST Behavior## Shorewall offers two types of blacklisting:## - static blacklisting through the /etc/shorewall/blacklist file#   together with the 'blacklist' interface option.# - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.## The following variable determines whether the blacklist is checked for each# packet or for each new connection.## BLACKLISTNEWONLY=Yes Only consult blacklists for new connection# requests## BLACKLISTNEWONLY=No Consult blacklists for all packets.## If the BLACKLISTNEWONLY option is not set or is set to the empty value then# BLACKLISTNEWONLY=No is assumed.#BLACKLISTNEWONLY=Yes## Users with a large blacklist find that "shorwall [re]start" takes a long# time and that new connections are disabled during that time. By setting# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections# before loading the blacklist.#DELAYBLACKLISTLOAD=No# MODULE NAME SUFFIX## When loading a module named in /etc/shorewall/modules, Shorewall normally# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a# different naming convention then you can specify the suffix (extension) for# module names in this variable.## To see what suffix is used by your distribution:##     ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter## All of the file names listed should have the same suffix (extension). Set# MODULE_SUFFIX to that suffix.## Examples:## If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"# If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"#MODULE_SUFFIX=## DISABLE IPV6## Distributions (notably SuSE) are beginning to ship with IPV6# enabled. If you are not using IPV6, you are at risk of being# exploited by users who do. Setting DISABLE_IPV6=Yes will cause# Shorewall to disable IPV6 traffic to/from and through your# firewall system. This requires that you have ip6tables installed.DISABLE_IPV6=Yes## BRIDGING## If you wish to restrict connections through a bridge# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have# the physdev match option enabled; that option is available at the above URL# for 2.4 kernels and is included as a standard part of the 2.6 series# kernels. If not specified or specified as empty (BRIDGING="") then "No" is# assumed.#BRIDGING=No## DYNAMIC ZONES## If you need to be able to add and delete hosts from zones dynamically then# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.DYNAMIC_ZONES=No## USE PKTTYPE MATCH## Some users have reported problems with the PKTTYPE match extension not being# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall# will use IP addresses to detect broadcasts rather than pkttype. If not given# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.#PKTTYPE=Yes## RFC 1918 BEHAVIOR## Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'# processing to cease for a packet if the packet's source IP address matches# the rule. Thus, if you have:## SUBNETS TARGET# 192.168.1.0/24 RETURN## then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you# also have:## SUBNETS TARGET# 10.0.0.0/8 logdrop## Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped# since while the packet's source matches the RETURN rule, the packet's# destination matches the 'logdrop' rule.## If not specified or specified as empty (e.g., RFC1918_STRICT="") then# RFC1918_STRICT=No is assumed.## WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support#    'conntrack state' match.#RFC1918_STRICT=No## MAC List Table## Normally, MAC verification occurs in the filter table (INPUT and FORWARD)# chains. When forwarding a packet from an interface with MAC verification# to a bridge interface, that doesn't work.## This problem can be worked around by setting MACLIST_TABLE=mangle which# will cause Mac verification to occur out of the PREROUTING chain. Because# REJECT isn't available in that environment, you may not specify# MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle.MACLIST_TABLE=filter## MACLIST caching## If your iptables and kernel support the "Recent Match" (see the output of# "shorewall check" near the top), you can cache the results of a 'maclist'# file lookup and thus reduce the overhead associated with MAC Verification# (/etc/shorewall/maclist).## When a new connection arrives from a 'maclist' interface, the packet passes# through the list of entries for that interface in /etc/shorewall/maclist. If# there is a match then the source IP address is added to the 'Recent' set for# that interface. Subsequent connection attempts from that IP address occuring# within $MACLIST_TTL seconds will be accepted without having to scan all of# the entries. After $MACLIST_TTL from the first accepted connection request,# the next connection request from that IP address will be checked against# the entire list.## If MACLIST_TTL is not specified or is specified as empty (e.g,# MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not# be cached.#MACLIST_TTL=## Save/Restore IPSETS## If SAVE_IPSETS=Yes then Shorewall will:## Restore the last saved ipset contents during "shorewall [re]start"# Save the current ipset contents during "shorewall save"## Regardless of the setting of SAVE_IPSETS, if ipset contents were# saved during a "shorewall save" then they will be restored during# a subsequent "shorewall restore".#SAVE_IPSETS=No## Map Old Actions## Previously, Shorewall included a large number of standard actions (AllowPing,# AllowFTP, ...). These have been replaced with parameterized macros. For# compatibility, Shorewall can map the old names into invocations of the new# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed#MAPOLDACTIONS=No## Fast ESTABLISHED/RELATED handling## Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets# reach the chain in which the original connection was accepted. So for packets# going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are# ACCEPTED in the 'loc2net' chain.## If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are accepted# early in the INPUT, FORWARD and OUTPUT chains.  If you set# FASTACCEPT=Yes then you may not include rules in the ESTABLISHED and# RELATED sections of the rules file.FASTACCEPT=No################################################################################ P A C K E T   D I S P O S I T I O N################################################################################# BLACKLIST DISPOSITION## Set this variable to the action that you want to perform on packets from# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,# DROP is assumed.#BLACKLIST_DISPOSITION=DROP## MAC List Disposition## This variable determines the disposition of connection requests arriving# on interfaces that have the 'maclist' option and that are from a device# that is not listed for that interface in /etc/shorewall/maclist. Valid# values are ACCEPT, DROP and REJECT. If not specified or specified as# empty (MACLIST_DISPOSITION="") then REJECT is assumed#MACLIST_DISPOSITION=REJECT## TCP FLAGS Disposition## This variable determins the disposition of packets having an invalid# combination of TCP flags that are received on interfaces having the# 'tcpflags' option specified in /etc/shorewall/interfaces or in# /etc/shorewall/hosts. If not specified or specified as empty# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.#TCP_FLAGS_DISPOSITION=DROP#LAST LINE -- DO NOT REMOVE

    Këtu ki kujdes të përcaktosh CLAMPMSS=yesROUTE_FILTER=Yes e në fundSTARTUP_ENABLED=Yes

Rinis shorewall (ose rinis pc): normalisht gjithçka duhet të funksionojë pa probleme;Fillo të ndryshosh apo shtosh rregulla të personalizara në firewall.

trip's picture

PershendetjeMe duken shume gjera arabisht ;) p.sh,c'fare jane fw dhe loc dhe net,c'fare do te thote kur vendos $ para fw?Ose,zonat,cfare jane dhe si percaktohen ip-te e zonave,pra si i them shorewall qe une kam komputerin tim si getaway dhe nje komputer tjeter ne cross me ip 192.168.0.2.dhe si arri ti them qe dua qe komputeri ne cross te kete access ne internet por jo ne komputerin tim...Megjithate falemnderit per interesimin.Me pelqen idea qe te shkruaj me dore ne nje file se cilet jane protokollet qe dua te lejoj dhe cilet jo vetem se, sic ju thashe,ky file me duket pak arabisht.:)Megjithate nuk kam hequr dore,po perdor gusrddog me teer per te krijuar nje ide...Rrespekte

trip's picture

Megjithese edhe kete guarddog nuk po merrkam vesh si funksionon...Po instaloj shorewall dhe te shohim si do me shkojne punet...;)

laurenti's picture

Në fakt janë anglisht: çdo hap shpjegohet në menyrë tepër të qartë, por në anglisht (nk mund të përkthehet gjithçka në shqip).Pyetjet që bën kanë përgjigje të thjeshtë: imagjino sikur krejt interneti të ketë emrin net, imagjino kompjuterin që kryen rolin e firewall dhe gateway të ketë emrin fw dhe krejt rrjeti i brendshëm (pra në rastin tënd XP) të quhet loc; këto konsiderohen zona.Duke ditur që zonat janë tre: net (interneti), fw (kompjuteri që kryen mbrojtjen + funksionet e tjera), loc (rrjeti i brendshëm, i përbërë nga 1 apo më shumë pc), është thjeshtë përcaktimi i rregullave (apo policy e rules). Në këtë menyrë mund të përcaktojmë se kush nga net mund të hyjë në rrjetin tonë, dhe ku mund të hyjë, e kush nga loc mund të dalë jashtë e ku mund të shkojë.Përsa i takon $FW është thjesht një e ndryshueshme: n.q.s. unë deklaroj që FW = fw, atëhere $FW do të thotë fw, n.q.s. them që FW = trip, atëhere $FW lexohet trip.

trip's picture

pershendetje ma kishte marre mendja qe net eshte internet dhe fw eshte komputeri im dhe loc eshte rrjeti local...pra me pake llafe firewall eshte komputeri me slackware dhe ipv4 jane internet dhe rrjeti brendeshem.por cilieshte kuptimi i ketij ipv4 (ip forward?)domethene ne qofte se dua qe te perdor dns per local duhet te them dns/accept net loc?po si mund ti them se ksuh eshte ip i zones loc?shuem puetje po ju bej...pershendetje

trip's picture

pervec se file /etc/network/interfaces nuk eksiston fare me ndodhi dhe kjo gjeja tjeter:konfigurova shorewall me net=internet loc=lan dhe fw=firewall(komputeri im normalisht)i thashe shorewall te jete startuppasi i jap shorewall start me dalin keto gjera...Loading /usr/share/shorewall/functions...Processing /etc/shorewall/params ...Processing /etc/shorewall/shorewall.conf...Loading Modules...Starting Shorewall...Initializing...Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Extended Multi-port Match: Not available Connection Tracking Match: Available Packet Type Match: Available Policy Match: Not available Physdev Match: Not available IP range Match: Not available Recent Match: Available Owner Match: Available Ipset Match: Not available CONNMARK Target: Not available Connmark Match: Not available Raw Table: Not available CLASSIFY Target: Not availableDetermining Zones... IPv4 Zones: net loc Firewall Zone: fwValidating interfaces file... ERROR: No Interfaces DefinedTerminated???cili eshte difekti

trip's picture

PO pse me duhet te karikoj modulin e pppoe?normalisht duhet te jete i karikuar pasi pppoe-setup funksionon(me hope por funksionon)Megjithate do filloj te provoj...P.S:ne nje post te alblinux (siti i vjeter) patet shkrojtur nje script mbi pppoe dhe iptables.Ky skript ishte per tu perdorur mbi kanotix,e perdora per slackware dhe me thote se ip_tables no such file or folder...!

trip's picture

Mirembrema kjo direktory nuk ekziston fare ne komputerin tim...ekziston nje file /etc/networks qe ka brenda keto gjera:## networks This file describes a number of netname-to-address# mappings for the TCP/IP subsystem. It is mostly# used at boot time, when no name servers are running.#loopback 127.0.0.0localnet 127.0.0.0# End of networks.Duhet ta krijoj une kete file?

laurenti's picture

Në fakt, nën slackware, file korrispondues i /etc/network/intefaces është /etc/rc.d/rc.inet1.conf.Konfigurimi është i ngjashëm (automatikisht kryhet me anë të komandës netconfig).Prandaj dhe shorewall nuk arrin të niset.

trip's picture

PershendetjeKonfigurova shorewall dhe pas shumemundimesh arriti te startoje pa error.Vetem se,kur starton,nuk arri me te lundroj!Une ne file plicy kam shtuar ne fund keto rreshta#loc net ACCEPTloc fw DROP#lejo lidhejen e loc me internetnet all DROP#mos lejo lidhjen e internetit me mua(dhe ketu besoj se duhet te shtoj dicka)fw net ACCEPTlejo firewall me internetfw loc ACCEPTlejo firewall me loc(ketu e shtova sepse pa te shorewall nuk nusej)#LAST LINE -- DO NOT REMOVETani,kam pershtypjen se duhet et shtoj ndonje rregull tip,protokolli qe me duhet per te lundruar apo jo?Per shembull DNS tcp/ip,bittorrent,eDonkey,gnutella...si mund te shtohen keto protokolle dhe a eshte ky problemi perse nuk arri te lundroj kur startoj shorewall?falemderit dhe respekte

Faqet