David's questions

This is very strange.

Output of ip route show:

default via 192.168.1.1 dev eth0 metric 100
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.11
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.58
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

From the firewall logs: (slightly shortened)

Mar 8 09:17:12 vmhost kernel: [ 562.808036] ''IN-dmz-lan-face':'IN=eth1 OUT= MAC=... SRC=192.168.1.108 DST=192.168.1.58 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28218 DF PROTO=TCP SPT=47365 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0

Notice the wacky discrepancy?

The firewall log lists eth1 at the address 192.168.1.58, but the routing table puts it at 192.168.1.10.

Somehow, eth1 and eth0 are getting swapped, or their ip addresses are.

There are no extra routing tables in play.

How can this happen? How can I fix it?

Edit (more info)

Output of ip addr | grep "inet ":

inet 127.0.0.1/8 scope host lo
inet 192.168.1.58/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1
inet 192.168.1.11/24 brd 192.168.1.255 scope global eth2
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0

Gateway 192.168.122.1 runs dns, and the command dig @192.168.122.1 www.google.com returns valid ip addresses, so dns is working and reachable.

The command tracepath www.google.com returns gethostbyname2: Host name lookup failure.

The command tracepath 74.125.129.103 (www.google.com) yields valid results, so the default route is set up correctly.

The command route -n outputs:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.122.1   0.0.0.0         UG    100    0        0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

And the applicable portion of /etc/network/interfaces reads:

auto eth0
iface eth0 inet static
    address 192.168.122.5
    netmask 255.255.255.0
    broadcast 192.168.122.255
    gateway 192.168.122.1
    dns-servers 192.168.122.1

No firewalls are currently running.

I would think, given these settings, that tracepath www.google.com would contact 192.168.122.1 for dns information, which is verified to be working and reachable.

What should I do next to find out why the tracepath command returns gethostbyname2: Host name lookup failure?

Edit (more info)

/etc/resolv.conf is empty. Ubuntu 12.04 uses a new subsystem, resolvconf, that autogenerates resolv.conf data in /etc/resolvconf/resolv.conf.d/*.

/etc/resolvconf/resolv.conf.d/original contains:

nameserver 192.168.122.1

All other resolv.conf.d files (head and base)are empty.

/etc/nsswitch.conf contains:

    passwd:         compat
    group:          compat
    shadow:         compat

    hosts:          files dns
    networks:       files

    protocols:      db files
    services:       db files
    ethers:         db files
    rpc:            db files

    netgroup:       nis

/etc/hosts contains:

    127.0.0.1       localhost
    127.0.1.1       hostname

    # The following lines are desirable for IPv6 capable hosts
    ::1     ip6-localhost ip6-loopback
    fe00::0 ip6-localnet
    ff00::0 ip6-mcastprefix
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters

I've got two linux servers in question. When one server initiates a request for a specific IP address that the other server has, I would like the initiating server to route the request back to itself on one of its own IP addresses.

How might this be done? Iptables? Iproute2? I'm a newbie to both and am somewhat confused by all their options. If either one can do it, I'd love to see examples of each so I can learn a little extra!

Running apache2 on Ubuntu 12.04, using mod-apparmor for change-hat support.

I have installed and verified that change-hat is working but that it is not working for externally included hats like the example hat provided for phpSysInfo by the mod-apparmor package.

I'm curious why this particular external include doesn't work, when other types of includes (ie: the "abstractions") are working. It's strange that the package maintainer set it up this way if it doesn't work.

The hat works fine if it is not provided as an "include", but is instead written directly into the apache2 profile.

The pertinent config file layout is like so:

/etc/
| apparmor.d/
| | apache2.d/
| | | phpsysinfo
| | usr.lib.apache2.mpm-prefork.apache2

And the hats are included in the apache profile like this, as provided by the package maintainer:

/usr/lib/apache2/mpm-prefork/apache2 flags=(complain) {
  #include <apache2.d>
}

With the hat file (apache2.d/phpsysinfo) looking like this:

^phpsysinfo {
  #include <abstractions/apache2-common>
  #include <abstractions/base>
  ...
}

I'm responsible for a server that serves a single service (ssh) over the internet via port-forwarding through a firewall.

The ssh service login is limited to encryption-key only (no passwords allowed).

Several times a week I see the following sort of firewall log (slightly obfuscated of course):

[UFW BLOCK] IN= OUT=eth0 SRC=192.168.x.x DST=211.224.108.50 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=29364 WINDOW=14600 RES=0x00 ACK SYN URGP=0

The source-port is always 22, and the destination IP is always something overseas (Korea, in this case) that appears to be malicious.

I've got the server fairly locked down, but I don't know enough about the SSH and TCP protocols to be confident, and I don't like the fact that it looks like my server is trying to contact a stranger. This sort of communication never happens during a legitimate ssh session.

Should I be concerned? Is there anything else strange about that log that my eyes haven't spotted?

Edit: I've tried a few simple things (like attempted password auth) to reproduce the blocked connection using an ssh client, with no success. Would be nice if I could reproduce it.