Firewall - Reset, Drop. or Reject

[RWF]

In NodeWorx | Server | Firewall for TCP and UDP Drop Policies, there are 3-4 options.

Reset, Drop, Reject plus UDP has an additional Prohibit.

The setting now is at Drop, but which one is the best, and can anyone give me a description and benefits of one over another. Such description and help text is a good idea to include in your "?" help pop window.

Also when on "Drop", I receive approximately a thousand lines of "Packet Drop" notifications in my daily log email, which is already bloated by the obsolete "Succesfull email" logins, which I BTW also would like to know how to get rid off.

Thanks

[IWorx-Socheat]

The easier question first: to reduce your DROP logs, you'll need to edit /etc/apf/conf.apf and set DROP_LOG to 0.

I'll have to do a little more digging to determine the exact differences between the drop options, but here is the gist: DROP drops all packets, without returning any information to the destination. All the others are some form of REJECT, with different reject responses.

The TCP default is RESET, which is the same as REJECT, but sends back a TCP reset packet
The UDP default is RESET also, again REJECT, but this sends an icmp-port-unreachable packet.
PROHIBIT sends back an icmp-host-prohibited packet.
I believe the default for REJECT, if no '--reject-with' paramater is supplied is "icmp-port-unreachable", but I'll have to dig a little more to confirm.

Socheat

[RWF]

Thanks for that information.

Is that also the location where I can edit so I do not receive one million lines of successful email logins?

[IWorx-Socheat]

Are you referring to the email you receive from the logwatch script?

[RWF]

Yes that email

[IWorx-Socheat]

I believe the proper to place to edit that would be the logwatch config files.

/etc/log.d/conf/logwatch.conf
/etc/log.d/conf/logfiles
/etc/log.d/conf/services

I'm really not all that familiar with configuring logwatch, so I'm sorry that I can't be more help than that. :(

Socheat

[JayBaen]

RWF,

Look at this thread:

http://www.interworx.com/forums/showthread.php?t=485

I don't think it's anything we can fix until the next "version" (recompile, etc) for vpopmail is incorporated.

JB