2

I run a small network where a linux web/mail server also provides NAT for a collection of windows boxes. One of these windows machines is apparently misbehaving (ZeroAccess botnet even though I can't find any problems using Norton PowerEraser and have only been able to find 3 outgoing port 16465 packets in /var/syslog in weeks of logging). For some reason setting a firewall rule to drop all outgoing 16465 packets doesn't solve the problem, either, but that's an unrelated issue.

This issue is causing the mail server to be blacklisted with, for example, spamhaus.org. Since I can't find the infected windows host, I hit upon the idea of using IP aliasing to send the NAT traffic out through a different IP address.

External interface:

eth0:   216.82.212.230
eth0:1  72.48.103.182

Internal interface:

eth1:   172.18.90.1

In my firewall rules I then changed

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 216.82.212.230

to

iptables -t nat -A POSTROUTING -s 172.18.90.0/24 -o eth0 -j SNAT --to 72.48.103.182

The problem is now everything appears to be going out as 72.48.103.182, including traffic from the mail server. If I ssh from the firewall host to another external machine, the connection is identified as coming from 72.48.103.182.

This doesn't make sense to me as I'm specifically specifying the source IP's which are supposed to be NATed. Originally I tried the line above without "-s 172.18.90.0/24" and got exactly the same result.

Any thoughts on what is going on? I'm not an iptables expert by stretch of the imagination, but have made an effort to try and research this before posting to serverfault.

=======================

root@www:etc# ip ro
216.82.212.0/24 dev eth0  proto kernel  scope link  src 216.82.212.230
72.48.103.0/24 dev eth0  proto kernel  scope link  src 72.48.103.182
172.18.90.0/24 dev eth1  proto kernel  scope link  src 172.18.90.1
default via 216.82.212.254 dev eth0  src 72.48.103.182  metric 100
default via 216.82.212.254 dev eth0  metric 100
Improve this question
2
  • 1
    Show your ip ro output
    – poige
    Dec 15, 2013 at 21:56
  • See edited question above.
    – pgoetz
    Dec 16, 2013 at 0:44

2 Answers 2

Reset to default
3

The "magic" part is not the SNAT rule or the NAT table altogether, it is this routing table entry:

default via 216.82.212.254 dev eth0  src 72.48.103.182  metric 100

it is telling your kernel to use 72.48.103.182 for outbound locally-initiated connections (as long as the socket is not explicitly bound to a specific address upon creation) if the destination is reachable via this route - which would be the case for all "external" destinations as this is your default route. You should redefine it as

default via 216.82.212.254 dev eth0  src 216.82.212.230  metric 100

to get the expected behavior.

Improve this answer
4
  • Thanks for this. My ubuntu server install is setting up this route automatically somehow based on the /etc/network/interfaces file; now I just need to figure out how/why and what to do to fix it.
    – pgoetz
    Dec 16, 2013 at 3:37
  • @pgoetz The quick & dirty fix obviously would consist of ip route del default via 216.82.212.254 dev eth0 src 72.48.103.182 metric 100 && ip route add default via 216.82.212.254 dev eth0 src 216.82.212.230 metric 100. The startup route definition would probably be in the interfaces file but could indeed be elsewhere - e.g. in the hotplug daemon configuration.
    – the-wabbit
    Dec 16, 2013 at 8:54
  • I'm frustrated by how poorly I understand how the routing system works. In particular, I just ran the command suggested by poige below ip ro add default via 216.82.212.254 and that fixed the issue, even thought the errant route is still in place. In the interfaces file do I need to make the route commands part of some auto ethN stanza, or can they just stand alone anywhere in the file?
    – pgoetz
    Dec 16, 2013 at 10:03
  • @pgoetz ip route add by default would add with a metric of 0 - which means the route added would be a higher-priority route than the existing one with a metric of 100. Additionally, if you omit the src specification, the source IP address chosen would be the one of the interface facing the route (which is eth0 in your case) - this is why it works as a fix. I would expect to have the route added via an up option to an interface definition, but it really might be anywhere else, including a hotplug script or a separate startup script running on its own, depending on your configuration.
    – the-wabbit
    Dec 16, 2013 at 16:52
2

Ok, so I as thought — your server just uses this IP as outogoing one. Actually you don't need 2 default routes at all and it's even misleading. You have to use only one:

ip ro add default via 216.82.212.254

Alias you're using doesn't need to have special default route entry, since more than likely it's being routed back by your ISP using the primary link (address) of your interface.

Improve this answer
1
  • Yes, I agree. I had no idea this route was being set up. My Ubuntu server install is doing this automatically; I didn't/wouldn't have configured it this way, of course, but your initial question identified the problem.
    – pgoetz
    Dec 16, 2013 at 3:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .