In this article, learn about these concepts:
- Configure access to and from a Samba server at the firewall level
- Troubleshoot firewall problems with your Samba server
This article helps you prepare for Objective 315.2 in Topic 315 of the Linux Professional Institute's (LPI) Mixed Environment Specialty exam (302). The objective has a weight of 2.
To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test your security settings.
Samba has many features to restrict who can access which
share—limiting access to particular user names, enforcing password
requirements, checking group membership, or filtering at the network
level. The latter parameters, such as
allow hosts and
smb ports, operate on IP addresses and User
Datagram Protocol (UDP)/TCP ports, which provide an easy way of
controlling which hosts are allowed to connect to your Samba server.
Network-level control is achieved when you can identify which devices will connect to a server, such as those belonging to an internal network or even to a particular subnet or group of servers. It is a first line of defense: if an attacker can't connect to a device, the device is safer.
Controlling network access within the Samba daemon may sound like the perfect solution, but there are better ways. To determine whether a remote connection is desirable, Samba must first accept the connection, because Samba doesn't get any details about the incoming connection until it has completed that connection. If the idea were to prevent undesirable people from connecting to Samba, it would make more sense to prevent Samba from even seeing the connection. Any configuration inside Samba only affects Samba, and you must then find similar solutions for other daemons, such as web servers and file transfer.
In a typical environment, network security is handled not by systems administrators but by other IT staff members. Controlling access at the host level rather than the application level provides separation of concerns and reduces errors caused by changes to smb.conf.
Linux provides a robust host-based firewall called iptables. This firewall can inspect packets coming into, out of, or through a Linux device. iptables can refer to the packet-filtering system inside the Linux kernel or the name of the command used to manage the filters. The packet-filtering system in the kernel has grown over the years from a simple matching engine to a robust firewall capable of loading plug-ins dynamically. As such, it can be complicated to configure once you stray outside the basic use cases.
The first important concept behind iptables is that of the tables themselves. A table is a self-contained list of rules and actions. When the kernel needs to filter a packet, it consults the filter table. When network address translation (NAT) is called for, the nat table is used. Other tables may exist depending on which network features have been loaded into the kernel. A packet may traverse multiple tables—for example, to perform packet filtering before address translation.
Within each table is a set of chains. Each table has some predefined chains, and you can add custom chains to this list. The predefined chains are used at different points in a packet's life cycle. For example, the filter table has three predefined chains:
- INPUT. Used to determine what to do with packets that are destined to the host itself.
- OUTPUT. Applied to packets originating from the host.
- FORWARD. Only for packets passing from one interface to another, such as when the host is acting as a router.
A chain has an ordered list of zero or more rules, with each rule consisting of a matching clause and a target. The matching clause can be almost anything, from an IP address or port to rate limit statements that only take effect when a particular action occurs too frequently. The target can be another chain or an action, such as an instruction to accept or drop the packet. You can create both the matching clauses and the targets through kernel modules, so the possibilities are limitless.
The kernel chooses the chain based on what needs to be done and looks at each rule in order. Upon the first match, the kernel jumps to the target. In most cases, rule processing stops, though some targets—such as logging—are considered non-terminating, so the kernel will continue processing with the next rule. If no rule is matched, the chain's default target is used.
Note: For the purposes of this article, only the filter table is needed.
Protecting Samba with a firewall
There are many different ways to design a firewall policy for Samba, with the choice being made on items like the layout of your network and who or what needs access to your Samba server. At a high level, you can either choose to protect the whole host or just focus on Samba.
If you want to protect the whole host, then you aren't concerned with which ports Samba is using. The code that follows shows a simple policy to allow traffic only from the 10.0.0.0/8 private network to the local server:
iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -P INPUT DROP
The first command adds a rule to the INPUT chain by appending it to the
current list of rules. The rule specifies that anything coming from the
source network (
-s) 10.0.0.0/8 will jump to the
ACCEPT target, which accepts the packet. The second command allows packets
that come from an existing session, achieved by calling the state matcher
-m state. This matcher keeps track of
which connections are leaving the host. The response packets to the
outgoing connections are considered
related, so the rest of the rule accepts
The final command sets the default policy of the INPUT chain to drop the packet. If the packet doesn't come from the 10.0.0.0/8 network or is not part of a connection that the host initiated, it will not be allowed.
You can get more granular by filtering at the port level. The previous example filtered on the source address, so all services would be blocked. If you had a web server on your host that you wanted to open to access by the general Internet, the previous policy would not do.
Recall from "Learn Linux, 302 (Mixed environments): Configure Samba" that Samba uses four different ports:
- 137 UDP. Network basic input/output system (NetBIOS) name services.
- 138 UDP. NetBIOS datagram services.
- 139 TCP. NetBIOS session services.
- 445 TCP. Direct hosting (Common Internet File System [CIFS] over TCP).
Listing 1 shows a policy that allows connections from the 10.0.0.0/8 network to the Samba services and also allows a web server to operate without restriction.
Listing 1. A policy that operates at the port level
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 137 -j ACCEPT iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 138 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 139 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 445 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -P INPUT DROP
The policy from Listing 1 is more complex than the previous policy, because
it specifies several different applications, each with different policies.
The first two rules match any incoming TCP packets
-p tcp) that are part of a new session
-m state --state NEW) and sent to either port
80 or port 443 (
--dport 443). There are no restrictions on the
source address, so anyone will be allowed.
The next two lines match any UDP packets
-p udp) coming from the internal network
-s 10.0.0.0/8) to port 137 or port 138
--dport 138). UDP is stateless, so you don't
need to worry about whether the connection is new or established.
Lines 5 and 6 combine the state matcher and the source address filter to allow only new connections on ports 139 and 445 if they come from the internal network.
Finally, the last two lines operate the same as in the previous policy. If the packet is related to a current connection, it is allowed. Anything else is dropped.
Troubleshooting firewall problems
Firewall problems are common, often because you run into an unexpected requirement or find out an application doesn't run the way you expect it to. Mistakes in the rules themselves are common, especially when dealing with long lists of port numbers and IP addresses. Not all problems are firewall related, though, so you should still know your basic network troubleshooting steps.
Viewing the policy
Listing 2. Viewing the detailed policy
# iptables -L -v Chain INPUT (policy DROP 47 packets, 5125 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:http 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:https 0 0 ACCEPT udp -- any any 10.0.0.0/8 anywhere udp dpt:netbios-ns 0 0 ACCEPT udp -- any any 10.0.0.0/8 anywhere udp dpt:netbios-dgm 0 0 ACCEPT tcp -- any any 10.0.0.0/8 anywhere state NEW tcp dpt:139 0 0 ACCEPT tcp -- any any 10.0.0.0/8 anywhere state NEW tcp dpt:445 214 15216 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 292 packets, 35009 bytes) pkts bytes target prot opt in out source destination
The verbose statistics show the number of packets and bytes that have matched a rule in the first two columns. From Listing 2, you can see that packets have only matched the last rule. Looking more closely at the first line of output, you will see that the default target also has a packet count. Forty-seven packets have been dropped because they didn't match a rule; this would indicate that either someone unauthorized is trying to access the machine or legitimate traffic is getting blocked by an incorrect firewall policy.
Another use for viewing the firewall policy is to get an understanding of the policy in its entirety. Because the processing stops after the first match, you should start at the top of the policy and work your way through to determine whether a rule is dropping your traffic.
One common scenario is when a less specific rule appears before a more specific rule. To avoid problems, put your most specific rules toward the top of your policy so that the exceptions are taken care of first. However, this convention doesn't always work out, and you might find yourself with users who are unable to connect to your server.
Listing 3 shows the policy on a server in the Engineering network. Users on the same network cannot connect to the service.
Listing 3. A policy with a rule that overrides another
# iptables -L -v Chain INPUT (policy DROP 21 packets, 2967 bytes) target prot opt in out source destination ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:http ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:https DROP tcp -- any any 10.0.0.0/8 anywhere ACCEPT udp -- any any 10.2.3.0/24 anywhere udp dpt:netbios-ns ACCEPT udp -- any any 10.2.3.0/24 anywhere udp dpt:netbios-dgm ACCEPT tcp -- any any 10.2.3.0/24 anywhere state NEW tcp dpt:netbios-ssn ACCEPT tcp -- any any 10.2.3.0/24 anywhere state NEW tcp dpt:microsoft-ds ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
The server in Listing 3 belongs to the Engineering network, which is
10.2.3.0/24. Access from the rest of the company, which is 10.0.0.0/8,
should be blocked. The 10.2.3.0/24 network is a subnet of the larger
network, so the rule to block the whole 10.0.0.0/8 network comes before
the Server Message Block (SMB)-specific rules; as a result, even
Engineering users will be caught by the
rule, because iptables uses a first-match, not a best-match, concept.
The solution to the problem above is to block the corporate network after the specific rules have been processed. That way, packets for the Engineering network will be accepted first.
Often, you can't be sure whether the firewall is to blame or the problems are somewhere else in the network. The simplest test is to turn off the firewall and see if the connection succeeds. Of course, doing so is not always possible, so if you can't drop the firewall, the next best thing is to watch for the packet to come to the server.
tcpdump utility displays the network packets
that the server sees, even if the firewall policy drops the packet. If you
can see the connection attempt from the server, then you know the packet
is getting to the server. Assuming the service is running, you can
reasonably conclude that the firewall is dropping the packet. Listing 4 shows the
tcpdump utility in action.
Listing 4. Packet trace of a blocked SMB connection
# tcpdump -i eth0 tcp port 445 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 20:24:18.392106 IP CLIENT.search > SERVER.microsoft-ds: S ... 20:24:21.358458 IP CLIENT.search > SERVER.microsoft-ds: S ... 20:24:27.393604 IP CLIENT.search > SERVER.microsoft-ds: S ...
The options to
tcpdump are as follows:
-i eth0. Listen on the eth0 interface.
tcp port 445. Watch for packets on TCP port 445.
The results of Listing 4 show that three packets made it to the server. The
arrow indicates the direction of the flow: These three packets go from the
client to the server on the microsoft-ds port, which is 445. The
S near the end of the line indicates a
connection attempt, and the lack of response indicates that the server is
Another indication of a failed connection is the increasing difference between successive packets. The timestamps on the left show that the second packet came roughly 3 seconds after the first, then the third came 6 seconds after that. Most network protocols implement an exponential back-off, which means that the time between successive attempts doubles each time.
- The smb.conf man page has more examples and descriptions of the commands shown in this article.
- Your firewall rules will not survive a reboot. Learn how to save your rule set in Debian and Red Hat Linux installations.
- Keep on top of Samba security patches to make sure your system is current.
- At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the LPI's Linux systems administration certification. In particular, look at the LPI-302 detailed objectives.
- Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
- In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
- Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
Get products and technologies
- Firewall Builder is a graphical firewall policy manager that can manage your iptables rules with ease.
- Netfilter.org is the home page for iptables. There, you can find more documentation and a list of modules that can extend your firewall's functionality.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.