Hi Timothy, I can't help you much with the iptables rules, but you could try using the "local_ip" option in the server config to specify the IP address for OSSEC to use (in your case the ip of eth0:1).
*example for ip 10.2.3.4: <remote> <local_ip>10.2.3.4</local_ip> </remote> http://www.ossec.net/main/manual/#remote_options As for OSSEC analyzing the dst ip of the incoming packet and using that for the reply, I will take a look into implementing that (for v1.5)... Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On 10/25/07, Timothy Meader <[EMAIL PROTECTED]> wrote: > > David, thanks for the reply. I've tried adding that line to my > iptables config (came up with a similar example after a web search), > but every time I do, I'm no longer able to startup IPtables due to an > error about "seems to have a -t table option" when I run > "/etc/init.d/iptables start". Admittedly, I don't know enough about > iptables syntax, but could you provide more explicit instruction on > WHERE to add that line? My actual /etc/sysconfig/iptables file is in > the message below (and my original message). Where in that file would > that line fit in? > > Thanks in advance. > > PS - I'd posted to the Linux-HA list as well for any possible help, > and one user stated that perhaps OSSEC isn't acting the way a program > should in order to run properly on a multi-homed system. They stated > that, in multi-homed cases, OSSEC should ideally be analyzing the > original dstip for packets it processes, and send all outgoing > responses with a matching srcip to avoid all this hassle. Is there > anyone that should be contacted to hopefully get OSSEC setup using > the proper behavior for HA or multi-homed systems? As it continues to > increase in popularity, I can see this only increasing as a problem. > > At 11:01 AM 10/25/2007, you wrote: > > >* PGP Signed by an unknown key: 10/25/07 at 11:01:29 > > > >Tim, > > I think you need to add a SNAT rule to use iptables for this. I'm > >not in a position to test this but I think something like this may > >work for you: > >-t nat -A POSTROUTING -o eth0 -p udp --dport 1514 -j SNAT --to > >xxx.xxx.xxx.29 > > The intent (as I said, I can't check this) is to add to the nat > >table a postrouting rule for udp output on eth0 to port 1514 that > >jumps to source network address translation setting the source > >address to be xxx.xxx.xxx.29. > > I hope that at least points you in the right direction. > > -David > > > >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. > > > > *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 > > > [EMAIL PROTECTED] > > > (301) 614-6371 > > > > > > >-- > >_______________________________________________ > >GPG (http://www.gnupg.org/) key available from: > >http://www.kayakero.net/per/david/ > > > >* Unknown Key > >* 0xF881874D (L) > > --- > Tim Meader > L-3 Communications, NASA EOS Security Operations > [EMAIL PROTECTED] > (301) 614-6371 > >
