Archive for the ‘Ossec’ Category

Why I use OSSEC

There are some great reasons to use OSSEC. One of them is you get emails like these I received this morning:

Jun 10 09:24:51 pukwudgie sshd[28651]: Failed password for invalid user pureftp from 202.121.49.62 port 45542 ssh2
Jun 10 09:24:48 pukwudgie sshd[28651]: Invalid user pureftp from 202.121.49.62
Jun 10 09:24:29 pukwudgie sshd[28630]: Failed password for invalid user tom from 202.121.49.62 port 37388 ssh2
Jun 10 09:24:28 pukwudgie sshd[28630]: Invalid user tom from 202.121.49.62
Jun 10 09:24:11 pukwudgie sshd[28628]: Failed password for invalid user peter from 202.121.49.62 port 57468 ssh2
Jun 10 09:24:09 pukwudgie sshd[28628]: Invalid user peter from 202.121.49.62
Jun 10 09:23:52 pukwudgie sshd[28610]: Failed password for invalid user thom from 202.121.49.62 port 49315 ssh2
Jun 10 09:26:39 pukwudgie sshd[28730]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62 user=root
Jun 10 09:25:43 pukwudgie sshd[28690]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62
Jun 10 09:25:24 pukwudgie sshd[28672]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62
Jun 10 09:25:05 pukwudgie sshd[28653]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62
Jun 10 09:24:48 pukwudgie sshd[28651]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62
Jun 10 09:24:28 pukwudgie sshd[28630]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62
Jun 10 09:24:09 pukwudgie sshd[28628]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.121.49.62Jun 10 09:44:08 pukwudgie sshd[29440]: pam_succeed_if(sshd:auth): error retrieving information about user recruit
Jun 10 09:44:46 pukwudgie sshd[29478]: pam_succeed_if(sshd:auth): error retrieving information about user office
Jun 10 09:45:25 pukwudgie sshd[29497]: pam_succeed_if(sshd:auth): error retrieving information about user tomcat
Jun 10 09:45:05 pukwudgie sshd[29480]: pam_succeed_if(sshd:auth): error retrieving information about user samba
Jun 10 09:45:42 pukwudgie sshd[29514]: pam_succeed_if(sshd:auth): error retrieving information about user webadmin
Jun 10 09:47:02 pukwudgie sshd[29555]: Failed password for invalid user spam from 202.121.49.62 port 45351 ssh2
Jun 10 09:46:59 pukwudgie sshd[29555]: Invalid user spam from 202.121.49.62
Jun 10 09:46:43 pukwudgie sshd[29538]: Failed password for invalid user ssh2 from 202.121.49.62 port 37198 ssh2
Jun 10 09:46:40 pukwudgie sshd[29538]: Invalid user ssh2 from 202.121.49.62
Jun 10 09:46:03 pukwudgie sshd[29518]: Failed password for invalid user jambo from 202.121.49.62 port 49116 ssh2
Jun 10 09:46:01 pukwudgie sshd[29518]: Invalid user jambo from 202.121.49.62
Jun 10 09:45:45 pukwudgie sshd[29514]: Failed password for invalid user webadmin from 202.121.49.62 port 40961 ssh2

Etcetera, etcetera…

Friday, June 10th, 2011

System Administration: Information

Probably 50% of a SysAdmin’s job revolves around information. Knowing what is going on with your systems can make all the difference. Just don’t make the mistake of thinking that the more information the better. What you really need is the *correct* information at the appropriate time and it shouldn’t be obfuscated by extra information.

Good info sources:
Use OSSEC and Nagios. These products will notify you about security issues and outages.

There is a child’s fable about the boy who cried wolf. To make a long story short, the boy made false alarms several times drawing attention until when he really saw a wolf, nobody would come. There is an important lesson in there about information too. After a while, if you are flooded with info you don’t need, you tend to stop paying attention and may miss something important.

The right stuff:
Make sure that you set up your source filters or rules well. Use your mail filters wisely and set them up as you go along to remove non essential notifications. And most importantly, read and pay attention to those alerts and notifications you get!

Wednesday, March 9th, 2011

Server Build

Last night on the TechShow I was asked about providing some info on a decent default server build. Here are some quick notes to get people going. Adjust as necessary.

Just for ease, here, lets assume you are installing CentOS 5, a nice robust enterprise class Linux for your server needs.

CentOS 5 / RHEL 5 / Scientific Linux, etc., does a really great job picking the defaults, so sticking with those is just fine and has worked well for me on literally hundreds of servers.

  • I let the partitioner remove all existing partitions and chose the default layout without modification.
  • Configure your networking appropriately, make sure to set your system clock for the appropriate timezone (no I do not generally leave my hardware clock set to UTC).
  • When picking general server packages I go for web server and software devel. I do not, generally, pick virtualization unless there is a specific reason to. I find that the web and devel meta server choices provide a robust background with all the tools I need to set up almost any kind of server I want without having to dredge for hundreds of packages later on.
  • The install itself at this point should take you about 15 minutes depending on the speed of your hardware.
  • Once installed, reboot the server and you should come to a setup agent prompt. Select the firewall configuration. Disable the firewall and SELinux completely (trust me here). Once that is done, exit the setup agent (no need to change anything else here), login to the machine as root and reboot it. This is necessary to completely disable SELinux.

From this point on it’s all post install config…:

  • Add any software repositories you need to.
    I not only have my own repo for custom applications, but also have a local RedHat repo for faster updates and lower network strain/congestion.
  • Install your firewall.
    I use an ingress and egress firewall built on iptables. While mine is a custom written app, there are several iptables firewall generator apps out there you can try.
  • Install your backup software.
    Doesn’t matter if this is a big company backup software like TSM or CommVault, or you are just using tar in a script. Make sure your system is not only being backed up regularly, but that you can actually restore data from those backups if you need to.
  • Add your local admin account(s).
    Don’t be an idiot and log into your server all the time as root. Make a local account and give yourself sudo access (and use it).
  • Fix your mail forwarding.
    Create a .forward file in your root directory and put your email address in there. You will get your servers root emails delivered to you so you can watch the logwatch reports and any cron results and errors. This is important sysadmin stuff to look at when it hits your inbox.
  • Stop unnecessary services.
    Yes, if you are running a server you can probably safely stop the bluetooth and cups services. Check through what you are running with a “service –status-all” or a “chkconfig –list” (according to your runlevel) and turn off / stop those services you are not and will not be using. This will go a long way toward securing your server as well.
  • Install OSSEC and configure it to email you alerts.
  • No root ssh.
    Change your /etc/ssh/sshd_config and set “PermitRootLogin no”. Remember, you just added an admin account for yourself, you don’t need to ssh into this thing as root anymore. Restart your sshd service after making the change in order to apply it.
  • Set runlevel 3 as default.
    You do not need to have a GUI desktop running on your server. Run the gui on your workstation and save your server resources for serving stuff. Make the change in /etc/inittab “id:3:initdefault:”.
  • Fix your syslog.
    You really should consider having a separate syslog server. They are easy to set up (hey, Splunk is FREE up to so much usage) and it makes keeping track of whats happening on multiple servers much easier (try that Splunk stuff – you’ll like it).
  • Set up NTPD.
    Your server needs to know what time it is. ‘Nuff said.
  • Install ClamAV.
    Hey, it’s free and it works. If you do ANYTHING at all with handling emails or fileshares for windows folks on this machine, you owe it to yourself and your users to run Clam on there to help keep them safer.
  • Do all your updates now.
    Before you go letting the world in on your new server, make sure to run all the available updates. No sense starting a new server instance with out of date and potentially dangerous software.
  • Lastly, update your logbook.
    You should have SOME mechanism for keeping track of server changes, whether it be on paper or in a wiki or whathaveyou. Use it RELIGIOUSLY. You will be glad someday you did.

Thursday, February 24th, 2011

Splunk + OSSEC

splunk

splunk


I have just started working with splunk a little bit and one of the things I have tried is to hook it up to OSSEC. This, like most things these days, has proven to be interesting to say the least. Actually, it’s a very simple process, however, the documentation is abysmal at best and I spent hours pouring through different websites until I found the correct potion to get things actually working they way they are supposed to. I am documenting it here for future reference. I am currently running OSSEC v2.4.x and Splunk v4.1.4:

On splunk:

Install ossec module into splunk

splunk->manager->data inputs->udp->new
udp port – 10002
set host – ip
source type – manual
source type – ossec
save

Make sure 10002 is enabled

On OSSEC:

vim /var/ossec/etc/ossec.conf
add:
<syslog_output>
<server>172.25.3.3</server>
<port>10002</port>
</syslog_output>
under global config

/var/ossec/bin/ossec-control enable client-syslog

service ossec restart

You should now start getting ossec alerts to splunk…!

Wednesday, July 21st, 2010

Ossec 2


Yessiree Bob.
Ossec has released v2. Go and grab it now. One of the really exciting new features it’s supposed to have is clientless monitoring. I can’t wait to try that out!

Most of you know that I run Ossec on a *lot* of systems. Almost every box I run at home and at work has Ossec on it. What I can say about Ossec is it does the job as advertised. It’s simply put, the best intrusion detection system for opensource out there. Period. Any sysadmin worth his/her salt should be running this, if for nothing else, just so you can sleep at night 🙂

Sunday, March 15th, 2009

Ossec insmod error

Let me preface this by saying that if you are not running Ossec on at least your external facing machines, then you should be. It’s great software!

The reason this post is here is for reference mostly and maybe to be able to help someone out later via their favorite search engine.

I have been getting a couple errors reported lately through Ossec emails that report: “insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg”. Well, after checking, the actual error is found in /var/log/messages and is “floppy.o: init_module: No such device”. AHA! Well, it just so happens that these machines are servers *with no floppy*. The fix for this to turn off the errors seems to be to add “alias floppy off” in the /etc/modules.conf file and then run a “depmod -a”.

Tuesday, October 21st, 2008