| View previous topic :: View next topic |
| Author |
Message |
rota
l33t
Joined: 13 Aug 2003
Posts: 960
|
 Posted: Wed Mar 16, 2005 11:54 pm Post subject: |
 |
|
bella pero ricordiamoci unacosa .. che qualsiasi sia il firewall dobbiamo vedere qaunta memoria a di defoult la cache ( creddo che si chiami cosi .. ) perche probabilmente la lentezza di iptables dipende da questo ..cioe che a finito la cache a suadisposizzione..
o io creddo di vere detto una cosa sensata.. pero da profano posso sbagliare .che nessuno me ne voglia |
|
| Back to top |
|
 |
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Thu Mar 17, 2005 7:25 am Post subject: |
|
|
la cache di cosa?
Non mi pare proprio che iptables abbia dei requisiti esosi di sistema.
Un 486 gia' fa il suo dovere senza problemi 
che intendi?
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
arnor
Tux's lil' helper
Joined: 01 Nov 2004
Posts: 147
|
| Posted: Thu Mar 17, 2005 9:21 am Post subject: |
|
|
per ora ho fatto il portatile, questo pomeriggio spero di riuscire a mettere le mani sul server.
la macchina server ha 2 interfacce di rete eth0 e eth1
eth0 -> WAN
eth1 -> LAN
su eth0 tutto chiuso tranne openvpn,ftp, https
su eth1 che apre sulla rete LAN interna abilitare una navigazione full verso l'esterno e l'accesso a diversi servizi:
- samba
- ssh
- cvsd
- http
non credo che ci metterò 5' ma l'obbiettivo è questo 
ciao lorenzo |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Thu Mar 17, 2005 9:30 am Post subject: |
|
|
per openvpn usa il file /etc/shorewall tunnel
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
arnor
Tux's lil' helper
Joined: 01 Nov 2004
Posts: 147
|
| Posted: Thu Mar 17, 2005 3:36 pm Post subject: |
|
|
sul portatile ho configurato e funziona egregiamente.
C'è solo una cosa che non capisco. Nel file /etc/shorewall/rules ho inserito queste righe:
####################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT net all tcp 22,80
ACCEPT net all icmp
ho fatto un nmap e mi risulta che c'è aperta la porta 143. perchè? è un default?
cmq se ho detto chiudi tutto non dovebbe farlo?
cmq grazie. Ora provo sul server
ciao lorenzo |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Thu Mar 17, 2005 3:39 pm Post subject: |
|
|
premesso che quelle regole andrebbero modificate...
net all e' sempre da evitare!
meglio
net fw .....
dovrei vedere la config per valutare...
se fai un tar.gz e me lo mandi ti posso aiutare.
oppure posta i soliti 3-4 file
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
arnor
Tux's lil' helper
Joined: 01 Nov 2004
Posts: 147
|
| Posted: Thu Mar 17, 2005 5:33 pm Post subject: |
|
|
sono molto soddisfatto, dopo 1 ora ho gia la macchina configurata e funzionante. Mi manca capire alcuni dettagli.
questo il mio scan con nmap:
| Code: | PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
113/tcp closed auth
443/tcp closed https |
tutto giusto tranne la porta 113 che io non ho aperto... almeno non volontariamente.
i miei file di configurazione che ho toccato:
/etc/shorewall/zones
| Code: | #ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
|
/etc/shorewall/interfaces
| Code: | #ZONE INTERFACE BROADCAST OPTIONS
net eth0 192.168.2.255
loc eth1 192.168.3.255 |
/etc/shorewall/policy
| Code: | #SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
loc net ACCEPT
net all DROP info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT info
#LAST LINE -- DO NOT REMOVE |
/etc/shorewall/rules
| Code: | ####################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT net fw tcp 21,443,22
ACCEPT net fw icmp
ACCEPT fw net
ACCEPT loc net
ACCEPT loc fw |
/etc/shorewall/masq
| Code: |
###############################################################################
#INTERFACE SUBNET ADDRESS PROTO PORT(S)
eth0 eth1
|
/etc/shorewall/shorewall.conf
| Code: |
##############################################################################
# /etc/shorewall/shorewall.conf V2.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 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# 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.
#
# 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 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/shorewall/shorewall.log
#
# 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 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=10/minute
LOGBURST=5
#
# 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=
#
# LOGGING 'New not SYN' rejects
#
# This variable only has an effect when NEWNOTSYN=No (see below).
#
# When a TCP packet that does not have the SYN flag set and the ACK and RST
# flags clear then unless the packet is part of an established connection,
# it will be rejected by the firewall. If you want these rejects logged,
# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.
#
# See the comment at the top of this section for a description of log levels
#
# Example: LOGNEWNOTSYN=debug
LOGNEWNOTSYN=info
#
# 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
#
# BOGON Log Level
#
# Specifies the logging level for bogon packets dropped by the
#'nobogons' interface option in /etc/shorewall/interfaces and in
# /etc/shorewall/hosts. If set to the empty value
# ( BOGON_LOG_LEVEL="" ) then packets whose TARGET is 'logdrop'
# in /usr/share/shorewall/bogons are logged at the 'info' level.
#
# See the comment at the top of this section for a description of log levels
#
BOGON_LOG_LEVEL=info
################################################################################
# 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
################################################################################
#
# 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
#
# SHOREWALL TEMPORARY STATE DIRECTORY
#
# This is the directory where the firewall maintains state information while
# it is running
#
STATEDIR=/var/lib/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, 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=
################################################################################
# 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, "fw"
# is assumed.
#
FW=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.
#
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!!!
#
ADD_SNAT_ALIASES=No
#
# ENABLE TRAFFIC SHAPING
#
# If you say "Yes" or "yes" here, Traffic Shaping is enabled in the firewall. If
# you say "No" or "no" then traffic shaping is not enabled. If you enable traffic
# shaping you must have iproute[2] installed (the "ip" and "tc" utilities).
TC_ENABLED=No
#
# 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=Yes 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.
#
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
#
# NEWNOTSYN
#
# TCP connections are established using the familiar three-way "handshake":
#
# CLIENT SERVER
#
# SYN-------------------->
# <------------------SYN,ACK
# ACK-------------------->
#
# The first packet in that exchange (packet with the SYN flag on and the ACK
# and RST flags off) is referred to in Netfilter terminology as a "syn" packet.
# A packet is said to be NEW if it is not part of or related to an already
# established connection.
#
# The NETNOTSYN option determines the handling of non-SYN packets (those with
# SYN off or with ACK or RST on) that are not associated with an already
# established connection.
#
# If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not
# part of an already established connection will be dropped by the
# firewall. The setting of LOGNEWNOTSYN above determines if these packets are
# logged before they are dropped.
#
# If NEWNOTSYN is set to "Yes" or "yes" then such packets will not be
# dropped but will pass through the normal rule/policy processing.
#
# Users with a High-availability setup with two firewall's and one acting
# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may
# also need to select NEWNOTSYN=Yes.
#
# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis
# using the 'newnotsyn' option in /etc/shorewall/interfaces and on a
# network or host basis using the same option in /etc/shorewall/hosts.
#
# I find that NEWNOTSYN=No tends to result in lots of "stuck"
# connections because any network timeout during TCP session tear down
# results in retries being dropped (Netfilter has removed the
# connection from the conntrack table but the end-points haven't
# completed shutting down the connection). I therefore have chosen
# NEWNOTSYN=Yes as the default value.
NEWNOTSYN=Yes
#
# 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
# 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 control traffic 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 patch certain broadcast packets.
#
# Other users have complained of the following message when
# starting Shorewall:
#
# modprobe: cant locate module ipt_pkttype
#
# If you set PKTTYPE=No then Shorewallwill 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
################################################################################
# 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 |
Un altra nota per la tua guida. Se aggiungi due righe sul perchè inserisci la zona fw è una buona cosa. Sul portatile infatti non ho messo fw ma solo loc intendendolo come localhost. quando poi ho configurato il server leggendo il shorewall.conf ho capito cosa intendeva e l'ho aggiunto.
Ho seguito il consiglio di evitare all 2 loc mettendo come mediazione fw.
il proplema della porta 113 aperta lo tengo sia sul server che sul portatile. I file di configurazione sono in relazione del server.
ultima quest poi scrivo il tuo nome sulle finestre, rimuovo iptables da "rc-update" e metto shorewall oppure vanno lasciati entrambi?
grazie 1000 per la guida e per il supporto
ciao lorenzo
Edit gutter: usiamo i bbcode |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Thu Mar 17, 2005 6:10 pm Post subject: |
|
|
alura..
la prossima volta il codice mettilo tra tag [code] [ / code]
che non si capisce una mazza
la porta 113 non e' aperta!
e' solo che nel file common.def e' specificato di fare un reject... quindi la macchina che scanna da correttamente closed!
ho notato un errore in rules:
se metti:
zona1 zona2 ACCEPT
mettilo in policy che ha + senso
riguardo il discorso fw non ho capito cosa intendi
puoi fare in 2 modi per lo startup script.
o lasci solo shorewall
o lasci iptables con la configuarazione salvata dopo aver lanciato shorewall (+ veloce)
io preferisco lasciare shorewall di default perche' a ogni riavvio mi legge la config aggiornata.
_________________
while True:Gentoo() |
|
| Back to top |
|
|
rota
l33t
Joined: 13 Aug 2003
Posts: 960
|
| Posted: Thu Mar 17, 2005 8:00 pm Post subject: |
|
|
o solo detto la mia .....
pero potrebbe vedere quanta memoria occupano i servizzi aperti no ????
sempre da profano... |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Thu Mar 17, 2005 9:35 pm Post subject: |
|
|
rota...
non ti ho mica aggredito
diciamo che quanta memoria portano via i servizi e' qualche cosa che esula dal argomento firewall.
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
rota
l33t
Joined: 13 Aug 2003
Posts: 960
|
| Posted: Thu Mar 17, 2005 11:12 pm Post subject: |
|
|
ok... soc stato un po permaloso ... non me nevolere ... |
|
| Back to top |
|
|
AlterX
l33t
Joined: 03 Apr 2004
Posts: 754
Location: rm -rf /*
|
| Posted: Fri Mar 18, 2005 11:12 am Post subject: |
|
|
uhm...se vuoi un mio parere, lascia perdere iptables come modulo nel kernel
o quasiasi altra forma di automatismo.
Anche perchè cavolo ci sono trentamila regole!!
Io uso iptables separatamente, mi creo il mio scriptino e lo avvio
come servizio. Risultato: 10/15 regole e ora (su mandrake) una scheggia!!
Trasparenza assoluta e nessuna lentezza!
Scarico a banca larga e massimale nonostante il filtraggio/natting
Ora sto ultimando la stessa configurazione con una gentoo (molto più performante perchè da stage1 e prelinkata  )
e la sto per mettere in produzione...
se vuoi ti faccio sapere come va con la gentoo, ma se va come una spada una mandrake, figurati una gentoo!!! |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Fri Mar 18, 2005 11:24 am Post subject: |
|
|
non sono molto d'accordo.
primo: con 15 regole la vedo dura ignorare IP rfc1918
secondo: se lanci shorewall - salvi il tutto con iptables-save che differenza abbiamo in fase di start? 10 ms? ... no troppo
terzo: firewall con 3,4,5,6 zone: 15 regole non bastano di sicuro (a meno che non usi 3 policy di default di DROP  )
(e con shorewall ti assicuro che scrivi molto,molto meno)
Parlare di regole pesanti o meno mi sembra proprio assurdo.
Un 486 che lavori come firewall a 3 zone (e non offra servizi pesanti come VPN) e sempre adeguato.
Il che la dice lunga sulla pesantezza
Se cerchiamo di snellire la macchina... cerchiamo altrove.. che e' meglio!
del tutto IMHO
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
AlterX
l33t
Joined: 03 Apr 2004
Posts: 754
Location: rm -rf /*
|
| Posted: Fri Mar 18, 2005 11:41 am Post subject: |
|
|
| xchris wrote: | non sono molto d'accordo.
primo: con 15 regole la vedo dura ignorare IP rfc1918
secondo: se lanci shorewall - salvi il tutto con iptables-save che differenza abbiamo in fase di start? 10 ms? ... no troppo
terzo: firewall con 3,4,5,6 zone: 15 regole non bastano di sicuro (a meno che non usi 3 policy di default di DROP )
(e con shorewall ti assicuro che scrivi molto,molto meno)
Parlare di regole pesanti o meno mi sembra proprio assurdo.
Un 486 che lavori come firewall a 3 zone (e non offra servizi pesanti come VPN) e sempre adeguato.
Il che la dice lunga sulla pesantezza
Se cerchiamo di snellire la macchina... cerchiamo altrove.. che e' meglio!
del tutto IMHO
ciao |
Mah...non so che dirti!
Certo che le mie firewall/nat (due mandrake e una TSL) separate, gestisce tutto il traffico come
ho detto in modo ottimale e se le pinghi non ti rispondono ne accettano connessioni,
semplicemente perchè è tutto droppato su ogni catena di ingresso.
Permette serivizio ssh e di vnc, server web, oltre che di nat per una decina di computer, e sia
su macchine linux che win va come se non ci fosse neanche. Sono due anni che uso
e nessun blocco o tentativo di intrusione.
ovviamente è imho la cosa
Inoltre perferisco sempre mettere io le mani sulle configurazioni. |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Fri Mar 18, 2005 11:46 am Post subject: |
|
|
scusa...
ma hai su http e vnc e ti preoccupi per il carico delle regole di iptables?
cmq.. ognuno e' libero di pensarla come vuole.
Resta di fatto che iptables non e' uno strumento per tutti.
iptables per la sua totale configurabilita' e' complesso da utilizzare e mantenere
Quindi a mio avviso sia i principianti che gli advanced user possono trarre vantaggio da un tool come shorewall.
ciao
EDIT: nessun tentativo di intrusione? a che serve il firewall?
_________________
while True:Gentoo() |
|
| Back to top |
|
|
AlterX
l33t
Joined: 03 Apr 2004
Posts: 754
Location: rm -rf /*
|
| Posted: Fri Mar 18, 2005 12:57 pm Post subject: |
|
|
| xchris wrote: | scusa...
ma hai su http e vnc e ti preoccupi per il carico delle regole di iptables?
|
Non è che li ho su....abbiamo dei servizi, quali posta e web, per cui viene garantito l'accesso da rete esterna
da macchine che ne facciano richiesta; ovviamente ci sono delle regole che stabiliscono dove instradare i pacchetti
| Quote: |
cmq.. ognuno e' libero di pensarla come vuole.
Resta di fatto che iptables non e' uno strumento per tutti.
iptables per la sua totale configurabilita' e' complesso da utilizzare e mantenere
Quindi a mio avviso sia i principianti che gli advanced user possono trarre vantaggio da un tool come shorewall.
ciao
|
Per il resto la penso come te. |
|
| Back to top |
|
|
arnor
Tux's lil' helper
Joined: 01 Nov 2004
Posts: 147
|
| Posted: Fri Mar 18, 2005 4:46 pm Post subject: |
|
|
grazie ho coretto il file con le rules.
Per quanto riguarda la zone "fw" l'incomprensione nasce perchè nel file di gentoo /etc/shorewall/zones di default "fw" non è presente. Viene citato in shorewall.conf
A me questo cosa a inizialmente disorientato.
Tutto qui.... ora mi sto lanciando ad installare il nostro nuovo webserver e userò nuovamente shorewall
Veramente bello, ancora grazie per avermi fatto conoscere questa utility
... la vpn l'ho rimandata di qualche giorno perchè mi pare un po' più ostica...
ciao lo |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Fri Mar 18, 2005 5:46 pm Post subject: |
|
|
si posso comprendere...
infatti nella guida dicevo che una "zona logica" e' gia' definita di default
sono contento che lo apprezzi.
Altra cosa comoda... il debug in caso di problemi e' banale
la vpb con openvpn viene su che e' una bellezza
Ricorda il file tunnels. (oppure se preferisci avere tutto nelle rules metti ACCET net:altro_host fw udp 5000
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
makoomba
Bodhisattva
Joined: 03 Jun 2004
Posts: 1856
|
| Posted: Fri Mar 18, 2005 6:48 pm Post subject: |
|
|
| shorewall gestisce anche configurazioni bridged ? |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Sat Mar 19, 2005 12:10 am Post subject: |
|
|
dipende a che livello vuoi il firewall...
se vuoi fare filtering sulle 2 (supponiamo) interfacce che fanno il bridge la risposta e' no. (perche' devi usare ebtables)
se e' sufficiente considerare br0 allora si... e' come una qualunque interfaccia.
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
makoomba
Bodhisattva
Joined: 03 Jun 2004
Posts: 1856
|
| Posted: Sat Mar 19, 2005 9:43 am Post subject: |
|
|
| xchris wrote: | dipende a che livello vuoi il firewall...
se vuoi fare filtering sulle 2 (supponiamo) interfacce che fanno il bridge la risposta e' no. (perche' devi usare ebtables)
se e' sufficiente considerare br0 allora si... e' come una qualunque interfaccia.
|
con physdev non devi necessariamente utilizzare ebtables per filtrare sulle singole interfacce.
vabbè, allora mi sa che devo continuare ad usare script ad hoc. |
|
| Back to top |
|
|
xchris
Advocate
Joined: 10 Jul 2003
Posts: 2824
|
| Posted: Sat Mar 19, 2005 10:30 am Post subject: |
|
|
mi correggo!
non sapevo si potesse fare senza ebtables...
ecco con shorewall:
http://www.shorewall.net/bridge.html
ciao
_________________
while True:Gentoo() |
|
| Back to top |
|
|
makoomba
Bodhisattva
Joined: 03 Jun 2004
Posts: 1856
|
| Posted: Sat Mar 19, 2005 10:39 am Post subject: |
|
|
ok, allora c'è speranza
grazie per il link |
|
| Back to top |
|
|
|
Forum italiano (Italian)
