On Fri, 26 Feb 2016, Pedro S wrote:
The proxy server will be a good external solution of course,
About OSSEC, maybe we need something like "reload", NOT restart, reload
could allow OSSEC to read again all the configuration files and refresh
internal structures, sure it won't be easy but.. just thinking.
Marginal gain over just a simple restart. And keep in mind this is a
one-off problem caused by using AWS as a hosting provider. The obvious
long-term solution is to go to a different hosting service that gives you
stable IP addresses.
Having said that there are still other solutions not as extreme. While
the AWS host may be required to use a dynamic IP there's nothing that
prevents the OP/VM owner from adding stable, private, SECONDARY (AKA
ALIAS) IP addresses on the same NICs, no gateway needed. The agents and
servers communicate using those addresses. You could probably even do
that using IPv6 SLAAC addresses as long as the NIC MAC isn't changing :).
The hosting provider may not even need to know about the secondary
network. This assumes of course that the agents and server sit on the
same network.
On Thursday, February 25, 2016 at 8:56:08 PM UTC+1, Antonio Querubin wrote:
On Thu, 25 Feb 2016, Barry Kaplan wrote:
Ok, is this something that would be considered for change? In our
environment there is no guarantee that nodes will remain on the same IP.
For this we use consul and dnsmasq to lookup DNS names.
For now I will hard code server_hostname to the DNS of the ossec server.
At
least that value exists when the agent starts. But when the ossec server
dies (AWS nodes die all the time) I will have update and restart every
agent.
I suspect this is impractical for performance reasons with the current
code. I'd recommend you find a way to proxy the server connection to the
real host to mask it's dynamic IP address change from the agents.
Antonio Querubin
e-mail: [email protected] <javascript:>
xmpp: [email protected] <javascript:>
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
Antonio Querubin
e-mail: [email protected]
xmpp: [email protected]
