The part of your /etc/syslog.conf that is putting the messages up on your console is
The syslog.conf manpage tells me that these entries consist of a facility
and a priority.
At present, your configuration is redundant and verbose; the first line says "all messages from daemons or mail", the next says "high-priority messages from news", the third and fourth say "all messages of priority debug, info, notice or warn", followed by "put them on the X console (your screen).
This set covers nearly all the sorts of messages that get put into the syslog. The only things that are not covered by this set of rules are of very high priority, but are rare: messages with priority err, crit, alert, or emerg from facilities other than daemon, mail, or news.
My personal taste would be to turn this configuration pretty nearly on its head, and display only
those rare messages that actually mean trouble on the console; there is a program called logwatch
which will run every night and e-mail you a digest of any other problems that have been logged in the last day.
Such an approach would eliminate most of the messages that you are seeing on your screen now.
Second, the four LOG rules that you found in your iptables configuration are set up to log various Internet attacks. The syslog priority is set to 6, which means they are crit(ical) in the view of the rule writer. The log messages will only be generated if the frequency of arrival is too high or a burst of 5 or more arrives at once.
Although such attacks can be debilitating, a properly-designed set of iptables rules will ward them off, and it is not clear what action you might take if you got the warning in real time anyway, because a really determined attack of this type is called a denial-of-service attack, since it swamps your Internet connection. Your only defense is to unplug the connection, which denies you access to the 'Net for any corrective action. Therefore, I would recommend just sending such messages to syslog, so that you will have a record of the IP address where such an attack originated. Once it is over, you can then send a complaint to email@example.com
, if the address can be resolved to the name of some ISP that you think might do something about the offender. In my experience, this is pretty uncommon. Often the source IP address is bogus, or does not resolve to a name at all, and if you try to trace the packet back, you will end up at a blank wall somewhere along the line.
Therefore, I would reduce the loglevel to 4 (info), and set up /etc/syslog.conf to put all such messages into the logfile (probably /var/log/messages).