Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Iptables and ipchains both use the "KERN" facility not "LOCAL#", iptables at loglevel "WARN", and ipchains at loglevel "INFO", so for ipt your line should be: "kern.warn<tab><logfile>".
Variations in loglevel are possible, or can be replaced by an asterix, depending on what you log, please consult the syslog(d|.conf) manual.
If you don't have a firewall, it can't log, right? :-]
Btw1, you commented out the "KERN" facility. IMO if you don't want that on your console, you can raise the loglevel to something like "EMERG", or have it log to a file. You never know when you'll need this.
Btw2, the "LOCAL#" facility is only used by apps that can use it by changing a var in their config, or at compile time.
OTOH if you mean syslogd should log messages from fw's from other machines you'll have to redirect them in the syslog.conf on that machine, and have syslogd listen on this machine on 514/UDP.
Thanks for all your time. I think I was unclear from the beginning. The firewall is hardware and its logging messages and should send them to my linux syslog server. I setup a windows syslog server as a test and it worked.
On the box you send syslog *from* specify a line
"*.*<tab>@hostname" (w/o quotes, change hostname).
On the *receiving* box you need syslog started with the "-r" flag so it will listen on UDP port 514 for messages from remote servers. This ain't on by default in distro's.
Also add the line "syslog 514/udp" (if its not there) to the /etc/services.
Shake the chicken bones 3 times, sprinkle with penny-royale oil, do some admin voodoo chants, and presto, remote logging...
Thanks unSpawn but i still have problems. Im logging from a cisco firewall. If i setup kiwi on my windows workstation it works great. Its not logging to my linux workstation. I have syslog udp/514 in the /etc/services. I have it running with the -r. Still nada.......
Both devices can ping each other/etc/
It just doesnt want to work.
Any ideas on how to debug?
How does your logging look in Config on the Cisco?
Should be something along the lines of:
logging <facility> (local0 to local7)
logging trap <logging_level> (? or like "informational">
logging source-interface <interface>
On the Linux box:
in /etc/syslog.conf add line with the logging facility specified on the Cisco:
Else; Not blocking from /etc/hosts.(deny|allow) from that address? Not blocking by fw? Does tcpdump show up anything from the Cisco address?
I added the *.* as show above and kernel messages showed up in my firewall.log. I did it as a test after touching the file to make sure syslog could write to it. hosts.allow and hosts.deny are both empty. /usr/sbin/tcpdump --> Cant read...Must be an executable or something. iptables/ipchains is not running.
What else am i suppossed to do? This should be working.
I start syslog via /etc/rc.d/init.d/syslog start -r
facility20 does equal local 4. Someone told me that its always offset by 16. ANyhow my kiwi syslog priority comes up as local4.notice........
Cant we eliminate the facility because i have entered *.* in my syslog.conf. Also im not running xinetd. Im not sure if some other process should be running.
So i think we can eliminate these:
1) facility ---> due to *.* in syslog.conf even though facility 20 is correct.
2) firewall.log --> This is writeable due to kernal messages showing up here due to *.* in syslog.conf.
Is there a way to test some more? Im not sure what else to do.
Thanks for everyones help.
Reading back I noticed you said you start syslog as "/etc/rc.d/init.d/syslog start -r". unless some wacky distro decides otherwise and mucked up SYSV stylee starting of daemons this can't be good, cuz I'm quite sure it won't pick up parameters on the cmdline else than start|stop|status and the like.
You will have to edit /etc/rc.d/init.d/syslog to add the "-r" parameter, then kill and start it.
Use netstat or socklist, and ps to verify its using UDP/514, and the flags include "-r" (ps ax).
Then I would like to suggest you try setting the Cisco facility line to specifically read anything starting with local like:
"logging facility local4".
Also note syslog *is* picky about tabs or spaces between the facility.priority and the logfile. Make sure your syslog.conf ends up with *all* tabs or *all* spaces, no mixing.
If this all won't work, and the kiwi box ain't the same IP as the Linux box, I would suggest you use tcpdump to see if the stream is there (w/o quotes):
"tcpdump -a -vv -i <interface> -p -c 1000 > tcpdump.log"
this will set the <interface> to promiscuous mode so itll receive all messages, log in ascii format with increased verbosity to the tcpdump.log and exit after 1000 packets are logged.
"cat tcpdump.log | grep -v "\^" | grep udp"
and it should show lines like
<timestamp> <cisco_address>.<port> > <linux_address>.514 udp <packet flags>.
If this works we definately know the error's on the syslog side, then we can opt to use logger(local) or netcat(remote) to test syslog further.
If this doesnt work, review your Cisco's conf (facility name and other logging options) or post the relevant logging lines here.