On 01/23/2013 02:09 PM, Jeff Boyce wrote:> Greetings -
>
> I have an interesting issue that I am trying to understand. This may
> not be a direct Samba related issue, but the results of the issue are
> showing up in the Samba log, so I thought I would start here. Please
> direct me elsewhere if there is a better forum for this question. I
> have spent some time Googling and have a small understanding of what
> is going on, but now my Google-fu is exhausted and I still don't have
> a complete understanding of the issue and whether I need to make some
> configuration changes in my network.
>
> Issue:
> I am seeing in my samba log file denied connections from IP addresses
> that are outside my network. Since I believe that I have my network
> firewalled and access adequately restricted from outside, I am trying
> to understand how the access attempts are only showing up in my Samba
> logs.
>
> /var/log/samba/samba.log
> [2013/01/22 21:24:34.477896, 0] lib/util_sock.c:1514(matchname)
> matchname: host name/address mismatch: ::ffff:14.132.17.44 !=
> 14-132-17-44.aichiwest1.commufa.jp
> [2013/01/22 21:24:34.479447, 0] lib/util_sock.c:1635(get_peer_name)
> Matchname failed on 14-132-17-44.aichiwest1.commufa.jp
> ::ffff:14.132.17.44
> [2013/01/22 21:24:34.479723, 0] lib/access.c:413(check_access)
> Denied connection from UNKNOWN (::ffff:14.132.17.44)
> [2013/01/22 21:24:34.479961, 1] smbd/process.c:2299(smbd_process)
> Connection denied from ::ffff:14.132.17.44
>
> Logwatch
> --------------------- samba Begin ------------------------ Connections
> Denied:
> smbd/process.c:2299(smbd_process) ::ffff:109.72.49.42 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:111.254.232.135 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:114.46.201.200 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:121.67.7.193 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:121.67.7.200 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:124.11.241.39 : 1 Time(s)
> smbd/process.c:2299(smbd_process) ::ffff:14.132.17.44 : 1 Time(s)
> ---------------------- samba End -------------------------
> Background & Network Information:
> 1. The server in which Samba is running (a KVM guest, CentOS 6) does
> have a public IP address.
> 2. The firewall rules on this server has ports open for SSH, OpenVPN,
> Webmin, and Samba. The bottom rule on the input chain deny's all.
> 3. On the Server: HostDeny = all, and HostAllow = 192.168.112
> (internal lan), 10.9.8. (OpenVPN lan), and loopback
> 4. Samba config: hosts allow = 127. 192.168.112. 10.9.8.
>
> What I think I understand at this point:
> 1. Google research indicates that the Host Name/Address mismatch
> portion of the log file refers to IPV6 name resolution not working.
> There are some suggestions for fixing that, but it isn't really the
> issue I am trying to understand.
> 2. The firewall may not be denying access to Samba because the Samba
> ports are open to make Samba available over our remote access.
>
Well, then you should configure the firewall for promiscuous mode and
dump all traffic to see if that is the case. I am assuming you are
doing that with iptables?
Then I would suggest you use wireshark or tcpdump or both and track it.
You can do this rather easily with tcpdump, if you do not have all of
the required infrastructure to run wireshark locallly on your firewall.
May I suggest something like tcpdump -n -i w1g1chdl -s 0 -w samba.txt
src or dst port 139, or the relevant port you wish to monitor.
After a while you can break out of tcpdump and load the session file
samba.txt into wireshark if you like for a more helpful view of things.
> What I don't understand:
> 1. If the Server OS configuration is restricting access to only the
> internal lan addresses and the OpenVPN lan addresses, then how are the
> access attempts from external addresses getting to Samba where they
> are being logged.
You also have to be aware, that virtual machine networks, can be
configured for bridging in certain ways that depending on the iptables
chain you create may or may not get too see the packet on the guest network.
This is particularly true if you choose to setup a route based network
segment vs a nat based one in libvirtd.
I suggest using only routed based network subnets for KVM as NAT on a
virtual machine network still can cause all sorts of silliness with
double or even triple NAT scenarios, which are vendor implementation
specific.
So if you are port forwarding to get to a guest on your KVM hypervisor,
do it only at your external firewall that is doing the NAT/holding the
port translation tables and try not to do it on the physical
hypervisor/kvm host. You need to make sure not to use anything but
forwarded/routed libvirtd configurations. In fact I would do that first,
just to get it to work, then convert to NAT if that is what you want.
I have no idea what your stuff is like on your network, but if you are
using CISCO router crap it might have proprietary ways not listed in the
RFC's for doing double NAT and what not that might work if you insist on
NAT's your guests on your hypervisor network (i.e. libvirtd configuration).
>
> If someone can give me some insight as to what is going on here I
> would appreciate it. Then I can figure out what I might need to
> change in my network or server. Thanks.
>
> Also, I am only receiving the Daily Digest of the mailing list, so
> would appreciate any responses CC'ing me directly also.
>
> Jeff Boyce
> Meridian Environmental
> www.meridianenv.com