# How do I make FireHOL log less ?

## IvanYosifov

I am using FireHOL and my system log is filled with zillions of messages like:

 *Quote:*   

> 
> 
> Dec 21 20:01:07 gateway kernel: IN-internet:IN=ppp0 OUT= MAC= SRC=200.75.88.187 DST=195.97.5.193 \
> 
> 	LEN=78 TOS=0x00 PREC=0x00 TTL=111 ID=63816 PROTO=UDP SPT=34165 DPT=137 LEN=58 
> ...

 

From the FireHOL docs I gathered that  these are packets that did not match any rule and got implicitly dropped. However there is no mention in the docs as to how do I disable the logging of those packets. I really don't care about this info, and there are more important things that I want to show up in dmesg, not get flooded out by this log spam. Does anyone know how to disable the logging of such packets ?

----------

## LoDown

Google is your friend.  I found this page: http://firehol.sourceforge.net/commands.html#log.

I did not read it all, but scroll down the page until you get to the section about logging.  Hopefully this will answer your question.

----------

## IvanYosifov

I know of this page. Unfortunately, so far I have not managed to make any use of it.

I have FIREHOL_LOG_LEVEL="0" in /etc/firehol/firehol.conf which acording to this should suppress loging - it does not. I think the log comands/variables are used when rules defined by me want to log something, not with the "implicitly dropped" traffic that is getting logged.

----------

## LoDown

Ok, it looks like iptables (which FireHOL uses to filter packets) will log any packet that reaches the end of the chain without an explicit DROP  or ACCEPT.  So the solution at this times seems to be add rules to the end of all your chains ( I am assuming they are default drop) to DROP all the packets that traverse that far, that way none should get logged.

----------

## IvanYosifov

There is quite a number of chains ( most created by FireHOL ) and manually adding a rule to all of them seems like quite a lot of typing to me. Is there any way to automatically remove all rules with target LOG from iptables ?

----------

## IvanYosifov

But it turned out I can do this at FireHOL level.

I added "server all drop" to the end of the FireHOL interface deffinition, and this did the trick.

And SYN floods and such will still get logged.

The interface deffinition now looks like:

```

interface eth0 internet

        policy drop

        protection strong

        server "http  https  ssh  ICMP  ftp" accept

        client all accept

        server all drop

```

Thanks for the idea.  :Cool: 

----------

## IvanYosifov

I managed to sole this completely for me, and thought I'd post it.

First, the above solution of putting "server all drop" at the end of the FireHOL interface definition did not really solve it, FireHOL kept logging things that I did not really want to see, like bad _outgoing_ packets. 

The ultimate solution is to emerge ulogd ( a special logging daemon for the netfilter subsystem of the kernel ), add it to the boot runlevel and put 

```

FIREHOL_LOG_MODE=ULOG

```

in FireHOL.conf  :Very Happy:  Now ALL the firwall generated messages go to /var/log/ulogd.syslogemu and NOT to /var/log/messages or the dmesg.  :Cool:  Problem solved... this time ( I hope ) for real.

----------

## bonbons

Other way to fix this issue is to generate the IP-tables script with firehol, then save it (so it can be restored by /etc/init.d/iptables) and edit the iptables-rule-dump.

Just delete all the --log lines at end of each table.

This only works if you have no services that change port on each boot.

----------

## DNAspark99

I too, didn't want these in the main logfile, and found the easiest way to filter them out of /var/log/messages was to put them into their own file, since on occasion it can be helpful to diagnose various problems by seeing what is hitting the firewall:

/etc/syslog-ng/syslog-ng.conf :

```
destination firewall { file ("/var/log/firewall.log"); };

filter f_firewall { 

        match ("IN-") or

        match ("OUT-") or

        match ("PASS-") or

        match ("NEW TCP w/o SYN:") or

        match ("SYN FLOOD:");

};

log { source(src); filter(f_firewall); destination (firewall); };

filter f_messages { 

        not filter(f_firewall);

};

```

There's probably other conditions that won't catch these filters, but in basic operation, I havn't seen anything get by yet, so if it does, I want to see it in /var/log/messages first, then I'd add a 'match' rule to fit...

since size may be an issue after a while, I added the following to /etc/logrotate.d/syslog-ng:

```

/var/log/firewall.log {

    olddir /var/log/archive

    size=512M

    rotate 2

}

```

(/var/log/archive is a dir I've created for all my 'rotated' and compressed logs)

----------

