pix syslog to linux box

What is the best way to config the pix to log messages to the syslog on a linux box. Does anyone have a link to a config, I want to have it setup like the experts.

tx

Reply to
R Siffredi
Loading thread data ...

In article , R Siffredi wrote: :What is the best way to config the pix to log messages to the syslog :on a linux box.

The main trick you need to know is that on Linux you may need to alter the options provided to your syslog daemon, in order to configure it to allow receipt from the PIX.

I have not used Linux, so I do not know the exact mechanism for doing this.

:Does anyone have a link to a config, I want to have it setup like the :experts.

I apologize that this is likely to come out sounding a bit rude, but your message suggests that you are not ready to have it set up "like the experts". The "experts" often build custom analysis or alert scripts in order to suit the demands of the particular environment -- and the technical skills involved in those customizations are such that anyone able to whip the customizations up would not have thought twice before reading the Linux syslogd man page or googling for previously posted information about linux pix syslog .

Reply to
Walter Roberson

You will need to set up a logging facility in syslog.conf to log your messages to a particular directory/file. If you look in your /etc/syslog.conf you will see something like;

# Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console

# Log anything (except mail) of level info or higher. # Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron,local0,local1,local2.none /var/log/messages

# The authpriv file has restricted access. authpriv.* /var/log/secure

# Log all the mail messages in one place. mail.* /var/log/maillog

# Log cron stuff cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log local7.* /var/log/boot.log

This defines what logging level will log to what file. So, decide on a logging facility and then create a directory and file that the logs will be written to and enter this info in the syslog.conf file;

# local1 (17) logging from customers equipment local1.* /var/log/routers/routers

So here I have created a file called routers in the directory /var/log/routers and I will log anything on local1 to this file. Retsart syslog.

On the pix set up the following;

logging on logging trap (warnings, notifications, errors etc..) logging facility (17 for local1) logging host inside (or outside!)

This will then trap any logs at the defined trap level and send them to the syslog server. The logging facility dictates what file the logs will be sent to depending on the configuration of syslog.conf.

How you manage these files is then up to you. I usually set up a cron job to switch the log files and keep the last seven.

Good luck.

Chris.

Reply to
Chris

Thanks a bunch Chris, this gets me started and I appreicate not being called lazy becasue I have researched this topic and didn't know where toget started. Can I have it setup to log like this debug - facility 17 critical - facility 15 info -- facilty and have it stored in different files. Or am I still thinking about the facility wrong?

Thanks again for the responce

R
Reply to
R Siffredi

As far as I know, you can't do that. You can only have one 'logging trap statment and everything at that level AND below will be logged. So, I usually have my firewalls logging to one logging facility that dumps the logs to /var/logs/firewall/pix and routers to another logging facility that dumps logs to /var/log/routers/router (for example).

If you have the logging trap level set too high then your logs will fill up very quickly and you will be swamped with bucket loads of logs that you might not need. So, under normal conditions I log at a low level, say error but if I'm monitoring a firewall or a router then I just change the loging level to something higher, say informational which will log everything below it as well.

I also identify the source of the log entry by having an entry in /etc/hosts so that the name of the device appears in the logs and then I run a cron job every hour to grep for all logs for a device and then write those to a seperate file so I can store all logs for one device for seven days. I log rotate those files once a day.

The logging levels are as follows (from cisco.com);

a.. Emergency. Generates syslog messages that identify system instabilities. a.. Alert. Generates syslog messages that identify system integrity issues that require immediate administrative action. Includes all Emergency messages. a.. Critical. Generates syslog messages that identify critical system issues. Includes all Emergency and Alert messages. a.. Error. Generates syslog messages that identify system errors during operation. Includes all Emergency, Alert, and Critical messages. a.. Warning. Generates syslog messages that identify system warnings, such as possible misconfigurations. Includes all Emergency, Alert, Critical, and Error messages. a.. Notification. Generates syslog messages that identify normal operations that are typically considered significant events. Includes all Emergency, Alert, Critical, Error, and Warning messages. a.. Information. Generates syslog messages that identify system information that is typical of day-to-day activity, such as network session records. Includes all Emergency, Alert, Critical, Error, Warning, and Notification messages. a.. Debugging. Generates syslog messages that assist you in debugging. It also generates logs that identify the commands issued during FTP sessions and the URLs requested during HTTP sessions. Includes all Emergency, Alert, Critical, Error, Warning, Notification, and Information messages

I normally have my trap level at error unless I want more information then I adjust it accordingly.

I hope that this is of some help.

Chris.

Reply to
Chris

In article , R Siffredi wrote: :Thanks a bunch Chris, this gets me started and I appreicate not being called lazy becasue I have researched this topic and didn't know where toget :started.

If anyone called you 'lazy' then it wasn't in this thread. In this thread, the comment that -was- made was that someone who wants to set something up "like the experts" needs a minimal technical expertise to draw on, and that a possessor of that expertise would have known "where to get started".

One of the functions of newsgroups is to assist in managing expectations: would it be professional or ethical for us to say "Yes, yes, it's easy to do" to someone whose questions indicated to us that it would not be easy for -them- to do it until they had more experience with the fundamentals ?

:Can I have it setup to log like this :debug - facility 17 :critical - facility 15 :info -- facilty : and have it stored in different files. Or am I still thinking about the facility wrong?

Chris's answer on this matter should be of assistance, but I will give a slightly different slant that should also help.

facility is intended as the primary distinguishing mark between different varieties of data sources. For example, everything about email might get logged with one facility, and everything about (say) system hardware problems might get logged with a different facility.

Any given syslog message sends along a facility -and- a "level". The "level" corresponds roughly to the priority. The lower the level, the higher the priority (e.g., level 1 might indicate critical problems, and level 6 might indicate be debugging information of interest only in obscure instances.) On the PIX, the number you give to the "logging trap" command corresponds to the maximum "level" (lowest priority) of message the PIX will send to syslog -- so for example, "logging trap 4" will allow the PIX to send syslog messages for items of priorities 1, 2, 3, or 4.

When you are configuring syslogd.conf, you can direct different priorities of messages to different files or services, and you can have the same message processed in several different ways. For example, you could have

local5.debug/var/adm/routerLOG

to mean that all messages with facility 'local5' (facility number 21) that are of priority 'debug' or higher (1 thru 6) be sent to the file /var/adm/routerLOG . You could also, in the same configuration file, have

local5.emerg|/usr/sbin/pager 555-1234

and if that were in there, then messages of facility 'local5' that were of priority 'emerg' or above would get sent to the program /usr/sbin/pager which would be passed the command-line argument 555-1234, hypothetically causing a pager message to phone number 555-1234 *in addition to* the logging done by the earlier statement.

You would normally configure the same (or similar) varieties of devices all with the same facility, as you would normally want the same kinds of things done for the same priorities of messages for each. Sometimes, though, you want to break things up further, by device -- for example, you might want to be woken up in the middle of the night for a problem with the company finance server, but a problem with the company Muzac server might not be worth high attention. You can have different treatment for different devices by sending the syslog message through a "filter". The syslogd man page has more information on how to configure filters. The details of how to efficiently code the filter itself are beyond the scope of this newsgroup .

Reply to
Walter Roberson

Good answer Walter. I might have another look at my syslog configuration and see if I can filter based on logging levels. I generally just log all levels to one file for a particular device (local.5.*) and then grep through the files to find what I am looking for but I might try your approach as well.

R Siffredi, I think that the message here is that once you know how syslog works ona Linux/Unix box and Cisco devices, how you actually manage your logging is entirely up to you and as you have seen is quite flexable.

Good luck.

Chris.

Reply to
Chris

In article , Chris wrote: :R Siffredi, I think that the message here is that once you know how syslog :works ona Linux/Unix box and Cisco devices, how you actually manage your :logging is entirely up to you and as you have seen is quite flexable.

And then there's the complications that the PIX offers mechanisms to alter the priority of messages away from the default... and also offers a different format of logging (more like IOS) by adding the 'log' keyword onto ACLs.

To use syslog "like the experts", one has to learn when to use each of these options and when not to. It's hard to know, though, what does or does not need to be explained to someone who does not know enough about systems administration to know where to start. Do we need to explain what a pipe is? What an environment variable is? How to write a shell script? How to compile a C program? How to write a C program? The basic constructs of programming? How to get perl? How to write programs in perl? How to process log files -efficiently- in perl? When to use perl and when to use C? How to write a parser? How to write a grammar? How to write a regular expression? The differences between what can be recognized by a DFA and what can be recognized by an LALR(1)? How to multiprocess? How DNS works? How to program a DNS call? How IP addressing works? How data *really* gets transmitted through IP? etwork byte order? Big-endian vs little-endian ?

Reply to
Walter Roberson

Chris napisa³(a):

If you really want to do this, you should separate log sources by IP

For example in syslog.conf :

+192.168.1.1 *.=critical /var/log/pix.critical *.=debug /var/log/pix.debug

etc.

But it depends on your syslog implementation, on my FreeBSD it works good.

*man syslog.conf*

regards jarcar

Reply to
jarcar

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.