In this article, we will understand these concepts:
- Configure access to and from the Samba server at the firewall level
- Troubleshooting of Samba server-related firewall faults
This article helps you prepare for objective 302 under theme 315 of the Linux Professional Institute (LPI) hybrid environment Professional examination 315.2. The weight of the target is 2.
Prerequisites
To make the most effective use of the articles in this series, you should have advanced Linux knowledge and need to prepare a Linux system to use it to practice the commands described in this article. In addition, you must be able to access the Windows environment and use it to test security settings.
Firewall
Samba has many features to restrict who can access Shared Files-restrict access to specific user names, force password requests, inspection team members, or filter at the network layer. The following parameters, such as allow hosts and smb ports, operate on the IP address and User datasync Protocol (UDP)/TCP port, A simple method is provided to control which hosts can be connected to the Samba server.
If you can identify which devices are connected to the server, such as an internal network, or even a specific subnet or a group of servers, network layer control is implemented. This is the first line of defense: If attackers cannot connect to the device, the device will be safer.
Controlling Network access in the Samba daemon sounds like a perfect solution, but there are actually better methods. To determine whether the remote connection meets the requirements, Samba must first accept the connection, because Samba can obtain detailed information only after the connection is complete. To prevent non-conforming users from connecting to Samba, it makes more sense for Samba to see these connections. All configurations in Samba only affect Samba. Therefore, you must find a similar solution for other daemon such as web servers and file transfers.
In a typical environment, network security is not managed by the system administrator but by other IT employees. Control access at the host layer rather than the application layer to implement business separation and reduce errors caused by changes to smb. conf.
Iptables
Linux provides a powerful host-based firewall called iptables. This firewall can check the packages that pass in or out of Linux devices. Iptables can also be the name of the package filtering system in the Linux kernel or the command used to manage the filter. After several years of development, the package filtering system in the kernel has evolved from a simple matching engine to a powerful firewall that can dynamically load plug-ins. Therefore, configuration is complicated beyond the scope of basic use cases.
The first important concept of iptables is the table itself. A table is a self-contained list of rules and operations. When the kernel needs to filter packets, it queries the filter table. If you need Network Address Translation (NAT), the nat table is used. Other tables are also used based on the network features loaded to the kernel. A data packet can traverse multiple tables. For example, packet filtering is performed before address translation.
Each table is a chain. Each table has predefined chains. You can also add custom chains to the list. These predefined links are used at different time points in the data packet lifecycle. For example, a filter table has three predefined links:
- INPUT. Defines how data packets are transmitted to the host.
- OUTPUT. Applicable to outgoing packets from the host.
- FORWARD. It is only used to pass data packets from one interface to another, for example, when the host acts as a router.
Each chain is an ordered list containing zero or more rules. Each rule consists of a matching clause and a target. The matching clause can be any content, from the IP address or port to the speed limit statement that only takes effect when the specified operation is too frequent. The target can be another chain or operation, such as a command to accept or discard data packets. You can use the kernel module to create matching clauses and targets without any restrictions.
The kernel selects a chain based on what needs to be done and views each rule in order. After the first matching rule is met, the kernel jumps to the target. In most cases, the rule processing will stop, although some targets, such as logon, are considered not to end, so the kernel will continue to process the next rule. If no rules are matched, the default target of the chain is used.
Note: For the purpose of this Article, this article only uses the filter table.
Use firewall to protect Samba
There are a variety of different methods to design Samba firewall policies. When selecting a firewall policy, you should consider the network layout and who or which hosts need to access the Samba server. At a higher level, you can choose to protect the entire host or focus only on Samba.
If you want to protect the entire host, you do not have to worry about which port Samba uses. The following code is a simple policy that allows only traffic from the 10.0.0.0/8 private network to the local server:
iptables -A INPUT -s 10.0.0.0/8 -j ACCEPTiptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -P INPUT DROP |
The first command adds a rule to the INPUT chain, which adds the rule to the current rule list. This rule sets all content from the source network-s) 10.0.0.0/8 to jump to the ACCEPT target, and it will ACCEPT data packets. The second command allows packages from an existing Session, which is implemented by calling the state matters with-m state. Which of the following connections will be tracked when the server leaves the host. The response packet of the outgoing connection is considered as established or related, so the rest of the rule will accept these packets.
The last command sets the Default policy for the INPUT chain to discard data packets. If the packet is not from the 10.0.0.0/8 network or is not part of the connection generated by the host, it will not be accepted.
You can obtain more precise granularity by filtering at the port layer. In the previous example, the source address is filtered, and thus all services are blocked. If you have a web server on your host and want it to be accessible to the general Internet, the previous policy will not work.
Let's look back at "learn about Linux, 302 hybrid environment): Configure Samba". Samba uses four different ports:
- 137 UDP. Network Basic Input/Output System (NetBIOS) Name Service.
- 138 UDP. NetBIOS datagram service.
- 139 TCP. NetBIOS session service.
- 445 TCP. Directly host the Common Internet File System [CIFS] on TCP.
Listing 1 demonstrates a policy that allows you to connect to the Samba service from the 10.0.0.0/8 network, or allow the web server to operate without any restrictions.
Listing 1. Port-layer operation policy
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPTiptables -A INPUT -p udp -s 10.0.0.0/8 --dport 137 -j ACCEPTiptables -A INPUT -p udp -s 10.0.0.0/8 --dport 138 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 139 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 445 -j ACCEPTiptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -P INPUT DROP |
The policy in Listing 1 is much more complex than the previous one, because it sets different applications and each has a different policy. The first two rules match all parts of the NEW session-m state -- state NEW) and are sent to port 80 or port 443 -- dport 80, -- dport 443) -p TCP ). There are no restrictions on the source address, so it will support everyone.
The next two rows match all UDP packets sent from the internal network-s 10.0.0.0/8) to port 137 or port 138 -- dport 137, -- dport 138)-p udp ). UDP is stateless, so you don't have to worry about whether the connection is new or established.
Line 2 and line 3 combine the status check and source address filter to only allow new connections from the internal network on port 5th and port 6th.
The last two rows are the same as those of the previous policy. If the data packet is related to the current connection, It is supported. Others will be discarded.
Troubleshoot firewall faults
Firewall problems are common because unexpected requirements may occur or applications may not run as expected. Rules are also common, especially when handling a long string of port numbers and IP addresses. However, not all problems are related to the firewall. Therefore, you should understand some basic network troubleshooting steps.
View Policy
Use the iptables command to view the policy. -L option lists policies, while verbose-v option adds additional details, such as packet counters. Listing 2 shows the policy of Listing 1.
List 2. view detailed policies
# iptables -L -vChain 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,ESTABLISHEDChain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destinationChain OUTPUT (policy ACCEPT 292 packets, 35009 bytes) pkts bytes target prot opt in out source destination |
Detailed statistics show the number of data packets and the number of bytes matching the rules in the first two columns. For Listing 2, you will see that this packet only matches the last rule. Take a closer look at the first line of the output, and you will see that the default destination also has a number of data packets. 45 packets are discarded because they do not match any rule. This indicates that unauthorized users attempt to access the host, or the legitimate traffic is blocked by incorrect firewall policies.
Another purpose of viewing firewall policies is to fully understand the policies. Since the processing will stop after the first match, you should start from the beginning of the policy and continue to look down to determine whether a rule will discard your traffic.
A common scenario is that unspecified rules appear before specific rules. To avoid problems, place the most specific rules in the Policy header so that exceptions can be found first. However, this practice is not always effective, so you should find users who cannot connect to the server.
Listing 3 shows the policy of a server in the Engineering Network. Users in the same network cannot connect to the service.
Listing 3. Policies with overwriting rules
# iptables -L -vChain INPUT (policy DROP 21 packets, 2967 bytes)target prot opt in out source destinationACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:httpACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:httpsDROP tcp -- any any 10.0.0.0/8 anywhereACCEPT udp -- any any 10.2.3.0/24 anywhere udp dpt:netbios-nsACCEPT udp -- any any 10.2.3.0/24 anywhere udp dpt:netbios-dgmACCEPT tcp -- any any 10.2.3.0/24 anywhere state NEW tcp dpt:netbios-ssnACCEPT tcp -- any any 10.2.3.0/24 anywhere state NEW tcp dpt:microsoft-dsACCEPT 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 other places in the company, that is, 10.0.0.0/8, will also be blocked. The 10.2.3.0/24 network is a subnet of a larger network. Therefore, rules that Block the entire 10.0.0.0/8 network are placed before the Server Message Block (SMB) rules. Therefore, even Engineering users are captured by DROP, because iptables uses the first match instead of the best match concept.
The solution to the above problems is to block the company's network after the specific rules are processed. In that case, the Engineering Network package will be accepted first.
Advanced troubleshooting
You cannot determine whether the firewall is faulty or the network is faulty elsewhere. The simplest test method is to disable the firewall and check whether the connection is successful. Of course, this is not always the case. If you cannot close the firewall, the second best solution is to observe the packets entering the server.
The tcpdump tool displays the network package that the server sees, even if the firewall policy discards the package. If you can see the connection attempts from the server, you will know that the packets have arrived at the server. If the service is running, you may conclude that the firewall discards data packets. Listing 4 shows that the tcpdump tool is being executed.
Listing 4. Data Packet tracking for blocked SMB connections
# tcpdump -i eth0 tcp port 445tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes20: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 ... |
Tcpdump options are as follows:
- -I eth0. Listen to the eth0 interface.
- Tcp port 445. Check the packets on TCP port 445.
The result of Listing 4 shows that three data packets are sent to the server. Arrows indicate the direction of the data stream: The three packets arrive at the server from the client on the microsoft-ds port 455. The S at the end of the row indicates a connection attempt. If no response is returned, the server does not respond.
Another indication of connection failure is the difference between consecutive packets. The timestamp on the left shows that the second package arrived about 3 seconds after the first package, and the third package arrived after these 6 seconds. Most network protocols implement the exponential back-off algorithm, which means the time between each successive attempt will double.
Http://www.ibm.com/developerworks/cn/linux/l-lpic3-315-2/index.html? Ca = drs-