PIX's being what they are, I'd look into whether or not the PIX is permitting the syslog packets to actually leave the device, much less whether it's correctly configured to send. - billn On Tue, 3 Jan 2006, Andrew Meyer wrote:
Sorry, there must be some miscommunitcation, its just that I'm only seeing logs from one PIX come in, I figured it was many-to-one.
--- Bill Nash <billn@bacchus.billn.net> wrote:
Ok, I'm getting the sense that there's some unfamiliarity with general syslog implementation architectures and methods, so a brief primer.
Most syslog setups are a many-to-one style setup. For a given array of servers, routers, firewalls, bananas and/or oranges, a single syslog host is designated as the collection point. Once that is done, all devices that syslog is to be collected from are then configured individually to send their logs to the collection point.
The syslog server itself, once configured, normally accepts any syslog traffic you send to it, from any host. Different requirements and networks may dictate otherwise, but this is generally the case.
Each individual device must be configured to send it's traffic to the syslog server. I am unaware of any platform that is capable of automatically determining where it's logging should go, and sending it along accordingly.
Each PIX, each router, switch, orange, and banana will need to have a directive in their configuration that identifies the syslog server, and the related information involved in sending it along.
- billn
On Tue, 3 Jan 2006, Andrew Meyer wrote:
I have multiple PIXs', do i have to have a entry for each one of them? If so how do i do this?
--- Bill Nash <billn@bacchus.billn.net> wrote:
Inside a syslog packet, facility and severity get munged together for transport, and separated at reception time. They
get
broken out like this:
(these are from /usr/include/sys/syslog.h, for reference)
Severity: #define LOG_EMERG 0 /* system is unusable */ #define LOG_ALERT 1 /* action must be taken immediately */ #define LOG_CRIT 2 /* critical conditions */ #define LOG_ERR 3 /* error conditions */ #define LOG_WARNING 4 /* warning conditions */ #define LOG_NOTICE 5 /* normal but significant condition */ #define LOG_INFO 6 /* informational */ #define LOG_DEBUG 7 /* debug-level messages */
Facility: #define LOG_KERN (0<<3) /* kernel messages */ #define LOG_USER (1<<3) /* random user-level messages */ #define LOG_MAIL (2<<3) /* mail system */ #define LOG_DAEMON (3<<3) /* system daemons */ #define LOG_AUTH (4<<3) /* security/authorization messages */ #define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */ #define LOG_LPR (6<<3) /* line printer subsystem */ #define LOG_NEWS (7<<3) /* network news subsystem */ #define LOG_UUCP (8<<3) /* UUCP subsystem */ #define LOG_CRON (9<<3) /* clock daemon */ #define LOG_AUTHPRIV (10<<3) /* security/authorization messages #define LOG_FTP (11<<3) /* ftp daemon */ /* other codes through 15 reserved for system use */ #define LOG_LOCAL0 (16<<3) /* reserved for local use */ #define LOG_LOCAL1 (17<<3) /* reserved for local use */ #define LOG_LOCAL2 (18<<3) /* reserved for local use */ #define LOG_LOCAL3 (19<<3) /* reserved for local use */ #define LOG_LOCAL4 (20<<3) /* reserved for local use */ #define LOG_LOCAL5 (21<<3) /* reserved for local use */ #define LOG_LOCAL6 (22<<3) /* reserved for local use */ #define LOG_LOCAL7 (23<<3) /* reserved for local use */
These are the basis for translating the numeric syslog levels to human readable terms.
Since your guy set to facility 16, you should be referencing 'local0'. Alex notes this in his email, but doesn't enumerate it as explicitly.
- billn
On Fri, 30 Dec 2005, Andrew Meyer wrote:
Our network guy changed ti to facility logging level 16 so should i change the local # to 16 correct?
--- "SOLIS, ALEX" <asolis@oppd.com> wrote:
If you don't have too many assets to log from, I found that filtering by facility proved an effective logging method.
1. Setup your pix to send all its logs via a certain facility. For example local0. The pix command will look something like "logging facility 16". (note: Facilities have a corresponding ID in PIX IOS. Local0 starts at 16 and increments all the way to local7 which is 23.)
2. Setup the PIX to send its logs via UDP to the loghost server. Assuming Your loghost is on the inside of your PIX the command will look something like this: "logging host inside x.x.x.x". Be careful if you plan to use TCP for logging as the PIX will not allow communication between its interfaces if your syslog server fails!
3. Now modify the syslog-ng.conf file on you loghost with the appropriate destination, filter, and log statements. For example, to capture the PIX logs and send them to a private file we would have:
destination pix { file("/var/log/pix"); }; filter f_pix { facility(local0); }; log { source(src); filter(f_pix); destination(pix); };
restart syslog-ng and you should be in business. If you don't see enough information (or too much) play with the PIX's logging levels. There are 7 of them with 7 being the most verbose.
Hope that helps.
Alex
-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu
=== message truncated ===
I'm worth a million in prizes With my torture film Drive a GTO Wear a uniform On a government loan.
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html