OSSEC server won't bind to 1514/UDP...

Eric Hansen

unread,

Mar 18, 2011, 10:20:08 AM3/18/11

to ossec...@googlegroups.com

First, I'd like to say that I've been doing a lot of Goggling around and tried a lot of things to no avail.

Error:

2011/03/18 09:46:34 ossec-logcollector: INFO: Started (pid: 5415).

2011/03/18 09:46:38 ossec-agentd(1218): ERROR: Unable to send message to server.

2011/03/18 09:46:44 ossec-syscheckd: Setting SCHED_BATCH returned: 0

2011/03/18 09:46:50 ossec-agentd(1218): ERROR: Unable to send message to server.

2011/03/18 09:46:51 ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: '192.168.1.103'.

uname -a

Linux s4u 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 18 16:58:42 UTC 2011 i686 AMD Sempron(tm) Processor 3100+ AuthenticAMD GNU/Linux

My flavor I'm running on both is Arch Linux.

I've uninstalled iptables on both the server and agent (wanted to see if this was causing any issues). I've also edited /etc/hosts.deny to comment out the ALL: ALL line, and add the ALL: ALL line to hosts.allow. I've done this for both agent and server, as well as opened up UDP port 1514 on my router/firewall to point to the server.

Here's my <remote> section in ossec.conf for the server:

<connection>secure</connection>

<!-- <port>1514</port>

<allowed-ips>19.168.1.101</allowed-ips>

<local_ip>192.168.1.103</local_ip> -->

</remote>

(I've also tried it with the lines not commented out and it still doesn't make a difference.

ossec-init.conf (server):

DIRECTORY="/var/ossec"

VERSION="v2.5.1"

DATE="Thu Mar 10 12:36:34 EST 2011"

TYPE="server"

-- The agent one specifies "agent" for type. --

In internal_options.conf, all the daemons have level 2 debugging and I set up ossec-control bash script to run each daemon with the -d flag for debugging.

When running cat /var/ossec/logs/ossec.log | grep remoted here's what I get:

2011/03/18 09:27:25 ossec-remoted: DEBUG: Starting ...

2011/03/18 09:27:25 ossec-remoted: INFO: Started (pid: 22933).

2011/03/18 09:27:25 ossec-remoted: DEBUG: Forking remoted: '0'.

2011/03/18 09:27:25 ossec-remoted: INFO: Started (pid: 22934).

2011/03/18 09:27:25 ossec-remoted: ERROR: Unable to create merged file: '/etc/shared/merged.mg'.

2011/03/18 09:27:25 ossec-remoted: DEBUG: Running manager_init

2011/03/18 09:27:26 ossec-remoted: INFO: (unix_domain) Maximum send buffer set to: '114688'.

2011/03/18 09:27:26 ossec-remoted(4111): INFO: Maximum number of agents allowed: '256'.

2011/03/18 09:27:26 ossec-remoted(1410): INFO: Reading authentication keys file.

2011/03/18 09:27:26 ossec-remoted: DEBUG: OS_StartCounter.

2011/03/18 09:27:26 ossec-remoted: OS_StartCounter: keysize: 1

Here's the output for netstat:

netstat -np

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 192.168.1.103:80 69.14.233.178:61774 FIN_WAIT2 -

tcp 0 0 192.168.1.103:80 69.14.233.178:61769 FIN_WAIT2 -

tcp 0 0 192.168.1.103:8018 69.14.233.178:42808 ESTABLISHED 22630/sshd: love [p

udp 0 0 192.168.1.103:2011 194.97.114.3:2010 ESTABLISHED 1005/ts3server_linu

udp 0 0 192.168.1.103:38894 194.97.114.3:2010 ESTABLISHED 1005/ts3server_linu

Active UNIX domain sockets (w/o servers)

Proto RefCnt Flags Type State I-Node PID/Program name Path

unix 7 [ ] DGRAM 3851 921/syslog-ng /dev/log

unix 6 [ ] DGRAM 2231128 16682/ossec-analysi /queue/ossec/queue

unix 2 [ ] DGRAM 2107 416/udevd @/org/kernel/udev/udevd

unix 3 [ ] DGRAM 2231117 16677/ossec-execd /var/ossec/queue/alerts/execq

unix 2 [ ] DGRAM 2375980 22635/su

unix 2 [ ] DGRAM 2375966 22634/sudo

unix 3 [ ] STREAM CONNECTED 2375942 22630/sshd: love [p

unix 3 [ ] STREAM CONNECTED 2375941 22632/0

unix 2 [ ] DGRAM 2231155 16700/ossec-monitor

unix 2 [ ] DGRAM 2231154 16682/ossec-analysi

unix 2 [ ] DGRAM 2231153 16682/ossec-analysi

unix 2 [ ] DGRAM 2231152 16686/ossec-logcoll

unix 2 [ ] DGRAM 2231151 16696/ossec-syschec

unix 2 [ ] DGRAM 2231150 16682/ossec-analysi

unix 2 [ ] DGRAM 2231149 16682/ossec-analysi

unix 2 [ ] DGRAM 2231129 16696/ossec-syschec

unix 2 [ ] DGRAM 2231124 16696/ossec-syschec

unix 2 [ ] DGRAM 31439 22660/nagios

unix 2 [ ] DGRAM 4579 1379/nmbd

unix 2 [ ] DGRAM 4499 1371/smbd

unix 2 [ ] DGRAM 4033 991/crond

unix 3 [ ] DGRAM 2120 416/udevd

unix 3 [ ] DGRAM 2119 416/udevd

When running ps, I get this:

ps aux | grep ossec

ossecm 22916 0.0 0.0 2056 440 ? S 09:27 0:00 /var/ossec/bin/ossec-maild -d

root 22920 0.0 0.0 1844 424 ? S 09:27 0:00 /var/ossec/bin/ossec-execd -d

ossec 22924 0.1 0.2 2820 1524 ? S 09:27 0:01 /var/ossec/bin/ossec-analysisd -d

root 22928 0.0 0.0 1920 432 ? S 09:27 0:00 /var/ossec/bin/ossec-logcollector -d

root 22939 1.1 0.1 2404 1216 ? S 09:27 0:12 /var/ossec/bin/ossec-syscheckd -d

ossec 22943 0.0 0.0 2048 456 ? S 09:27 0:00 /var/ossec/bin/ossec-monitord -d

root 23800 0.0 0.1 3972 824 pts/0 S+ 09:44 0:00 grep ossec

What I don't get is when I run /var/ossec/bin/ossec-control status, I get this: (service is a wrapper for init.d scripts in my bashrc)

# service ossec status

ossec-monitord is running...

ossec-logcollector is running...

ossec-remoted: Process 22934 not used by ossec, removing ..

ossec-remoted not running...

ossec-syscheckd is running...

ossec-analysisd is running...

ossec-maild is running...

ossec-execd is running...

I'm put up the logs on my server so it'll be easier to see: http://yli.no-ip.info/server.log & http://yli.no-ip.info/agent.log

Eric Hansen

unread,

Mar 18, 2011, 11:55:34 AM3/18/11

to ossec...@googlegroups.com

Also, I ran tcpdump on UDP/1514 and I do get traffic on the server:

00 [03/18/11 11:40:57 AM] - root# tcpdump -vv -i eth0 -A -s 0 udp port 1514

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:41:35.833808 IP (tos 0x0, ttl 64, id 11077, offset 0, flags [DF], proto UDP (17), length 101)

192.168.1.101.47492 > 192.168.1.103.fujitsu-dtcns: [udp sum ok] UDP, length 73

E..e+E@.@..&...e...g.....QLW:..hF.....`....*{{$|.&._I-.Y wC....m..*...j..~R....W...K.D.*.n#....)P.].1

11:41:41.834555 IP (tos 0x0, ttl 64, id 11078, offset 0, flags [DF], proto UDP (17), length 101)

192.168.1.101.47492 > 192.168.1.103.fujitsu-dtcns: [udp sum ok] UDP, length 73

:..|v5.U.....S..qJ....B\P.....Y&..N...r.r.Uu.-Q.tT.&...B..i U..LB{.@].qF.

11:41:51.834053 IP (tos 0x0, ttl 64, id 11079, offset 0, flags [DF], proto UDP (17), length 101)

192.168.1.101.47492 > 192.168.1.103.fujitsu-dtcns: [udp sum ok] UDP, length 73

E..e+G@.@..$...e...g.....Q..:.......%.....1.......Jf.....1a.%......2Yt./'C(...{.^...G.c.....M.^\.o~X.

11:42:00.836577 IP (tos 0x0, ttl 64, id 18580, offset 0, flags [DF], proto UDP (17), length 101)

192.168.1.101.48716 > 192.168.1.103.fujitsu-dtcns: [udp sum ok] UDP, length 73

E..eH.@.@.m....e...g.L...Q..:

..Y.o...G.DN.1`z..u.04....[.%..y.....).a.c..3?.

When your work speaks for itself, don’t interrupt.
– Henry J. Kaiser

Jason 'XenoPhage' Frisvold

unread,

Mar 18, 2011, 10:07:19 PM3/18/11

to ossec...@googlegroups.com

On Mar 18, 2011, at 10:20 AM, Eric Hansen wrote:
>
> First, I'd like to say that I've been doing a lot of Goggling around and tried a lot of things to no avail.

Did you register the client on the server using manage_agents? And did you then copy the key to the client and install it using manage_agent?

---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- Niven's Inverse of Clarke's Third Law

Eric Hansen

unread,

Mar 18, 2011, 11:43:22 PM3/18/11

to ossec...@googlegroups.com

That I did.

When your work speaks for itself, don’t interrupt.
– Henry J. Kaiser

Jason 'XenoPhage' Frisvold

unread,

Mar 21, 2011, 5:03:24 PM3/21/11

to ossec...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/18/2011 11:43 PM, Eric Hansen wrote:
> That I did.

Are you running selinux, perchance?

> When your work speaks for itself, don’t interrupt.
> – Henry J. Kaiser

- --
- ---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
- ---------------------------

"Any sufficiently advanced magic is indistinguishable from technology."

- - Niven's Inverse of Clarke's Third Law
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HvRsACgkQ8CjzPZyTUTR77gCgmg6Uq8qXva7lF2LnWZyZKAQv
DvEAoJkx7GX+MBehuQIJq/X60y4MYnnn
=zwM6
-----END PGP SIGNATURE-----

Eric Hansen

unread,

Mar 21, 2011, 5:29:17 PM3/21/11

to ossec...@googlegroups.com

Nah, I'm using Arch Linux which doesn't include anything beyond the
core files needed for Bash and Linux, and I really dislike (to put it
nicely) SELinux.

When your work speaks for itself, don’t interrupt.
– Henry J. Kaiser

Jason 'XenoPhage' Frisvold

unread,

Mar 22, 2011, 10:57:00 AM3/22/11

to ossec...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 05:29 PM, Eric Hansen wrote:
> Nah, I'm using Arch Linux which doesn't include anything beyond the
> core files needed for Bash and Linux, and I really dislike (to put it
> nicely) SELinux.

You know, if you want help, you're really going to have to have one of
the problems I'm describing so we can fix it.. ;)

Ok.. Let me re-iterate so I understand the problem.. Your server (not
agent) won't bind to port 1514/UDP. Is that correct?

The error you see in the logs : "ERROR: Unable to create merged file:
'/etc/shared/merged.mg'." is on the server, correct? What are the
permissions on the /etc/shared ... wait.. /etc/shared? Did you
relocate the ossec install? That should be /var/ossec/etc/shared ...
Where is OSSEC installed?

What are the permissions on the shared directory (wherever it is) ? It
appears that remoted isn't running, perhaps because of directory
permissions problems. On my install, the shared directory is owned by
ossec.ossec and has permissions of 770 .

- --
- ---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
- ---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- - Niven's Inverse of Clarke's Third Law
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IuLwACgkQ8CjzPZyTUTRpiQCeOtGypM3UaEKSbWEYNDL4kRCH
OOQAn2GfNN4vn6p90jsLdG4snjmNctzk
=/UMv
-----END PGP SIGNATURE-----

Eric Hansen

unread,

Mar 22, 2011, 11:10:30 PM3/22/11

to ossec...@googlegroups.com

Lol, the only thing I'm beginning to wonder is that Arch Linux, for one reason or another, isn't liking OSSEC. Correct, the server cannot bind to 1514/UDP (the agent has the port open just fine trying to connect to the server). My OSSEC is installed in /var/ossec, the default path. The shared is located in /var/ossec/etc/shared, and it's ossec:ossec w/ permission 770.

When your work speaks for itself, don’t interrupt.
– Henry J. Kaiser

jjennings

unread,

Mar 23, 2011, 7:46:30 AM3/23/11

to ossec...@googlegroups.com

I've noticed a few times each day that a machine running the agent causes a UDP flood to the OSSEC server.

any ideas why this might be happening. I know because my Juniper 5gt reports it. The agent machine is a very active webserver that does not contain any root kits nor has it been compromised in any way.

any ideas why this mihgt be happening.

a typical burst looks like this:

[00001] 2011-03-22 21:08:07 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 3 times.
[00002] 2011-03-22 21:08:06 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 1585 times.
[00003] 2011-03-22 21:08:05 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 2547 times.
[00004] 2011-03-22 21:08:04 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 4122 times.
[00005] 2011-03-22 21:08:03 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 2897 times.
[00006] 2011-03-22 21:08:02 [Root]system-alert-00012: UDP flood! From 192.168.1.42:35634 to nn.nn.241.39:1514, proto UDP (zone Trust, int trust). Occurred 2521 times.

Satish Patel

unread,

Mar 23, 2011, 9:03:25 AM3/23/11

to ossec...@googlegroups.com, <ossec-list@googlegroups.com>

What are the content of packet I meant. Port and inside data. Run tcpdump.

--

Sent from my iPhone

dan (ddp)

unread,

Mar 23, 2011, 9:19:18 AM3/23/11

to ossec...@googlegroups.com

Your thresholds are too low. That's probably just the agent sending
the logs to the manager.

Jason 'XenoPhage' Frisvold

unread,

Mar 23, 2011, 9:25:01 AM3/23/11

to ossec...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/22/2011 11:10 PM, Eric Hansen wrote:
> Lol, the only thing I'm beginning to wonder is that Arch Linux, for one
> reason or another, isn't liking OSSEC. Correct, the server cannot bind
> to 1514/UDP (the agent has the port open just fine trying to connect to
> the server). My OSSEC is installed in /var/ossec, the default path.
> The shared is located in /var/ossec/etc/shared, and it's ossec:ossec w/
> permission 770.

And the files within the shared directory are root:ossec with 770
permissions?

I'm not sure why Arch wouldn't like OSSEC.. I know arch has some
peculiar (at least to me) ways of doing things, but I thought that was
just my own unfamiliarity with the system. You used install.sh to set
up the server, yes?

- --
- ---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
- ---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- - Niven's Inverse of Clarke's Third Law
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J9K0ACgkQ8CjzPZyTUTRzCACgmoNCN1NQTH5zquIBw1EIt5DU
TwgAoJK4yVyYlfsVkPTPg/CMZhfSpzi5
=Y23S
-----END PGP SIGNATURE-----

jjennings

unread,

Mar 23, 2011, 9:34:59 AM3/23/11

to ossec...@googlegroups.com

the times this happens are consistent - thanks

jeff

Eric Hansen

unread,

Mar 23, 2011, 10:54:03 AM3/23/11

to ossec...@googlegroups.com

Yeaup; 770 with root:ossec, and I used install.sh to install OSSEC. I know I also can't install Safe Squid either on Arch Linux (it won't generate a full serial key), so I'm wondering if it just might be a lost cause. I can continue looking into it as well, but I'm not sure what else to do.

When your work speaks for itself, don’t interrupt.
– Henry J. Kaiser

Tanishk Lakhaani

unread,

Mar 24, 2011, 1:11:20 AM3/24/11

to ossec...@googlegroups.com

Hi jeff,
Times are consistent bcoz integrity checksum must have been fixed to run at a certain time in the ossec.conf file...that's why when it notices changes it notified the server and hence the flood.

Regards
Tanishk Lakhaani
Sent from BlackBerry® on Airtel

Jason 'XenoPhage' Frisvold

unread,

Mar 24, 2011, 2:05:57 PM3/24/11

to ossec...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/23/2011 10:54 AM, Eric Hansen wrote:
> Yeaup; 770 with root:ossec, and I used install.sh to install OSSEC. I
> know I also can't install Safe Squid either on Arch Linux (it won't
> generate a full serial key), so I'm wondering if it just might be a lost
> cause. I can continue looking into it as well, but I'm not sure what
> else to do.

I may have to install arch just to figure this out... I wish I had an
answer for you. Anyone else running Arch?

iEYEARECAAYFAk2LiAUACgkQ8CjzPZyTUTT0twCdEP0gqGW6ifXoZT0oXAkUtqHi
nRMAniD3byV+9t22R/bMDZnx4nOIGl/k
=GR7r
-----END PGP SIGNATURE-----

dan (ddp)

unread,

Mar 28, 2011, 3:14:04 PM3/28/11

to ossec...@googlegroups.com

Nope, but I'm considering it now.

Reply all

Reply to author

Forward