OSSEC UDP Ports

[jplee3]

Hey guys,

I found something interesting in attempting to deploy OSSEC in agent/
server model. Not sure what the implications are here, but it seems
like 1514 isn't the only port OSSEC retains communication over (since
it's UDP I think?).

The firewall rules that I'm working with are very restrictive. And UDP
is also restricted. I requested that 1514 UDP be opened on both the
server and agents but still couldn't get OSSEC to communicate between
the agents/servers.

After running a tcpdump, I found this:

18:24:49.215025 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 93) 10.x.x.x.1514 > 216.x.x.x.43591: UDP, length 65


So it seems the server was sending a request to the destination where
the destination port is dynamic.


Is there something I'm missing here?

[Jeremy Rossi]

This is odd. I don't know the firewalls that you are using, but I am guessing they are not keeping a state table http://j.mp/78bHjA. This state table would be needed due to the dynamic ports selected OSSEC on the agent side of the connection.

OSSEC works by having the agent contacting the server on UDP port 1514 and the src port will be picked randomly.

Can you give me some more details on the firewall's used?

-Jeremy

[Lee Dilkie]

jplee3 wrote:
> Hey guys,

>
> After running a tcpdump, I found this:
>
> 18:24:49.215025 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 93) 10.x.x.x.1514 > 216.x.x.x.43591: UDP, length 65
>
>
> So it seems the server was sending a request to the destination where
> the destination port is dynamic.
>
>
> Is there something I'm missing here?
>

I can't say for certain, but in a client-server situation, it's
generally only the server that is listening on a known port. The client
generally doesn't bind and receives a port from the dynamic range. Is
this trace a packet from the server to the client, in essence, a reply?

[Jeremy Lee]

Good point. I asked about this when having them make the changes but I'm not sure if they even knew! But if that's all that's needed, I can have them look into it when we try rolling this out again across subnets. I think they may be using a mix of branded firewalls but I know at least Checkpoint is one.

[Michael Starks]

jplee3 wrote:
> Hey guys,
>
> I found something interesting in attempting to deploy OSSEC in agent/
> server model. Not sure what the implications are here, but it seems
> like 1514 isn't the only port OSSEC retains communication over (since
> it's UDP I think?).
>
> The firewall rules that I'm working with are very restrictive. And UDP
> is also restricted. I requested that 1514 UDP be opened on both the
> server and agents but still couldn't get OSSEC to communicate between
> the agents/servers.

I can confirm that only UDP/1514 is needed from the client to the server
(at least for a Cisco firewall). The client will initiate a connection
using an ephemeral port to 1514 on the server. At that point, the
firewall should allow the response.

[Anoop Perayil]

Observed that the server initiates a connection to the client when we restart Syscheck/Rootcheck on an agent like -
./agent_control -r -u 001

a tcpdump on the agent shows -
15:59:22.034966 IP x.x.x.x.1514 > x.x.x.x.48902: UDP, length 73

[dan (ddp)]

That makes sense. Thanks!

> --
>
> ---
> 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 ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.