Mailing List Archive: Linux-HA: Users

Setting Source IP for outgoing traffic?

Index | Next | Previous | View Threaded

Timothy.Meader at gsfc

Oct 24, 2007, 7:55 PM

Post #1 of 5 (249 views)
Permalink

Setting Source IP for outgoing traffic?

Hello, I'm having an issue that I'm hoping someone could provide me
some help on. To give a brief synopsis of the situation:

We originally had a single server setup running OSSEC. Last week, we
decided to combine this server with another two that were running as
a simple log server (in high availability fail-over mode using
heartbeat) to make better use of the existing systems. The log server
portion is running on the virtual IP xxx.xxx.xxx.7 on eth0:0, the
OSSEC server is setup to run on a secondary virtual IP,
xxx.xxx.xxx.29, on eth0:1. When running on a single server, OSSEC
worked fine. But now, the clients refuse to communicate properly with
the server.

Using tcpdump, I tracked this communications problem down to the fact
that the server response from OSSEC in the high availability setup is
going back to the client with the ACTUAL address of eth0
(xxx.xxx.xxx.17 or 18 depending on which of the two high-avail nodes
it's currently running on). What I need is for the server response to
come back to the client with the xxx.xxx.xxx.29 address as the
source. I've investigated the "IPsrcaddr" script that comes with
heartbeat, but unfortunately there are two issues that preclude me
from using it, so I'm looking to iptables for a means to handle this.

Basically, I need the responses to any traffic coming in on UDP port
1514 (or, alternatively, to the destination IP x.29) to go back out
with a src address of x.29 instead of x.17 or x.18. Is there a method
using iptables that can handle this problem? Or barring that, can
anyone think of any other means to accomplish this task if iptables
can't handle this on its own? Below, I've included the current
iptables data rules that the two cluster nodes are presently sharing.

Thank you in advance for any and all replies up-front.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 720 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport
1514 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
5514 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
5140 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
8000:8001 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
8089 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

---
Tim Meader
L-3 Communications, NASA EOS Security Operations
Timothy.Meader[at]gsfc.nasa.gov
(301) 614-6371

_______________________________________________
Linux-HA mailing list
Linux-HA[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

dejanmm at fastmail

Oct 25, 2007, 3:45 AM

Post #2 of 5 (230 views)
Permalink

Re: Setting Source IP for outgoing traffic? [In reply to]

Hi,

On Wed, Oct 24, 2007 at 10:55:10PM -0400, Timothy Meader wrote:
> Hello, I'm having an issue that I'm hoping someone could provide me
> some help on. To give a brief synopsis of the situation:
>
> We originally had a single server setup running OSSEC. Last week, we
> decided to combine this server with another two that were running as
> a simple log server (in high availability fail-over mode using
> heartbeat) to make better use of the existing systems. The log server
> portion is running on the virtual IP xxx.xxx.xxx.7 on eth0:0, the
> OSSEC server is setup to run on a secondary virtual IP,
> xxx.xxx.xxx.29, on eth0:1. When running on a single server, OSSEC
> worked fine. But now, the clients refuse to communicate properly with
> the server.
>
> Using tcpdump, I tracked this communications problem down to the fact
> that the server response from OSSEC in the high availability setup is
> going back to the client with the ACTUAL address of eth0
> (xxx.xxx.xxx.17 or 18 depending on which of the two high-avail nodes

I think that I've seen this happen before. It actually violates
RFC recommendations (a SHOULD) for multihomed hosts. Normally,
the host should use a source address from the packet which was
used as the destination address. Is this Linux? Perhaps you
should complain on the networking list.

> it's currently running on). What I need is for the server response to
> come back to the client with the xxx.xxx.xxx.29 address as the
> source. I've investigated the "IPsrcaddr" script that comes with
> heartbeat, but unfortunately there are two issues that preclude me
> from using it, so I'm looking to iptables for a means to handle this.

Why is it that you cannot use it? Could it be modified to fit?

> Basically, I need the responses to any traffic coming in on UDP port
> 1514 (or, alternatively, to the destination IP x.29) to go back out
> with a src address of x.29 instead of x.17 or x.18. Is there a method
> using iptables that can handle this problem? Or barring that, can
> anyone think of any other means to accomplish this task if iptables
> can't handle this on its own? Below, I've included the current
> iptables data rules that the two cluster nodes are presently sharing.

It's definitely possible to mangle packets and replace the IP
address on all traffic matching udp and that port. There should
be some good howto docs or just try the man page. Sorry, not
exactly an expert on iptables, always have to read the
documentation.

Thanks,

Dejan

> Thank you in advance for any and all replies up-front.
>
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> -A RH-Firewall-1-INPUT -i lo -j ACCEPT
> -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
> -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
> -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
> -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 514 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 720 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport
> 1514 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
> 5514 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
> 5140 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
> 8000:8001 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
> 8089 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> COMMIT
>
> ---
> Tim Meader
> L-3 Communications, NASA EOS Security Operations
> Timothy.Meader[at]gsfc.nasa.gov
> (301) 614-6371
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Timothy.Meader at gsfc

Oct 25, 2007, 10:08 AM

Post #3 of 5 (224 views)
Permalink

Re: Setting Source IP for outgoing traffic? [In reply to]

>From: Dejan Muhamedagic <dejanmm[at]fastmail.fm>
>Subject: Re: [Linux-HA] Setting Source IP for outgoing traffic?
>To: General Linux-HA mailing list <linux-ha[at]lists.linux-ha.org>
>Message-ID: <20071025104536.GA7013[at]rondo.suse.de>
>Content-Type: text/plain; charset=us-ascii
>
>Hi,
>
>On Wed, Oct 24, 2007 at 10:55:10PM -0400, Timothy Meader wrote:
> > Hello, I'm having an issue that I'm hoping someone could provide me
> > some help on. To give a brief synopsis of the situation:
> >
> > We originally had a single server setup running OSSEC. Last week, we
> > decided to combine this server with another two that were running as
> > a simple log server (in high availability fail-over mode using
> > heartbeat) to make better use of the existing systems. The log server
> > portion is running on the virtual IP xxx.xxx.xxx.7 on eth0:0, the
> > OSSEC server is setup to run on a secondary virtual IP,
> > xxx.xxx.xxx.29, on eth0:1. When running on a single server, OSSEC
> > worked fine. But now, the clients refuse to communicate properly with
> > the server.
> >
> > Using tcpdump, I tracked this communications problem down to the fact
> > that the server response from OSSEC in the high availability setup is
> > going back to the client with the ACTUAL address of eth0
> > (xxx.xxx.xxx.17 or 18 depending on which of the two high-avail nodes
> > it's currently running on). What I need is for the server response to
> > come back to the client with the xxx.xxx.xxx.29 address as the
> > source. I've investigated the "IPsrcaddr" script that comes with
> > heartbeat, but unfortunately there are two issues that preclude me
> > from using it, so I'm looking to iptables for a means to handle this.
>
>Why is it that you cannot use it? Could it be modified to fit?
>*****************************************

Thanks for the reply. I've moved the OSSEC server to now use the same
virtual IP as the logging/NFS portion (x.x.x.7), so that hopefully
will make things slightly easier. This is doable presnetly because we
haven't deployed the OSSEC clients to any nodes outside our local
network yet, so it's relatively trivial for us at this stage to
change the OSSEC server address locally on each node's conf file. The
reason I can't use the IPsrcaddr script though (which I've seemingly
verified just now after testing), is that it doesn't seem to work for
any machines on the local subnet. We have about 20 nodes reporting in
to the OSSEC server currently, all on the same /26 range as the HA
server. For these machines, the following setup in the haresources
file doesn't seem to work properly (the traffic is still going out to
the clients on x.17 or x.18). Any further suggestions?

open-logger-1.my.domain IPaddr::xxx.xxx.xxx.7/26/eth0
IPsrcaddr::xxx.xxx.xxx.7 drbddisk::syslogs Filesystem::/dev/drbd0
::/log::ext3 syslog-ng portmap nfs nfslock ossec httpd

Thanks

---
Tim Meader
L-3 Communications, NASA EOS Security Operations
Timothy.Meader[at]gsfc.nasa.gov
(301) 614-6371

_______________________________________________
Linux-HA mailing list
Linux-HA[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

ckowarzik at email

Oct 31, 2007, 10:06 AM

Post #4 of 5 (210 views)
Permalink

Re: Setting Source IP for outgoing traffic? [In reply to]

Possibly the SNAT-Target from iptables can help you (read the man page).

If your server is answering on the same port that the clients send their
traffic to (UDP 1514) use:

iptables --table nat --insert POSTROUTING --protocol udp --source-port 1514
--out-interface eth0 --jump SNAT --to-source xxx.xxx.xxx.29

That will make the server sending any udp port 1514 traffic which
originates through eth0 from the specified ip address.

Christian

Timothy Meader schrieb:
> Hello, I'm having an issue that I'm hoping someone could provide me some
> help on. To give a brief synopsis of the situation:
>
> We originally had a single server setup running OSSEC. Last week, we
> decided to combine this server with another two that were running as a
> simple log server (in high availability fail-over mode using heartbeat)
> to make better use of the existing systems. The log server portion is
> running on the virtual IP xxx.xxx.xxx.7 on eth0:0, the OSSEC server is
> setup to run on a secondary virtual IP, xxx.xxx.xxx.29, on eth0:1. When
> running on a single server, OSSEC worked fine. But now, the clients
> refuse to communicate properly with the server.
>
> Using tcpdump, I tracked this communications problem down to the fact
> that the server response from OSSEC in the high availability setup is
> going back to the client with the ACTUAL address of eth0 (xxx.xxx.xxx.17
> or 18 depending on which of the two high-avail nodes it's currently
> running on). What I need is for the server response to come back to the
> client with the xxx.xxx.xxx.29 address as the source. I've investigated
> the "IPsrcaddr" script that comes with heartbeat, but unfortunately
> there are two issues that preclude me from using it, so I'm looking to
> iptables for a means to handle this.
>
> Basically, I need the responses to any traffic coming in on UDP port
> 1514 (or, alternatively, to the destination IP x.29) to go back out with
> a src address of x.29 instead of x.17 or x.18. Is there a method using
> iptables that can handle this problem? Or barring that, can anyone think
> of any other means to accomplish this task if iptables can't handle this
> on its own? Below, I've included the current iptables data rules that
> the two cluster nodes are presently sharing.
>
> Thank you in advance for any and all replies up-front.
>
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> -A RH-Firewall-1-INPUT -i lo -j ACCEPT
> -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
> -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
> -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
> -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 514 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 720 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 1514
> -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5514
> -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5140
> -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport
> 8000:8001 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8089
> -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> COMMIT
>
> ---
> Tim Meader
> L-3 Communications, NASA EOS Security Operations
> Timothy.Meader[at]gsfc.nasa.gov
> (301) 614-6371
> _______________________________________________
> Linux-HA mailing list
> Linux-HA[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

carson at taltos

Nov 1, 2007, 2:33 PM

Post #5 of 5 (202 views)
Permalink

Re: Setting Source IP for outgoing traffic? [In reply to]

Timothy Meader wrote:

> Thanks for the reply. I've moved the OSSEC server to now use the same
> virtual IP as the logging/NFS portion (x.x.x.7), so that hopefully will
> make things slightly easier. This is doable presnetly because we haven't
> deployed the OSSEC clients to any nodes outside our local network yet,
> so it's relatively trivial for us at this stage to change the OSSEC
> server address locally on each node's conf file. The reason I can't use
> the IPsrcaddr script though (which I've seemingly verified just now
> after testing), is that it doesn't seem to work for any machines on the
> local subnet. We have about 20 nodes reporting in to the OSSEC server
> currently, all on the same /26 range as the HA server. For these
> machines, the following setup in the haresources file doesn't seem to
> work properly (the traffic is still going out to the clients on x.17 or
> x.18). Any further suggestions?

The server you are running is broken. You need to fix it (or get
somebody else to fix it). Anything else you do is just a hack.

Or you could dump the product and get one written by people who
understand networking. InfoSec tools with broken network code terrify
me, as it's a sign of crappy programming which probably has other bugs.
OSSEC added to my "I don't ever want to run it" list...

--
Carson
_______________________________________________
Linux-HA mailing list
Linux-HA[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com