Re: spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-31 Thread Alex Johnson
Peter-

> My solution was this: Set up and OpenBSD box doing spamd plus any content 
> filtering
> during receipt to a world-facing SMTP server on the same box. Make that box 
> the
> publicly visible MX for the relevant domains, but set up the smtpd, postfix 
> or exim
> (whatever you fancy) configuration to forward to the mail server the domain's 
> users 
> will be using.
> 
> I vaguely rememeber possibly writing about the setup in some detail in a blog
> post, but I forget which one. If I haven't, it's possible I should write that 
> up.

I have a recollection of reading something along those lines in your blog some 
years
ago as well, and I suspect that latent memory is what gave me the idea. Perhaps
when I have some time I’ll do some more searching for that one.

-Alex

P.S. I should also say thanks for your writings. As someone who doesn’t do this
kind of thing as a regular profession, I’ve found your articles both
entertaining and highly informative over the years.

 
Alex Johnson
ax.john...@gmail.com




Re: spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-27 Thread Alex Johnson
Thank you for your insight. I believe you are exactly correct. I have
previously run OpenBSD as my router and spamd in the classic setup, so
that is my past experience base. I was hoping to use it in this situation
as just a proxy in front of the mail server, but that seems to be getting 
outside of the typical use case, so I’ll look at other
options/configuration.

Again, thank you for your time.
-Alex

Alex Johnson
ax.john...@gmail.com

(P.S. Just changed the e-mail registered on the list, so this is
the same Alex)


> On May 27, 2022, at 12:29 AM, Stuart Henderson  
> wrote:
> 
> On 2022-05-27, Arete  wrote:
>> I’m setting up spamd in front of a Postfix mail server, and am having
>> an issue with rdr-to rules not working the way I expect.
>> 
>> My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix &
>> Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1
>> running in a VirtualBox machine on the same Mac Mini, with bridged
>> networking enabled.
>> 
>> Postfix on the Mac Mini can receive mail just fine from the internet
>> through the firewall. The mini has the IP address 192.168.20.15.
>> OpenBSD is configured and running with spamd (greylisting enabled) in
>> the VM, with IP address 192.168.20.16 - pf.conf rules as follows:
> 
> So if I understand correctly you have
> 
> internet -> firewall -> 192.168.20.0/24
> 
> and in 192.168.20.0/24 you have
> 
> - firewall
> - vm running spamd 
> - machine running postfix
> 
> incoming packet flow is internet -> firewall -> spamd -> postfix, but
> as the source address is unchanged by rdr-to, return packet flow is
> postfix -> firewall -> internet, bypassing the spamd vm, so there is
> nothing to "untranslate" the rdr-to.
> 
> The classic spamd setup is where it's run on a firewall which is set as
> default gateway on the mail server. Alternatively it also works where the
> mail daemon is running directly on the machine running spamd.
> 
> To run the mail daemon on another machine in the same subnet _alongside_
> spamd, you need to provide a way to get the return packets back through
> the spamd machine; if the mail server was running OoenBSD you could
> probably do this with "pass in quick from !192.168.20.0/24 to port
> smtp reply-to 192.168.20.16". There might be a way to do this with the
> version of PF in MacOS but I couldn't say how.
> 
> To be honest what I would do in your situation is forget about spamd.
> You could use postfix with postscreen and enable "after-greeting" tests,
> which means that an unknown client must attempt a connection, get a
> temporary failure, and reconnect (which it can do straight away)
> before being able to send mail. Or you could use explicit greylisting
> software (e.g. postgrey, policyd) or spam-filtering software that can
> also do greylisting (rspamd can do this and is typically configured
> to skip greylisting on mail with a low spam-score, which significantly
> reduces the negative impact of greylisting).
> 
> 
> -- 
> Please keep replies on the mailing list.
> 



Re: spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-27 Thread nacelle

On Thu, 26 May 2022, Arete wrote:

My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix &
Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1
running in a VirtualBox machine on the same Mac Mini, with bridged
networking enabled.


insert obvious comment about OpenBSD's ability to run Postfix and Dovecot.


a connection is never made to the Postfix server on the host machine 
(192.168.20.15:25).


Sounds like a routing triangle.  The host machine should have its default 
gateway as 192.168.20.16 and not the internet firewall.  (for other 
protocols, you could NAT inbound requests to the .16 address, but this is 
smtp... you want the source IPs for spamd purposes, etc.)



I’m sure there’s something I’m missing, but I
haven’t been able to figure out what. Any insight is most appreciated.


tcpdump or wireshark are a good way to see requests and responses (or
lack thereof)


P.S. dmesg for the OpenBSD VM:


I suggest adjusting your virtual hardware for higher performance/lower 
overhead:



wd0 at pciide0 channel 0 drive 0: 


OpenBSD supports virtio-scsi, much faster than emulated IDE


em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 
08:00:27:a4:36:7c


OpenBSD supports virtio-net, which has lower overhead than a virtualized 
EM device.  You also get much higher throughput with the host



auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 1 int 21, 
ICH


I suggest removing the emulated sound card


Re: spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-27 Thread Stuart Henderson
On 2022-05-27, Arete  wrote:
> I’m setting up spamd in front of a Postfix mail server, and am having
> an issue with rdr-to rules not working the way I expect.
>
> My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix &
> Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1
> running in a VirtualBox machine on the same Mac Mini, with bridged
> networking enabled.
>
> Postfix on the Mac Mini can receive mail just fine from the internet
> through the firewall. The mini has the IP address 192.168.20.15.
> OpenBSD is configured and running with spamd (greylisting enabled) in
> the VM, with IP address 192.168.20.16 - pf.conf rules as follows:

So if I understand correctly you have

internet -> firewall -> 192.168.20.0/24

and in 192.168.20.0/24 you have

- firewall
- vm running spamd 
- machine running postfix

incoming packet flow is internet -> firewall -> spamd -> postfix, but
as the source address is unchanged by rdr-to, return packet flow is
postfix -> firewall -> internet, bypassing the spamd vm, so there is
nothing to "untranslate" the rdr-to.

The classic spamd setup is where it's run on a firewall which is set as
default gateway on the mail server. Alternatively it also works where the
mail daemon is running directly on the machine running spamd.

To run the mail daemon on another machine in the same subnet _alongside_
spamd, you need to provide a way to get the return packets back through
the spamd machine; if the mail server was running OoenBSD you could
probably do this with "pass in quick from !192.168.20.0/24 to port
smtp reply-to 192.168.20.16". There might be a way to do this with the
version of PF in MacOS but I couldn't say how.

To be honest what I would do in your situation is forget about spamd.
You could use postfix with postscreen and enable "after-greeting" tests,
which means that an unknown client must attempt a connection, get a
temporary failure, and reconnect (which it can do straight away)
before being able to send mail. Or you could use explicit greylisting
software (e.g. postgrey, policyd) or spam-filtering software that can
also do greylisting (rspamd can do this and is typically configured
to skip greylisting on mail with a low spam-score, which significantly
reduces the negative impact of greylisting).


-- 
Please keep replies on the mailing list.



spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-26 Thread Arete
Hello-

I’m setting up spamd in front of a Postfix mail server, and am having
an issue with rdr-to rules not working the way I expect.

My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix &
Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1
running in a VirtualBox machine on the same Mac Mini, with bridged
networking enabled.

Postfix on the Mac Mini can receive mail just fine from the internet
through the firewall. The mini has the IP address 192.168.20.15.
OpenBSD is configured and running with spamd (greylisting enabled) in
the VM, with IP address 192.168.20.16 - pf.conf rules as follows:

__ 
#macros
lan="192.168.10.0/24" 
kootenai = "192.168.20.15"
set skip on lo

#default deny
block log all

#allow ssh from lan
pass in proto tcp from $lan to port ssh

#allow outbound connections for package, updates, time etc
pass out proto { tcp udp } to port { 22 53 80 123 443 }

# allow pings outbound 
pass out inet proto icmp icmp-type { echoreq }

# rules for spamd(8) 
table  persist 
table  persist
table  persist file "/etc/mail/whitelist.txt" 
table  persist file "/etc/mail/nospamd"

#mail traffic goes to spamd by default 
pass in log on egress inetproto tcp from any to any port smtp \
 divert-to 127.0.0.1 port smtp

#send traffic to the mail server from our white lists & who've 
#passed greylisting 
pass in log on egress proto tcp from  to any port smtp \
   rdr-to $kootenai port smtp
pass in log on egress proto tcp from  to any port smtp \
   rdr-to $kootenai port smtp 
pass in log on egress proto tcp from  to any port smtp \
   rdr-to $kootenai port smtp

#allow smtp out 
pass out log on egress proto tcp to any port smtp



When I switch my firewall to forward SMTP to the OpenBSD VM
(192.168.20.16:25), I get the following behavior:

Connections from the internet to port 25 get through to the OpenBSD
machine, connecting to port 25. If the connecting IP is not in any
whitelists, it gets forwarded to spamd (divert-to) as expected, and
the IP address added to the spamd table and greylisted. If the
connecting IP is in a whitelist (localwhite, nospamd, spamd-white),
the relevant rdr-to rule gets matched, but a connection is never made
to the Postfix server on the host machine (192.168.20.15:25).

- I can telnet from the OpenBSD VM to port 25 on the host machine and
connect just fine.
- If I telnet from another machine on the local network to port 25 on
the OpenBSD VM, and the machine is not in a whitelist, I talk to
spamd as expected.
- If I telnet from another machine on the local network to port 25 on
the OpenBSD VM, and the machine is in a whitelist, I get a connection 
timeout. By monitoring the pflog0 interface, I can see the connection
coming in and matching the pass in rdr-to rule, and then going out
matching the pass out rule (last two rules in the above pf.conf). 
I can also see the incoming and outgoing connections while monitoring
the em0 interface.

I’m sure there’s something I’m missing, but I
haven’t been able to figure out what. Any insight is most appreciated.

Thanks!
-Alex


P.S. dmesg for the OpenBSD VM:

littlechief$ dmesg
OpenBSD 7.1 (GENERIC) #151: Mon Apr 11 18:57:52 MDT 2022
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 1073168384 (1023MB)
avail mem = 1036857344 (988MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfda00, SMBIOS rev. 2.5 @ 
0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz ("GenuineIntel" 686-class) 2.03 
GHz, 06-45-01
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,AVX2,INVPCID,MD_CLEAR,L1DF,MELTDOWN
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 999MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
"PNP0A03" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0x8000 0xe2000/0xd400
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel