[clug] iptables for a samba file server
George at Clug
Clug at goproject.info
Thu Sep 21 12:05:49 UTC 2017
Steve,
To answer your question "what is your rational behind specifically
permitting the ports that can exit the system?", there is a school of
thought that firewalls should only permit traffic on required ports,
and that all other ports should be blocked. Since my Samba server is
only used as a file server, I have only enabled the ports that are
required to 1) allow Samba to act as a SMB file server, 2) NTP for
time management of the server, 3) ssh and apt-get for maintaining the
server.
I believe there is another school of thought that you allow all
outgoing ports, and block all but required incoming ports.
I am not completely familiar with FTP, however I believe that FTP
requires outgoing ports 1024 and above to be opened (known as
unprivileged ports). Which is one very large outgoing hole in a
firewall, hence I don't normally suggest using FTP.
However it is also my understanding that since these are outgoing
ports, and no services are [normally] listening on ports 1025 and
above, there "should be" no security risk to having these outgoing
ports opened. These ports are only enabled for outgoing traffic then
they can only used to initiate calls to external systems in response
to a request (e.g. an FTP connection). Even then the main risk is only
that a malicious program (e.g. virus) has managed to get itself
running on your server and is trying to find a way out via a port that
is not being used by an exiting server service.
However I have seen examples where both incoming and outgoing
unprivileged ports are opened. This seems to be a security risk? It
this not determined to be a security risk as no services are listening
on incoming unprivileged ports ?
If anyone can correct me or explain this better, then please do.
http://www.techrepublic.com/article/how-ftp-port-requests-challenge-firewall-security/
PORT-mode FTP server-side firewall
What if you’re the firewall/router administrator who has to deal
with an FTP server behind your device? In this case, you need to open
the following ports:
* Outbound: TCP ports 1025 and above
* Inbound: TCP port 21
I also have a Minecraft server, and I believe it requires the
unprivileged ports 1024 to 65535 to be open for outgoing traffic.
Though am I correct in suggesting that the example below is saying
that Minecraft wants to use unprivileged ports 1024 to 65535 for
incoming traffic? Is this a security risk?
https://github.com/nocliq/IPtables-Firewall-setup/blob/master/setiptables.sh
$IPTABLES -A INPUT -p tcp --source-port 1024:65535 --destination-port
1024:65535 -m recent --name Minecraft --rcheck --seconds 10800
--rsource -j ACCEPT
$IPTABLES -A INPUT -p tcp --source-port 1024:65535 --destination-port
1024:65535 -m recent --name Minecraft --rcheck --seconds 10800 --rdest
-j ACCEPT
$IPTABLES -A INPUT -p tcp --destination-port 25565 -m recent --set
--name Minecraft --rdest -m comment --comment "Minecraft" -j ACCEPT
>From my reading tonight, at first I believed I had an error in my
configuration. For my outgoing ports I should have used "--sport" not
"--dport", as in;
http://thesimplesynthesis.com/article/iptables
# allow input on the following ports
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# allow output on the following ports
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
But I don't think it matters if I specify "--sport" or "--dport" or
both. For example in "iptables -A OUTPUT -p tcp --sport 22 --dport
22 -j ACCEPT", if I specify both all I am saying is the traffic is
allowed to leave on port 22 and it must be going to port 22 on the
remote end.
But why do some people specify both dports and sports for OUTPUT
rules?
https://github.com/nocliq/IPtables-Firewall-setup/blob/master/setiptables.sh
# Outgoing - special FTP
$IPTABLES -A OUTPUT -p tcp --source-port 1024:65535 --destination-port
1024:65535 -m recent --name FTP --rcheck --seconds 10800 --rsource -j
ACCEPT
I am guessing that in "--sport 22 --dport 22" it simple means my
outgoing server would, say, use port 22 to go out on eth0, and its
intended destination has to be port 22, but that this can be changed
if desired.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-iptables-options.html
17.3.4.1. TCP Protocol
These match options are available for the TCP protocol (-p tcp):
--dport — Sets the destination port for the packet. Use
either a network service name (such as www or smtp), port number, or
range of port numbers to configure this option. To browse the names
and aliases of network services and the port numbers they use, view
the /etc/services file. The --destination-port match option is
synonymous with --dport.
To specify a specific range of port numbers, separate the two
numbers with a colon (:), such as -p tcp --dport 3000:3200. The
largest acceptable valid range is 0:65535.
Use an exclamation point character (!) after the --dport option
to match all packets which do not use that network service or port.
--sport — Sets the source port of the packet using the same
options as --dport. The --source-port match option is synonymous with
--sport.
17.3.5. Target Options
Once a packet has matched a particular rule, the rule can direct the
packet to a number of different targets that decide its fate and,
possibly, take additional actions. Each chain has a default target,
which is used if none of the rules on that chain match a packet or if
none of the rules which match the packet specify a target.
The following are the standard targets:
— Replace with the name of a user-defined chain within the
table. This target passes the packet to the target chain.
ACCEPT — Allows the packet to successfully move on to its
destination or another chain.
DROP — Drops the packet without responding to the requester.
The system that sent the packet is not notified of the failure.
QUEUE — The packet is queued for handling by a user-space
application.
RETURN — Stops checking the packet against rules in the
current chain. If the packet with a RETURN target matches a rule in a
chain called from another chain, the packet is returned to the first
chain to resume rule checking where it left off. If the RETURN rule is
used on a built-in chain and the packet cannot move up to its previous
chain, the default target for the current chain decides what action to
take.
17.3.2. Command Options
Command options instruct iptables to perform a specific action. Only
one command option is allowed per iptables command. With the exception
of the help command, all commands are written in upper-case
characters.
The iptables commands are as follows:
-A — Appends the iptables rule to the end of the specified
chain. This is the command used to add a rule when rule order in the
chain does not matter.
-C — Checks a particular rule before adding it to the
user-specified chain. This command can help you construct complicated
iptables rules by prompting you for additional parameters and options.
-D — Deletes a rule in a particular chain by number (such as
5 for the fifth rule in a chain). You can also type the entire rule,
and iptables deletes the rule in the chain that matches it.
-E — Renames a user-defined chain. This does not affect the
structure of the table.
-F — Flushes the selected chain, which effectively deletes
every rule in the the chain. If no chain is specified, this command
flushes every rule from every chain.
-h — Provides a list of command structures, as well as a
quick summary of command parameters and options.
-I — Inserts a rule in a chain at a point specified by a
user-defined integer value. If no number is specified, iptables places
the command at the top of the chain.
Caution Caution
Be aware when using the -A or -I option that the order of the
rules within a chain are important for determining which rules apply
to which packets.
On Thursday, 21-09-2017 at 00:28 Steve Walsh via linux wrote:
Hello
On 20/09/17 20:38, CLUG via linux wrote:
> These rules allow for management via ssh (22), DNS lookup (53),
NTP
> time (123), port 80 for apt, and the minimum ports for an smb file
> server. I guess ping is not required but it can be useful.
what is your rational behind specifically permitting the ports that
can
exit the system? I think following that path, coupled with a default
DROP on your output chain, is going to come back around to bite you at
some point down the track, and it will be a serious pain to debug.
>
> How would I apply these rules to a specific interface, e.g. eth0 ?
According to the man page, you can use the -i and -o options;
[!] -i, --in-interface name
Name of an interface via which a packet was
received
(only for
packets entering the INPUT,
FORWARD and PREROUTING
chains).
When the "!" argument is used before
the interface
name, the
sense is inverted. If the interface
name ends in a
"+", then
any interface which begins with this name
will match.
If this
option is omitted, any interface name will
match.
[!] -o, --out-interface name
Name of an interface via which a packet is
going to be
sent (for
packets entering the FORWARD, OUTPUT and
POSTROUTING
chains).
When the "!" argument is used
before the interface
name, the
sense is inverted. If the interface name
ends in a
"+", then
any interface which begins with this
name will match.
If this
option is omitted, any interface name will
match.
--
linux mailing list
linux at lists.samba.org
https://lists.samba.org/mailman/listinfo/linux
More information about the linux
mailing list