Problem with spamlogd

2012-06-17 Thread Doug Hardie
I am using spamd on several systems and started encountering a problem awhile 
ago with FreeBSD 7.2 servers, but let it go since I am in the process of 
upgrading the servers.  However, I now am encountering the same issue on 
FreeBSD 9.0 with spamlogd.  It never reads pflog0.  pflogd reads the entries 
just fine.  I set up syslog to log all the spamlogd messages and when spamlogd 
is started it gives:

spamlogd: Listening on pflog0 for all interfaces. 

lsof shows that it is connected to bpf0 as is pflogd.  However, pflogd shows an 
offset into the file that appears to be the end of the file.  spamlogd shows an 
offset of 0.  It is periodically reading the file as shown by ktrace but always 
getting back a 0 size return.  spamd itself is working just fine.  However, the 
expiration times are not being updated so white entries are timed out way too 
often.  spamlogd used to update them.  The rc.conf entries are:

obspamd_enable=YES
obspamd_flags=-G 2:1:1728
obspamd_setup_flags=
obspamd_grey=YES
obspamlogd_enable=YES
obspamlogd_flags=-W 1728


These were established a few years ago and worked up till short while ago.  I 
don't recall any changes I made to anything, but…

Looking through the spamlogd source it appears to be building a filter for the 
pcap routines with:

ip and port 25 and action pass and tcp[13]0x12=0x2

Using that filter on pflog yields no output.  I believe the pass item requires 
there to be some logging of the pass actions and those are not appearing in the 
pflog or in the pfctl counts for those rules.  I suspect that is the problem.  
The pf.conf is: (mail server is on this machine)

ext_if=em0

table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist


no rdr on { lo0, lo1 } from any to any

no rdr on { lo0, lo1 } from any to any
MAILHOSTS = {zool.lafn.org 10.0.1.10}

rdr pass log on $ext_if inet proto tcp from spamd-white-local to port smtp - 
127.0.0.1 port smtp
rdr pass log on $ext_if inet proto tcp from spamd-white to port smtp - 
127.0.0.1 port smtp
rdr pass log on $ext_if inet proto tcp to $MAILHOSTS port smtp - 127.0.0.1 
port spamd


pass in on lo0

pass in log on $ext_if inet proto tcp to 127.0.0.1 port smtp
pass out log on $ext_if inet proto tcp from 127.0.0.1 to any port smtp

block in quick log on $ext_if from blackhole to any

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Problem with spamlogd

2012-06-17 Thread Matthew Seaman
On 17/06/2012 11:45, Doug Hardie wrote:
 I am using spamd on several systems and started encountering a problem awhile 
 ago with FreeBSD 7.2 servers, but let it go since I am in the process of 
 upgrading the servers.  However, I now am encountering the same issue on 
 FreeBSD 9.0 with spamlogd.  It never reads pflog0.  pflogd reads the entries 
 just fine.  I set up syslog to log all the spamlogd messages and when 
 spamlogd is started it gives:
 
 spamlogd: Listening on pflog0 for all interfaces. 
 
 lsof shows that it is connected to bpf0 as is pflogd.  However, pflogd shows 
 an offset into the file that appears to be the end of the file.  spamlogd 
 shows an offset of 0.  It is periodically reading the file as shown by ktrace 
 but always getting back a 0 size return.  spamd itself is working just fine.  
 However, the expiration times are not being updated so white entries are 
 timed out way too often.  spamlogd used to update them.  The rc.conf entries 
 are:
 
 obspamd_enable=YES
 obspamd_flags=-G 2:1:1728
 obspamd_setup_flags=
 obspamd_grey=YES
 obspamlogd_enable=YES
 obspamlogd_flags=-W 1728
 
 
 These were established a few years ago and worked up till short while ago.  I 
 don't recall any changes I made to anything, but…
 
 Looking through the spamlogd source it appears to be building a filter for 
 the pcap routines with:
 
 ip and port 25 and action pass and tcp[13]0x12=0x2
 
 Using that filter on pflog yields no output.  I believe the pass item 
 requires there to be some logging of the pass actions and those are not 
 appearing in the pflog or in the pfctl counts for those rules.  I suspect 
 that is the problem.  The pf.conf is: (mail server is on this machine)
 
 ext_if=em0
 
 table blackhole persist file /etc/blackhole
 table spamd persist
 table spamd-white persist
 table spamd-white-local persist file /etc/mail/whitelist
 
 
 no rdr on { lo0, lo1 } from any to any
 
 no rdr on { lo0, lo1 } from any to any
 MAILHOSTS = {zool.lafn.org 10.0.1.10}
 
 rdr pass log on $ext_if inet proto tcp from spamd-white-local to port smtp 
 - 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp from spamd-white to port smtp - 
 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp to $MAILHOSTS port smtp - 127.0.0.1 
 port spamd
 
 
 pass in on lo0
 
 pass in log on $ext_if inet proto tcp to 127.0.0.1 port smtp
 pass out log on $ext_if inet proto tcp from 127.0.0.1 to any port smtp
 
 block in quick log on $ext_if from blackhole to any

You seem to be logging all the SMTP traffic that passes through pf in
any direction.  Which doesn't make a lot of sense to me -- obspamlogd
will see the logged SMTP packets, assume that's valid traffic and add
the hosts to the whitelist.  Even if that's the incoming SYN packet from
some dubious mailer trying to inject you full of spam.

You should only log the SYN packets going out of your upstream (egress)
interface for obspamlogd -- that way it immediately whitelists anyone
you send email to, so they can reply without delay due to greylisting.

A good way of doing that is to log SMTP traffic to a separate log
device. eg:

pass log (to pflog1) on $ext_if proto tcp \
 from any to any port smtp\
 flags S/SA keep state

then in /etc/rc.conf, tell obspamlogd to use pflog1:

obspamlogd_enable=YES
obspamlogd_flags=-i em0
obspamlogd_pflog_if=pflog1

That way you can keep pflog0 for doing the normal packet logging that is
usual with pf -- typically, logging anything that gets dropped by the
firewall -- without getting obspamlogd confused.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW





signature.asc
Description: OpenPGP digital signature


Re: how to allow by MAC

2012-06-17 Thread Bill Yuan
On Wed, Jun 13, 2012 at 4:56 PM, Ian Smith smi...@nimnet.asn.au wrote:

 On Mon, 11 Jun 2012 15:18:18 -0700, Randal L. Schwartz wrote:
Bill == Bill Yuan byc...@gmail.com writes:
   Bill I want to create a white list MAC address,  Only the machine
 which it's MAC
   Bill in the white list will be allowed,  all others will be blocked.
  
   Bad idea.  Since (a) every MAC address that *is* allowed is transmitted
   in the clear and (b) it's trivial to spoof a MAC address.
  
   This. is. no. security.

 Indeed, that's right Randal.  But I got the impression from Bill's mails
 that this is more likely just something inside his internal network.

Filtering by MAC is not secure, I agree. but at least secure enough for a
internal network.
And I am quite sure what I want to archive. I am really want to know how to
FILTER BY MAC .




   Please stop even trying.

 Well I don't think learning how to use ipfw properly at layer2 is a bad
 idea in itself, and I wouldn't want to discourage anyone from that.

 For some years I ran a filtering transparent bridge with ipfw + dummynet
 for a small network of about 20 mostly W98, XP and Mac boxes sharing one
 slow ADSL gateway between various assorted community groups (talk about
 herding cats! :) and MAC filtering was one of the handiest tools when
 some box or other got owned (again!) by some virus and started spewing
 spam, provider complains and/or cuts access .. you know the deal.

 In that sort of environment, none of the punters had any clue about
 forging MACs or anything vaguely like that, and it stopped people
 randomly plugging boxes into the network.  Horses for courses.

 I replied in more detail to another from Bill privately, copy follows.

Thanks. I saw your email already .very helpful . I will continue to try in
that way . and share with all here in the feature.:)
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Problem with spamlogd

2012-06-17 Thread Doug Hardie

On 17 June 2012, at 06:29, Matthew Seaman wrote:

 On 17/06/2012 11:45, Doug Hardie wrote:
 I am using spamd on several systems and started encountering a problem 
 awhile ago with FreeBSD 7.2 servers, but let it go since I am in the process 
 of upgrading the servers.  However, I now am encountering the same issue on 
 FreeBSD 9.0 with spamlogd.  It never reads pflog0.  pflogd reads the entries 
 just fine.  I set up syslog to log all the spamlogd messages and when 
 spamlogd is started it gives:
 
 spamlogd: Listening on pflog0 for all interfaces. 
 
 lsof shows that it is connected to bpf0 as is pflogd.  However, pflogd shows 
 an offset into the file that appears to be the end of the file.  spamlogd 
 shows an offset of 0.  It is periodically reading the file as shown by 
 ktrace but always getting back a 0 size return.  spamd itself is working 
 just fine.  However, the expiration times are not being updated so white 
 entries are timed out way too often.  spamlogd used to update them.  The 
 rc.conf entries are:
 
 obspamd_enable=YES
 obspamd_flags=-G 2:1:1728
 obspamd_setup_flags=
 obspamd_grey=YES
 obspamlogd_enable=YES
 obspamlogd_flags=-W 1728
 
 
 These were established a few years ago and worked up till short while ago.  
 I don't recall any changes I made to anything, but…
 
 Looking through the spamlogd source it appears to be building a filter for 
 the pcap routines with:
 
 ip and port 25 and action pass and tcp[13]0x12=0x2
 
 Using that filter on pflog yields no output.  I believe the pass item 
 requires there to be some logging of the pass actions and those are not 
 appearing in the pflog or in the pfctl counts for those rules.  I suspect 
 that is the problem.  The pf.conf is: (mail server is on this machine)
 
 ext_if=em0
 
 table blackhole persist file /etc/blackhole
 table spamd persist
 table spamd-white persist
 table spamd-white-local persist file /etc/mail/whitelist
 
 
 no rdr on { lo0, lo1 } from any to any
 
 no rdr on { lo0, lo1 } from any to any
 MAILHOSTS = {zool.lafn.org 10.0.1.10}
 
 rdr pass log on $ext_if inet proto tcp from spamd-white-local to port smtp 
 - 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp from spamd-white to port smtp - 
 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp to $MAILHOSTS port smtp - 127.0.0.1 
 port spamd
 
 
 pass in on lo0
 
 pass in log on $ext_if inet proto tcp to 127.0.0.1 port smtp
 pass out log on $ext_if inet proto tcp from 127.0.0.1 to any port smtp
 
 block in quick log on $ext_if from blackhole to any
 
 You seem to be logging all the SMTP traffic that passes through pf in
 any direction.  Which doesn't make a lot of sense to me -- obspamlogd
 will see the logged SMTP packets, assume that's valid traffic and add
 the hosts to the whitelist.  Even if that's the incoming SYN packet from
 some dubious mailer trying to inject you full of spam.

Right now, I would like spamlogd to be a bit confused ;-)  However, its not 
seeing any of the logging.  It never receives any input from pflog0.  From the 
filter, the pass action indicates it won't look at any of the rdr logging 
(which is in the log) but is waiting for the pass rules to log something.  The 
tcp[13]0x12=0x2 item is the TCP SYN flag so it should be able to separate out 
what it wants from the log.  However, the pass rules are never being used and 
hence they never generate any log entries.  pfctl -vvsr shows all zeros for 
both of those rules.  

I understand that the pass rules are applied after the rdr rules but apparently 
I am getting the matching criteria wrong.  At this point switching them to a 
separate log stream won't help since it would never get anything logged to it.


 
 You should only log the SYN packets going out of your upstream (egress)
 interface for obspamlogd -- that way it immediately whitelists anyone
 you send email to, so they can reply without delay due to greylisting.
 
 A good way of doing that is to log SMTP traffic to a separate log
 device. eg:
 
 pass log (to pflog1) on $ext_if proto tcp \
 from any to any port smtp\
 flags S/SA keep state
 
 then in /etc/rc.conf, tell obspamlogd to use pflog1:
 
 obspamlogd_enable=YES
 obspamlogd_flags=-i em0
 obspamlogd_pflog_if=pflog1
 
 That way you can keep pflog0 for doing the normal packet logging that is
 usual with pf -- typically, logging anything that gets dropped by the
 firewall -- without getting obspamlogd confused.
 
   Cheers,
 
   Matthew
 
 -- 
 Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
 JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW
 
 
 

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: UEFI Secure Boot Specs - And some sanity

2012-06-17 Thread Wojciech Puchar

Any server manufacturer who chooses to only support MS products is
going to find they don't get much business from the academic market.


such behaviour is even more stupid today as globally PC market is 
shrinking.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Why Clang

2012-06-17 Thread Wojciech Puchar


Clang is consistently faster at compiling than GCC and it is very clean and 
modular -- not bloated.


-r-xr-xr-x  3 root  wheel  37025016 12 cze 21:46 /usr/bin/clang

well..


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: dumping file system subtree (/var)

2012-06-17 Thread Wojciech Puchar

alternatively - use tar.


What I was trying to achieve, which I haven't done yet, was a smallish dump of the 
core system.  By that I mean system + ports, without distfiles, etc.  Then a 
separate dump of user data, which is considerably larger.  At this point I am thinking I 
should do this:
 make clean distclean  ports to remove temporary stuff
 set /usr/home NODUMP
 dump /, /var, and /usr
 unset /usr/home NODUMP
 dump /usr/home


really - use tar.

dump is not for that, but to QUICKLY dump a filesystem.

on SSD - both are faster than writing to backup target disk.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Why Clang

2012-06-17 Thread Mark Blackman

On 17 Jun 2012, at 21:13, Wojciech Puchar wrote:

 
 Clang is consistently faster at compiling than GCC and it is very clean and 
 modular -- not bloated.
 
 -r-xr-xr-x  3 root  wheel  37025016 12 cze 21:46 /usr/bin/clang
 
 well..

hope you just left the debugging symbols in and statically linked it…

- Mark___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Problem with spamlogd

2012-06-17 Thread Doug Hardie
After many hundreds of tests, I have uncovered something that I never found in 
any of the pf documents or man pages.  If an incoming packet is processed by an 
rdr rule, it will always be logged as rdr with the rdr rule number.  The pass 
action is never logged, even if the rdr rule does not include log and the pass 
rule does.

As a result, since spamlogd is specifically looking for a pass action, it will 
never see those log entries.  Hence, you must ensure that the packets which do 
get sent to the mailserver (real one) never are processed by a rdr rule.  I 
ended up having to use no rdr rules for those to get the logging done such that 
spamlogd would find them:

no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass on $ext_if inet proto tcp to $MAILHOSTS port smtp - 127.0.0.1 port spa
md

pass in log on $ext_if inet proto tcp to $MAILHOSTS port smtp

This setup works on FreeBSD 7.2 and 9.0.  I couldn't find any other that 
actually worked including those in the various pf books, man pages, and other 
writings on pf.


On 17 June 2012, at 09:40, Doug Hardie wrote:

 
 On 17 June 2012, at 06:29, Matthew Seaman wrote:
 
 On 17/06/2012 11:45, Doug Hardie wrote:
 I am using spamd on several systems and started encountering a problem 
 awhile ago with FreeBSD 7.2 servers, but let it go since I am in the 
 process of upgrading the servers.  However, I now am encountering the same 
 issue on FreeBSD 9.0 with spamlogd.  It never reads pflog0.  pflogd reads 
 the entries just fine.  I set up syslog to log all the spamlogd messages 
 and when spamlogd is started it gives:
 
 spamlogd: Listening on pflog0 for all interfaces. 
 
 lsof shows that it is connected to bpf0 as is pflogd.  However, pflogd 
 shows an offset into the file that appears to be the end of the file.  
 spamlogd shows an offset of 0.  It is periodically reading the file as 
 shown by ktrace but always getting back a 0 size return.  spamd itself is 
 working just fine.  However, the expiration times are not being updated so 
 white entries are timed out way too often.  spamlogd used to update them.  
 The rc.conf entries are:
 
 obspamd_enable=YES
 obspamd_flags=-G 2:1:1728
 obspamd_setup_flags=
 obspamd_grey=YES
 obspamlogd_enable=YES
 obspamlogd_flags=-W 1728
 
 
 These were established a few years ago and worked up till short while ago.  
 I don't recall any changes I made to anything, but…
 
 Looking through the spamlogd source it appears to be building a filter for 
 the pcap routines with:
 
 ip and port 25 and action pass and tcp[13]0x12=0x2
 
 Using that filter on pflog yields no output.  I believe the pass item 
 requires there to be some logging of the pass actions and those are not 
 appearing in the pflog or in the pfctl counts for those rules.  I suspect 
 that is the problem.  The pf.conf is: (mail server is on this machine)
 
 ext_if=em0
 
 table blackhole persist file /etc/blackhole
 table spamd persist
 table spamd-white persist
 table spamd-white-local persist file /etc/mail/whitelist
 
 
 no rdr on { lo0, lo1 } from any to any
 
 no rdr on { lo0, lo1 } from any to any
 MAILHOSTS = {zool.lafn.org 10.0.1.10}
 
 rdr pass log on $ext_if inet proto tcp from spamd-white-local to port 
 smtp - 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp from spamd-white to port smtp - 
 127.0.0.1 port smtp
 rdr pass log on $ext_if inet proto tcp to $MAILHOSTS port smtp - 127.0.0.1 
 port spamd
 
 
 pass in on lo0
 
 pass in log on $ext_if inet proto tcp to 127.0.0.1 port smtp
 pass out log on $ext_if inet proto tcp from 127.0.0.1 to any port smtp
 
 block in quick log on $ext_if from blackhole to any
 
 You seem to be logging all the SMTP traffic that passes through pf in
 any direction.  Which doesn't make a lot of sense to me -- obspamlogd
 will see the logged SMTP packets, assume that's valid traffic and add
 the hosts to the whitelist.  Even if that's the incoming SYN packet from
 some dubious mailer trying to inject you full of spam.
 
 Right now, I would like spamlogd to be a bit confused ;-)  However, its not 
 seeing any of the logging.  It never receives any input from pflog0.  From 
 the filter, the pass action indicates it won't look at any of the rdr logging 
 (which is in the log) but is waiting for the pass rules to log something.  
 The tcp[13]0x12=0x2 item is the TCP SYN flag so it should be able to 
 separate out what it wants from the log.  However, the pass rules are never 
 being used and hence they never generate any log entries.  pfctl -vvsr shows 
 all zeros for both of those rules.  
 
 I understand that the pass rules are applied after the rdr rules but 
 apparently I am getting the matching criteria wrong.  At this point switching 
 them to a separate log stream won't help since it would never get anything 
 logged to it.
 
 
 
 You should only log the SYN packets going out of your upstream (egress)
 interface for obspamlogd -- that 

Re: Why Clang?

2012-06-17 Thread Thomas Mueller
What is the current status of Clang vs. GCC as default compiler for ports and 
for
make buildworld and make buildkernel in HEAD and 9.0-STABLE?

Now one concern is wine not working when Clang is used to make buildworld.

I see from reading the emailing lists that the intention is to make Clang the 
default (or only?) compiler suite for 10.0-RELEASE.

I realize that still leaves much time to work out many of the bugs.

Tom
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Why Clang?

2012-06-17 Thread Eitan Adler
On 17 June 2012 21:37, Thomas Mueller mueller...@insightbb.com wrote:
 What is the current status of Clang vs. GCC as default compiler for ports and 
 for
 make buildworld and make buildkernel in HEAD and 9.0-STABLE?

http://wiki.freebsd.org/PortsAndClang

 Now one concern is wine not working when Clang is used to make buildworld.

This isn't good. Can you please follow up with more debugging
information? (gdb backtrace with debugging symbols enabled)

 I see from reading the emailing lists that the intention is to make Clang the 
 default (or only?) compiler suite for 10.0-RELEASE.

Yes.

 I realize that still leaves much time to work out many of the bugs.

We need your help though.

-- 
Eitan Adler
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org