LinuxPlanet Blogs

Background

People that use Linux on a daily basis probably are completely oblivious to the actual mechanisms being used to store their passwords safely and securely on a given Linux system. Oh they might guess that their password is stored in the /etc/passwd file (they’d be wrong by the way) but most probably never even gave it a passing thought. So I thought I’d take the opportunity to shed some light on how Linux systems “stash” your precious password away.

Solution

So if your password isn’t actually stored in the /etc/passwd file then where does it get stored?

Answer: the /etc/shadow file.

This file is where all the keys to each user’s account are kept for safe keeping. Obviously only the root user can peer inside this file so all the commands we’ll be dealing with in this post, it should be assumed that you’ll need to either be root, or use sudo to run.

/etc/shadow

A typical /etc/shadow entry:

1

root:$6$bbmDJwcZHy5bgEDz$kFO.W/T7nUqcszZWl5RglxoDDAcDxevWpHVfN3v3f.Cx2ZeMcn5PX23VvnnkgtNWZf8hYtqsL0pPkZqyj50NY/:14362:0:33333:7:::

NOTE1: Don’t get too excited, the above isn’t really my entry, I made this one up.
NOTE2: Each field is separated by a colon (:) & we’re only concerned with the first two columns!

dissecting the hash

The key pieces to notice in that line of what looks like gibberish is the following:

• The first column, root is the user whom this entry belongs to from the /etc/passwd file.
• The second column, $6$..... is essentially the user’s hashed password.

Taking the second column apart further you should start to notice that’s it’s not complete gibberish after all.

For example:

• the first couple of characters, $6$, is a mark that tells the system what type of hashing was used to hash the password.
• The text between the next set of dollar signs, $bbmDJwcZHy5bgEDz$, is the actual salt that was used to hash your password.
• Everything else after, is your password + salt hashed using whatever hash function was specified at the beginning, $6$, in our example here.

Specifically if you look at the man page for the crypt command, man 3 crypt there is a section that discusses what the $6$ notation means:

So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.

NOTE: So in our case the password + salt is being hashed using the SHA-512 scheme.

design details

For reference purposes here’s the rest of that excerpt from the crypt man page:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

If salt is a character string starting with the characters "$id$" followed by a
string terminated by "$":
 
       $id$salt$encrypted
 
then instead of using the DES machine, id identifies the encryption method used
and this then determines how the rest of the password string is interpreted.
The following values of id are supported:
 
       ID  | Method
       ─────────────────────────────────────────────────────────
       1   | MD5
       2a  | Blowfish (not in mainline glibc; added in some
           | Linux distributions)
       5   | SHA-256 (since glibc 2.7)
       6   | SHA-512 (since glibc 2.7)
 
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an
SHA-512 encoded one.
 
"salt" stands for the up to 16 characters following "$id$" in the salt. The
encrypted part of the password string is  the actual computed password. The
size of this string is fixed:
 
MD5     | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters
 
The characters in "salt" and "encrypted" are drawn from the set [a–zA–Z0–9./].
In the MD5 and SHA implementations the entire key is significant (instead of
only the first 8 bytes in DES).

Now what?

So by now you’re probably saying to yourself. OK, big deal, my password is hashed with some salt and stored in /etc/shadow. What else?

generating the hash manually using mkpasswd

For starters you can generate the $6$... string yourself manually using the mkpasswd command:

1
2

$ mkpasswd -m sha-512 password saltsalt
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/

In the above command we’re specifying that we want to use the SHA-512 hash, our password is the string password and our salt string is saltsalt. As before we can see in our resulting string the following components:

• $6$ – which hash function was used
• saltsalt – the string “saltsalt” was used
• qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/ – password + salt hashed using SHA-512

generating the hash manually using Python

I came across the following nice Python one-liner that effectively does the same thing as the mkpasswd command discussed above.

1
2
3

$ python -c "import crypt, getpass, pwd; \
             print crypt.crypt('password', '\$6\$saltsalt\$')"
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/

generating the hash manually using Perl

1
2

$ perl -e 'print crypt("password","\$6\$saltsalt\$") . "\n"'
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/

authconfig

Before I wrap up I thought I’d mention one final tool authconfig that’s included on Red Hat distros such as Fedora, CentOS, and RHEL. This tool allows you to change what hash algorithm is being used on a particular system. The command to change a system to use SHA-512 would be as follows:

1

authconfig –passalgo sha512 –update

See the man page for authconfig for more details.

conclusions

And with that you are now a little more in the know as to how Linux systems take your password and store them in the /etc/shadow file.

References

links

• crypt man page
• Thread: generate hashed password for /etc/shadow – ubuntuforums.org
• How to produce test hashes for various formats
• Shadow Fu
• Using ruby to generate SHA512 crypt-style hashes formatted for /etc/shadow?
• Calculate SHA Hash of Linux Password in Shadow File

I came across this question on the Stack Exchange site Unix & Linux. The question interested me so I answered it but thought I’d cross post it on my blog as well, given I took a pretty significant amount of time to put together a test case and write-up of how the solution ultimately worked.

Problem

I’m using rsync to copy some files from a share to another.

Recursively, I need to:

- delete files at the destination that are deleted in the origin
- Only sync php and js files
- exclude de rest of file types
- Don’t delete .svn/ directory in the destination

If I use this:

rsync -zavC --delete --include='*.php' --include='*.js' --exclude="*" /media/datacod/Test/ /home/lucas/Desktop/rsync/

Then rsync is not recursive because exclude=”*” excludes all files but also folders

If I add --include="*/" then the .svn/ directory gets deleted (it also gets included)

How can I solve this mind blasting dilemma?

Solution

The solution I ultimately came up with made use of a little known feature, at least to me, called filters. Filters allow you to play games with the includes/excludes by protecting portions based on regular expressions. Read on, I’ll discuss them further down.

1
2

rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \
     --exclude="*" --delete dir1/ dir2/

test data

To help determine if my solution was going to work or not I created some sample data so that I could test it out. For starters I wrote a script that would generate the data. Here’s that script, setup_svn_sample.bash:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/bin/bash
 
# setup .svn dirs
mkdir -p dir{1,2}/dir{1,2,3,4}/.svn
 
# fake data under .svn
mkdir -p dir1/dir{1,2,3,4}/.svn/origdir
mkdir -p dir2/dir{1,2,3,4}/.svn/keepdir
 
# files to not sync
touch dir1/dir{1,2,3,4}/file{1,2}
 
# files to sync
touch dir1/dir{1,2,3,4}/file1.js
touch dir1/dir{1,2,3,4}/file1.php

Running the above script produces the following directories (dir1 & dir2):

source dir

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

$ tree -a dir1
dir1
|-- dir1
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
|-- dir2
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
|-- dir3
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
`-- dir4
    |-- file1
    |-- file1.js
    |-- file1.php
    |-- file2
    `-- .svn
        `-- origdir

destination dir

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ tree -a dir2
dir2
|-- dir1
|   `-- .svn
|       `-- keepdir
|-- dir2
|   `-- .svn
|       `-- keepdir
|-- dir3
|   `-- .svn
|       `-- keepdir
`-- dir4
    `-- .svn
        `-- keepdir

Running the above rsync command which includes the --filter below we can see that it’s only syncing the files that match the --include patterns:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \
     --exclude="*" --delete dir1/ dir2/
sending incremental file list
dir1/file1.js
dir1/file1.php
dir2/file1.js
dir2/file1.php
dir3/file1.js
dir3/file1.php
dir4/file1.js
dir4/file1.php
 
sent 480 bytes  received 168 bytes  1296.00 bytes/sec
total size is 0  speedup is 0.00

Resulting dir2 afterwards:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$ tree -a dir2
dir2
|-- dir1
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
|-- dir2
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
|-- dir3
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
`-- dir4
    |-- file1.js
    |-- file1.php
    `-- .svn
        `-- keepdir

Why does it work?

The key piece to this script is to make use of the filters capability of rsync. Filters allow you to remove files from the matched set at various points in the command. So in our case we’re filtering any files that match the pattern */.svn*. The modifiers -rs_ tell the filter that we want to filter on both the source side as well as the target side.

excerpt from the FILTER NOTES section of rsync’s man page

- An s is used to indicate that the rule applies to the sending side. When a rule affects the sending side, it prevents files from being
transferred. The default is for a rule to affect both sides unless --delete-excluded was specified, in which case default rules become sender-side only. See also the hide (H) and show (S) rules, which are an alternate way to specify sending-side includes/excludes.

- An r is used to indicate that the rule applies to the receiving side. When a rule affects the receiving side, it prevents files from being deleted. See the s modifier for more info. See also the protect (P) and risk ® rules, which are an alternate way to specify receiver-side includes/excludes.

See man rsync for more details.

Tips for figuring this out (hint using --dry-run)

While describing how to do this I thought I’d mention the --dry-run switch to rsync. It’ extremely useful in seeing what will happen without having the rsync actually take place.

For Example

Using the following command will do a test run and show us the decision logic behind rsync:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

rsync --dry-run -avvzC --filter='-rs_*/.svn*' --include="*/" \
     --include='*.js' --include='*.php' --exclude="*" --delete dir1/ dir2/
sending incremental file list
[sender] showing directory dir3 because of pattern */
[sender] showing directory dir2 because of pattern */
[sender] showing directory dir4 because of pattern */
[sender] showing directory dir1 because of pattern */
[sender] hiding file dir1/file1 because of pattern *
[sender] showing file dir1/file1.js because of pattern *.js
[sender] hiding file dir1/file2 because of pattern *
[sender] showing file dir1/file1.php because of pattern *.php
[sender] hiding directory dir1/.svn because of pattern */.svn*
[sender] hiding file dir2/file1 because of pattern *
[sender] showing file dir2/file1.js because of pattern *.js
[sender] hiding file dir2/file2 because of pattern *
[sender] showing file dir2/file1.php because of pattern *.php
[sender] hiding directory dir2/.svn because of pattern */.svn*
[sender] hiding file dir3/file1 because of pattern *
[sender] showing file dir3/file1.js because of pattern *.js
[sender] hiding file dir3/file2 because of pattern *
[sender] showing file dir3/file1.php because of pattern *.php
[sender] hiding directory dir3/.svn because of pattern */.svn*
[sender] hiding file dir4/file1 because of pattern *
[sender] showing file dir4/file1.js because of pattern *.js
[sender] hiding file dir4/file2 because of pattern *
[sender] showing file dir4/file1.php because of pattern *.php
[sender] hiding directory dir4/.svn because of pattern */.svn*
delta-transmission disabled for local transfer or --whole-file
[generator] risking directory dir3 because of pattern */
[generator] risking directory dir2 because of pattern */
[generator] risking directory dir4 because of pattern */
[generator] risking directory dir1 because of pattern */
[generator] protecting directory dir1/.svn because of pattern */.svn*
dir1/file1.js
dir1/file1.php
[generator] protecting directory dir2/.svn because of pattern */.svn*
dir2/file1.js
dir2/file1.php
[generator] protecting directory dir3/.svn because of pattern */.svn*
dir3/file1.js
dir3/file1.php
[generator] protecting directory dir4/.svn because of pattern */.svn*
dir4/file1.js
dir4/file1.php
total: matches=0  hash_hits=0  false_alarms=0 data=0
 
sent 231 bytes  received 55 bytes  572.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

In the above output you can see that the ./svn directories are being protected by our filter rule. Valuable insight for debugging the rsync.

References

- Delete extraneous files from dest dir via rsync?
- Above scripts in a tarball

zypper ar http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_12.3 packman
zypper in gstreamer-plugins-bad-orig-addon gstreamer-plugins-libav
gstreamer-plugins-ugly-orig-addon w32codec-all
Add the Packman repository and install the required packages.

Aside:  If you don't want to be pestered about package vendor changes in the future you can edit  /etc/zypp/zypp.conf and set "solver.allowVendorChange = true".  But don't do that unless you know what that means.

Background

UEFI looks to be a major pain in the @$$, but like it or hate it everyone in the Linux community will need to learn to navigate it. Here’s a list of useful UEFI resources that I’ve come across as I’ve started to get smarter about how to deal with this beast.

Solution

Wikipedia

• Unified Extensible Firmware Interface

Ubuntu Docs

• UEFI
• UEFIBooting – Booting Linux natively on a UEFI system (without BIOS CSM) using GRUB2

AskUbuntu

• Install Ubuntu next to Windows 8
• Installing Ubuntu on a Pre-Installed UEFI Supported Windows 8 system

Rodsbooks.com

• Managing EFI Boot Loaders for Linux
• Managing EFI Boot Loaders for Linux: Using GRUB 2
• Managing EFI Boot Loaders for Linux: Dealing with Secure Boot

Misc.

• Running RHEL 6 on EFI BIOS-based system

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

Normally on this blog I tend to write about more complicated tasks or fancy Linux tricks and completely overlook some of the most basic tasks that a SysAdmin needs to know. Today I have decided that I will make my blog a little more comprehensive and add some posts with some of the basics.

Along with this I will be starting a new category, called Sysadmin Basics and I will try to post an additional article each week that covers some of the more basic concepts and commands used by Linux and Unix Sysadmins.

Remove Directories with the rmdir command

The rmdir command is used to delete and remove empty directories. I bolded empty as it is important to note that rmdir will only remove a directory if there are no files within that directory. If you want to remove a directory and all files within that directory, skip down to the rm section of this article.

Remove a single empty directory

# rmdir somedir/

Remove multiple empty directories (in a single tree)

# rmdir -p somedir/a/b/c/d/e/f/whoa

While rmdir will not remove directories with files in it; rmdir will recursively remove a directory tree that has no files. In the example somedir only has directory a within it, and the a directory only has b which only has c and so on.

Remove multiple empty directories

The above command will also fail if there are multiple directories in one single directory, to handle that scenario you can list the directories individually and include the –ignore-fail-on-non-empty flag.

# rmdir --ignore-fail-on-non-empty -p somedir/a/b/c/ somedir/a2/b2/

Without the –ignore-fail-on-non-empty flag the command will still print that somedir is not empty even though it removes somedir. This is due to the fact that both command line arguments ask rmdir to remove somedir and rmdir cannot remove that directory until the last step.

Removing Files and Directories with the rm Command

While the rmdir command is solely for directories the rm command can remove both files and directories. With the right combination of flags rm will also remove entire directories, files and all.

Remove a file

# rm a-file
 rm: remove regular empty file `a-file'? y

On it’s own rm will not prompt a user before removing a file; to keep systems safe from accidental file removals some distributions of Linux will ship with an alias for rm with the default .bashrc file. This alias gives the interactive (-i) flag for rm, this tells rm to prompt the user before removing files and directories.

# alias
alias rm='rm -i'

Remove a file without being prompted

While you can simply unalias the rm alias, a simplier and generally used method to remove files without being prompted is to add the force (-f) flag to the rm command. It is advisable that you only add the force (-f) flag if you really know what you are removing.

# rm -f b-file

Remove a file without being prompted and with verbosity

If you don’t want to be prompted for each file removable but also want to keep an eye on rm in case the command starts removing unexpected files, you can simply add the verbose (-v) flag.

# rm -fv c-file
 removed `c-file'

Remove multiple files

There are many ways to remove multiple files, one method is to simply list each file you want to remove.

# rm -f a-file b-file

Removing multiple files with a wildcard

The bash command line supports wildcards and regex statements. A simplier way to remove all files that end in the word file is to simply state *file. I suggest being cautious with wildcards as it is entirely possible to remove a file without meaning to.

# rm -f *file

Remove files using a regex

Another common method of deleting files is to use regex statement, the below would remove anything that looks like files-0 through files-9 but would not remove files-a or files-list.

# rm -f files-[0-9]

Remove a directory and all of it’s contents with rm

If you want to simply remove an entire directory and all of the contents within, including both files and directories the easiest method is to add the recursive (-R) flag to rm. If you are in any way unsure of what you are doing than drop the force (-f) and replace it with verbose (-v) or interactive (-i).

# rm -Rf somedir/

Adding static routes in Linux can be troublesome, but also absolutely necessary depending on your network configuration. I call static routes troublesome because they can often be the cause of long troubleshooting sessions wondering why one server can’t connect to another.

This is especially true when dealing with teams that may not fully understand or know the remote servers IP configuration.

The Default Route

Linux, like any other OS has a routing table that determines what is the next hop for every packet.

Print the routing table contents

There are numerous commands that show the routing table but today we will use the ip command as this command will be replacing the route command in future releases.

# ip route show
 10.1.6.0/26 dev eth0 proto kernel scope link src 10.1.6.21
 10.1.7.0/24 dev eth1 proto kernel scope link src 10.1.7.41
 default via 10.1.6.1 dev eth0

As you can see in the example routing table there are numerous routes however 1 route shows as the default route. This routing table tells the system that if the IP that is being communicated to does not fall into any of the other routes than send the packets to the default route defined as 10.1.6.1. The default route basically acts as a catchall for any packet that isn’t being told what to do in the above routes.

Our Example System

In today’s article I will be referencing an example network configuration in order to show how static routes are added, why to add them and some basic troubleshooting.

Example Interface Configuration

eth0:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=10.1.6.21
NETMASK=255.255.255.192
ONBOOT=yes

eth1:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
IPADDR=10.1.7.41
NETMASK=255.255.255.0
ONBOOT=yes

Example Default Route Configuration

# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=testing.example.com
GATEWAY=10.1.6.1

The GATEWAY configuration in /etc/sysconfig/network tells the system that 10.1.6.1 is the default route. This configuration could also be added to /etc/sysconfig/network-scripts/ifcfg-eth0 file; However if multiple ifcfg-<interface> files have a GATEWAY this may provide unexpected results as there can only be one default route.

Example Why we need a static route

For our example network configuration we have two interfaces; eth0 (10.1.6.21) for the internet, and eth1 (10.1.7.41) for the internal network. If we were to hook up to a backup server such as 10.1.5.202 we would want the connectivity to go through eth1 the internal network, rather than eth0 which is the internet network.

Since 10.1.5.202 is not in the same subnet at eth1 (10.1.7.0/24) the routing table does not automatically route the packet through eth1 and would then hit the “catchall” default route out eth0. To force all of our packets destined for 10.1.5.202 out eth1 we will need to set up a static route.

Adding a Static Route

Adding the route to the current routing table

Adding the static route is a fairly simple task however before we start we must first know the gateway for the internal network; for our example the gateway is 10.1.7.1.

Adding a single IP

# ip route add 10.1.5.202/32 via 10.1.7.1 dev eth1

The above command adds a route that tells the system to send all packets for 10.1.5.202 and only that IP to 10.1.7.1 from device eth1.

Adding a subnet of IP’s

In order to add a whole subnet than you will need to change the CIDR on the end of the IP. In this case I want to add anything in the 10.1.5.0 – 10.1.5.255 IP range. To do that I can specify the netmask of 255.255.255.0 in CIDR format (/24) at the end of the IP itself.

If a CIDR (or netmask) is not specified the route will default to a /32 (single ip) route.

# ip route add 10.1.5.0/24 via 10.1.7.1 dev eth1

The difference between these two routes is that the second will route anything between 10.1.5.0 and 10.1.5.255 out eth1 with 1 route command. This is useful if you need to communicate with multiple servers in a network and don’t want to manage lengthy routing tables.

Adding the route even after a network restart

While the commands above added the static route they are only in the routing table until either the server or network service is restarted. In order to add the route permanently the route can be added to the route-<interface> file.

# vi /etc/sysconfig/network-scripts/route-eth1

Append:

10.1.5.0/24 via 10.1.7.1 dev eth1

If the above configuration file does not already exist than simply create it and put only the route itself in the file (# comments are ok). When the interface is restarted next the system will add any valid route in the route-eth1 file to the routing table.

I highly suggest that when possible anytime you add a route to the route-<interface> files that the interface itself is restarted to validate whether the route is actually in place correctly or not. I have been on many late night calls where a static route was not added correctly to the configuration files and was removed on the next reboot, which is also long after everyone has forgotten that a static route was required.

Troubleshooting a Static Route

Check if the route is in the routing table

Before performing any deep down troubleshooting steps the easiest and first step should be to check if the routing table actually has the route you expect it to have.

# ip route show
 10.1.5.0/24 via 10.1.7.1 dev eth1
 10.1.6.0/26 dev eth0 proto kernel scope link src 10.1.6.21
 10.1.7.0/24 dev eth1 proto kernel scope link src 10.1.7.41
 default via 10.1.6.1 dev eth0

Use tcpdump to see tcp/ip communication

The easiest way that I have found to find out whether a static route is working correctly or not is to use tcpdump to look at the network communication. In our example above we were attempting to communicate to 10.1.5.202 through device eth1.

# tcpdump -qnnvvv -i eth1 host 10.1.5.202
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:50:35.880941 IP (tos 0x10, ttl 64, id 59563, offset 0, flags [DF], proto: TCP (6), length: 60) 10.1.7.41.41403 > 10.1.5.202.22: tcp 0
16:50:35.881266 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 10.1.5.202.22 > 10.1.7.41.41403: tcp 0

The above tcpdump command will only listen on eth1 and output only results that to or from 10.1.5.202.

TCP connections require communication from both the source and the destination, to validate a static route you can simply initiate a tcp connection (telnet to port 22 in this case) from the server with the static route to the destination server. In the output above you can see communication from 10.1.7.41 to 10.1.5.202 from the eth1 interface, this line alone shows that the static route is working correctly.

If the static route was incorrect or missing the tcpdump output would look similar to the following.

# tcpdump -qnnvvv -i eth1 host 10.1.5.202
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:50:35.881266 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 10.1.5.202.22500 > 10.1.7.41.22: tcp 0

In the above, only the target server is communicating over eth1.