Learn Linux, 302 (Mixed environments)

Samba security

Secure Samba at both the firewall and daemon levels


Content series:

This content is part # of # in the series: Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

This content is part of the series:Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

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.

Understanding iptables

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 private network to the local server:

iptables -A INPUT -s -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) 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 with -m state. This matcher keeps track of which connections are leaving the host. The response packets to the outgoing connections are considered established or related, so the rest of the rule accepts those packets.

The final command sets the default policy of the INPUT chain to drop the packet. If the packet doesn't come from the 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 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 --dport 137 -j ACCEPT
iptables -A INPUT -p udp -s --dport 138 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s --dport 139 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s --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 80, --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 to port 137 or port 138 (--dport 137, --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

You use the iptables command to view the policy. The -L option lists the policy, and the verbose (-v) option adds extra details, such as packet counters. Listing 2 shows the policy from Listing 1.

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  anywhere     udp dpt:netbios-ns
    0     0 ACCEPT  udp  --  any  any  anywhere     udp dpt:netbios-dgm
    0     0 ACCEPT  tcp  --  any  any  anywhere     state NEW tcp dpt:139
    0     0 ACCEPT  tcp  --  any  any  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   anywhere
ACCEPT   udp  --  any  any  anywhere      udp dpt:netbios-ns
ACCEPT   udp  --  any  any  anywhere      udp dpt:netbios-dgm
ACCEPT   tcp  --  any  any  anywhere      state NEW tcp dpt:netbios-ssn
ACCEPT   tcp  --  any  any  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 Access from the rest of the company, which is, should be blocked. The network is a subnet of the larger network, so the rule to block the whole network comes before the Server Message Block (SMB)-specific rules; as a result, even Engineering users will be caught by the DROP 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.

Advanced troubleshooting

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.

The 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 not responding.

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.

Downloadable resources

Related topics

  • 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.
  • 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.
  • 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.
  • 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.
  • Follow developerWorks on Twitter.
Zone=Linux, Security
ArticleTitle=Learn Linux, 302 (Mixed environments): Samba security