Re: help with phishing email?
> - http://www.postfix.org/POSTSCREEN_README.html > > with that config and postscreen properly configured you block far more > than 90% of junk without risk false positives > > postscreen_dnsbl_threshold = 8 > postscreen_dnsbl_action = enforce > postscreen_greet_action = enforce > postscreen_dnsbl_sites = > dnsbl.sorbs.net=127.0.0.109 > dnsbl.sorbs.net=127.0.0.149 > zen.spamhaus.org=127.0.0.[10;11]8 > dnsbl.sorbs.net=127.0.0.57 > zen.spamhaus.org=127.0.0.[4..7]7 > b.barracudacentral.org=127.0.0.27 > zen.spamhaus.org=127.0.0.37 > dnsbl.inps.de=127.0.0.27 > hostkarma.junkemailfilter.com=127.0.0.24 > dnsbl.sorbs.net=127.0.0.74 > bl.spamcop.net=127.0.0.24 > bl.spameatingmonkey.net=127.0.0.[2;3]4 > dnsrbl.swinog.ch=127.0.0.34 > ix.dnsbl.manitu.net=127.0.0.24 > psbl.surriel.com=127.0.0.24 > bl.mailspike.net=127.0.0.[10;11;12]4 > bl.mailspike.net=127.0.0.24 > zen.spamhaus.org=127.0.0.23 > score.senderscore.com=127.0.4.[0..20]3 > bl.spamcannibal.org=127.0.0.23 > dnsbl.sorbs.net=127.0.0.63 > dnsbl.sorbs.net=127.0.0.82 > hostkarma.junkemailfilter.com=127.0.0.42 > dnsbl.sorbs.net=127.0.0.92 > dnsbl-1.uceprotect.net=127.0.0.22 > all.spamrats.com=127.0.0.382 > bl.nszones.com=127.0.0.[2;3]1 > dnsbl-2.uceprotect.net=127.0.0.21 > dnsbl.sorbs.net=127.0.0.21 > dnsbl.sorbs.net=127.0.0.41 > score.senderscore.com=127.0.4.[0..69]1 > dnsbl.sorbs.net=127.0.0.31 > hostkarma.junkemailfilter.com=127.0.1.21 > dnsbl.sorbs.net=127.0.0.151 > ips.backscatterer.org=127.0.0.21 > bl.nszones.com=127.0.0.5-1 > score.senderscore.com=127.0.4.[90..100]-1 > wl.mailspike.net=127.0.0.[18;19;20]-2 > hostkarma.junkemailfilter.com=127.0.0.1*-2 > ips.whitelisted.org=127.0.0.2*-2 > list.dnswl.org=127.0.[0..255].0*-2 > dnswl.inps.de=127.0.[0;1].[2..10]-2 > list.dnswl.org=127.0.[0..255].1-3 > list.dnswl.org=127.0.[0..255].2*-4 > list.dnswl.org=127.0.[0..255].3*-5 Now that I've had a chance to study this, and despite our history, I'd like to thank you Harald, for this useful information. I am sure that a number of other present are grateful too. This will bring peace to many an Inbox.
Re: help with phishing email?
> first: before you call me again a fascist just because i don't agree > with your opinions backed by 10 years professional mailadmin better > don't give half thought advises! > > Am 09.12.2017 um 03:50 schrieb Colony.three: > >> Also in /etc/postfix/main.cf add to smtpd_recipient_restrictions = >> ...reject_rbl_client zen.spamhaus.org >> >> this is a completly wrong and dangerous Oh? Why didn't you say anything three days ago when another member of this listserv recommended it, Harald?
Re: help with phishing email?
> I'm trying to decide the best way to detect something like this. > > https://pastebin.com/hCX9MWNg > > Looking at the raw headers and body it's pretty easy to tell this is a > spoof, but when it shows-up in an inbox, it looks pretty good. > > Something specific to Amazon (where this is purported to come from) > would be to check if their domain is in the From and Reply-To and at > least score that relatively high if it's not correct - but compared to > what? Maybe if From text contains amazon/i and from-address does not > end with amazon.com (for me in the US at least)? > > That feels forced. Does anyone have any suggestions to help me out on > this fine Friday? > > Thanks, > AJ You shouldn't have even received that. Consider setting up your email as per this guide: https://arstechnica.com/information-technology/2014/03/taking-e-mail-back-part-3-fortifying-your-box-against-spammers/ After 3 months, and two major failures setting up email (not to mention shattered self-worth), this article series is what finally got me spinning. Also in /etc/postfix/main.cf add to smtpd_recipient_restrictions = ...reject_rbl_client zen.spamhaus.org,
Re: Does This Look Right?
Am 05.12.2017 um 19:29 schrieb Colony.three: >> Am 05.12.2017 um 19:13 schrieb Colony.three: >> >>> On 12/05/2017 01:17 AM, Colony.three wrote: >>> >>> |Looks like it's doing what it's supposed to, but just >>> checking... What do you think it's supposed to be happening >>> below? Those are just normal hacking attempts from China to do >>> SMTP authentication to try to abuse your server by sending >>> spam through it. The warnings are normal when Postfix can't >>> look up a matching A record from the PTR record content -- >>> FCrDNS. This will cause the "unknown" in the Received header >>> and SA rule hit on RDNS_NONE if the connection makes it far >>> enough. | >>> >>> That is what I was hoping is going on. I have never done this before, >>> so wanted to check to make sure. >>> In my case I don't have control over my PTR record though, as my mail >>> servers are on a hosted OpenStack instance. I do though have DNSSEC, >>> DKIM, and DNAE working for my mail servers. I hope those help. >>> >>> what are you talking about and how is that related to SPAMASSASSIN >>> >>> if you don't have control about your PTR you can't setup a outbound >>> mailserver but THIS LIST IS ABOUT INBOUND SPAMFILTERING and i >>> doubt the >>> IP below is yours >> >> I see that you are in a -good- mood today, Harald >> ... sometimes you're not! >> >> you still missed to explain what this whole thread has to do with >> SPAMASSASSIN - guess why there are different mailing lists Oh I didn't miss to explain it. I just am not interested in a bickering contest with a fascist. I know that there's expertise in spam here and I suspected that this is what my log entries are about. Now confirmed by a human being.
Re: Does This Look Right?
Am 05.12.2017 um 19:13 schrieb Colony.three: >> On 12/05/2017 01:17 AM, Colony.three wrote: >> >>> Looks like it's doing what it's supposed to, but just checking... >>> >>> What do you think it's supposed to be happening below? Those are just >>> normal hacking attempts from China to do SMTP authentication to try to >>> abuse your server by sending spam through it. >>> >>> The warnings are normal when Postfix can't look up a matching A record >>> from the PTR record content -- FCrDNS. This will cause the >>> "unknown" in >>> the Received header and SA rule hit on RDNS_NONE if the connection >>> makes >>> it far enough. >> >> That is what I was hoping is going on. I have never done this before, >> so wanted to check to make sure. >> In my case I don't have control over my PTR record though, as my mail >> servers are on a hosted OpenStack instance. I do though have DNSSEC, >> DKIM, and DNAE working for my mail servers. I hope those help. >> >> what are you talking about and how is that related to SPAMASSASSIN >> >> if you don't have control about your PTR you can't setup a outbound >> mailserver but THIS LIST IS ABOUT INBOUND SPAMFILTERING and i doubt the >> IP below is yours I see that you are in a -good- mood today, Harald ... sometimes you're not!
Re: Does This Look Right?
On 12/05/2017 01:17 AM, Colony.three wrote: >> Looks like it's doing what it's supposed to, but just checking... >> >> What do you think it's supposed to be happening below? Those are just >> normal hacking attempts from China to do SMTP authentication to try to >> abuse your server by sending spam through it. >> >> The warnings are normal when Postfix can't look up a matching A record >> from the PTR record content -- FCrDNS. This will cause the "unknown" in >> the Received header and SA rule hit on RDNS_NONE if the connection makes >> it far enough. That is what I was hoping is going on. I have never done this before, so wanted to check to make sure. In my case I don't have control over my PTR record though, as my mail servers are on a hosted OpenStack instance. I do though have DNSSEC, DKIM, and DNAE working for my mail servers. I hope those help.
Does This Look Right?
Looks like it's doing what it's supposed to, but just checking... Dec 5 06:58:26 quantumn postfix/smtpd[51554]: lost connection after AUTH from unknown[110.83.135.178] Dec 5 06:58:26 quantumn postfix/smtpd[51554]: disconnect from unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2 Dec 5 06:58:26 quantumn postfix/smtpd[51554]: warning: hostname 178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 110.83.135.178: Name or service not known Dec 5 06:58:26 quantumn postfix/smtpd[51554]: connect from unknown[110.83.135.178] Dec 5 06:58:27 quantumn postfix/smtpd[51554]: lost connection after AUTH from unknown[110.83.135.178] Dec 5 06:58:27 quantumn postfix/smtpd[51554]: disconnect from unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2 Dec 5 06:58:27 quantumn postfix/smtpd[51554]: warning: hostname 178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 110.83.135.178: Name or service not known Dec 5 06:58:27 quantumn postfix/smtpd[51554]: connect from unknown[110.83.135.178] Dec 5 06:58:28 quantumn postfix/smtpd[51554]: lost connection after AUTH from unknown[110.83.135.178] Dec 5 06:58:28 quantumn postfix/smtpd[51554]: disconnect from unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2 Dec 5 06:58:28 quantumn postfix/smtpd[51554]: warning: hostname 178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 110.83.135.178: Name or service not known Dec 5 06:58:28 quantumn postfix/smtpd[51554]: connect from unknown[110.83.135.178] Dec 5 06:58:28 quantumn postfix/smtpd[51554]: lost connection after AUTH from unknown[110.83.135.178]
Re: spamd Will Not Create unix:socket
>> First, copy and paste lines from the log into a file called thing0.log where
>> thing is a mnemonic name for what you're trying to enable. In this example,
>> thing is smartd
>>
>> root# cd; mkdir selinux; cd selinux
>> root# cat > smartd0.log
>> type=AVC msg=audit(1425551687.181:491): avc: denied { getattr } for
>> pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
>> ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
>> tcontext=system_u:object_r:file_t:s0 tclass=file
>> type=AVC msg=audit(1425551687.181:492): avc: denied { execute } for
>> pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
>> ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
>> tcontext=system_u:object_r:file_t:s0 tclass=file
>>
>> Next, see what allowing this would look like
>>
>> root# audit2allow < smartd0.log
>> #= fsdaemon_t ==
>> allow fsdaemon_t file_t:file { getattr execute };
>>
>> Assuming this looks vaguely sane, generate a loadable module that will allow
>> the access
>>
>> root# audit2allow -M smartd0 < smartd0.log
>>
>> And then load that module, using the command it just told you (annoyingly,
>> this step takes on the order of 10s)
>>
>> root# semodule -i smartd0.pp
My God. It's full of stars!
This fixed the spamass-milter problem. And it seems to be the correct way to
fix the hundreds of other SELinux errors I have.
You take this box, and put it through a magic tunnel and see if it looks right.
If it does you put the box through another magic tunnel where it becomes a
robot. Then turn on the robot.
You don't need to know what the box really means nor what the magic tunnel
does. Even though it's retail (one-by-one), it does fix it permanently.
Thank you Toby.
Re: spamd Will Not Create unix:socket
>> On 11/27/2017 10:34 PM, Colony.three wrote: >> >>>> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin >>>> >>>> There's a root exploit for the "spamd" user in that last line. Assuming >>>> you got the tmpfiles.d thing working, you should delete those >>>> ExecStartPre commands. >>> >>> Can you explain further please? >>> If this is true, someone should tell Red Hat that their >>> /usr/lib/systemd/system/spamass-milter-root.service has the same problem. >>> >>> On 28.11.17 09:03, Michael Orlitzky wrote: >>> The "chown" command follows both symlinks and hardlinks by default. >>> >>> to be more precise, there is nothing like "following hard links" because >>> hard links are "the" files. >>> >>> When used with the "-R" flag, it only follows hardlinks, >>> >>> it recurses into /run/spamassassin, handling all files and directories >>> there, not following symlinks. >>> >>> but that can still >>> be abused by the "spamd" user. The first time "chown -R" gets executed, >>> you give ownership of /run/spamassassin to the "spamd" user. The second >>> (and third, ...) time that the service is started, the "spamd" user owns >>> that directory and can place a hard link in it pointing to a root-owned >>> file. The "chown" call will then give root's file to the "spamd" user. >>> >>> The simple workaround is to avoid the "-R" flag. in fact, we only need it >>> when we create /run/spamassassin so it gets owned by spamd. >>> >>> The exploit is trickier in this case because /run is on a tmpfs, and >>> because hard links can't cross filesystem boundaries. But I would bet >>> that you have something else sensitive in /run that can be used to gain >>> root. Interesting, thanks guys. I'd added the chown because I thought I needed it, but have now found that it's entirely unnecessary. (Someone should let RedHat know about their milter.service though -- I tried but can't get signed up for Bugzilla) FWIW here's what I think RedHat's spamassassin.service -should- look like. Works perfectly, unlike RedHat's version which does not create the socket directory, nor have Nice, nor security . [Unit] Description=Spamassassin daemon After=syslog.target network.target PartOf=spamassassin-update.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd # Create socket directory: RuntimeDirectory=spamassassin RuntimeDirectoryMode=770 ExecStart=/usr/bin/spamd --pidfile /run/spamassassin/spamd.pid $SPAMDOPTIONS Nice=5 StandardOutput=syslog StandardError=syslog Restart=always # Security PrivateTmp=yes InaccessibleDirectories=/bin /boot /home /media /mnt /opt /root /sbin /sys ReadOnlyDirectories=/lib /lib64 /usr CapabilityBoundingSet=~CAP_SYS_PTRACE DeviceAllow=/dev/null rw NoNewPrivileges=yes [Install] WantedBy=multi-user.target
Re: spamd Will Not Create unix:socket
On 27 Nov 2017, at 22:45 (-0500), Colony.three wrote:
>> Is anyone using the unix:socket for spamaassassin's milter?
>> When I turned on SELinux, it will not let me change the group of the
>> spamass-milter socket. (/run/spamass-milter/postfix/sock)
>> /var/log/messages
>> spamass-milter: group option, chown: Operation not permitted
>> G**gle's baffled how to set SELinux to fix this.
>>
>> The policycoreutils-python package, in particular its audit2why and
>> audit2allow tools, are indispensable for diagnosing and solving SELinux
>> issues. A particular advantage they have over Google, Bing, or
>> StackOverflow is that they are designed specifically to diagnose and
>> solve SELinux problems and they work really fast...
audit2why -a gives just a haystack of problems, none of which reference
specific files, and all of which seem to be hysterics. I have so many things
to do that I can never learn SELinux coherently, and usually end up turning it
off. I've asked on IRC and can't get the hang of it, and I've searched for
appropriate commands to exhaustion. And I know there are thousands like me.
I am really trying to not turn off SELinux with this server, and only have this
one showstopper error. But I don't know what to do with this gibberish:
type=AVC msg=audit(1511826731.712:227): avc: denied { dac_override } for
pid=1615 comm="spamass-milter" capability=1
scontext=system_u:system_r:spamass_milter_t:s0
tcontext=system_u:system_r:spamass_milter_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow
this access.
Ch-yea, sure, I'll get right on that...
Re: spamd Will Not Create unix:socket
Is anyone using the unix:socket for spamaassassin's milter? When I turned on SELinux, it will not let me change the group of the spamass-milter socket. (/run/spamass-milter/postfix/sock) /var/log/messages spamass-milter: group option, chown: Operation not permitted G**gle's baffled how to set SELinux to fix this.
Re: spamd Will Not Create unix:socket
On 11/27/2017 11:53 AM, Colony.three wrote: >> It simply would not create /run/spamassassin directory on boot. It is >> supposed to create it automatically like clamd does, since /run is wiped >> at each boot. To make it work I finally had to add: >> ExecStartPre=/usr/bin/mkdir /run/spamassassin >> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin > > There's a root exploit for the "spamd" user in that last line. Assuming > you got the tmpfiles.d thing working, you should delete those > ExecStartPre commands. Can you explain further please? If this is true, someone should tell Red Hat that their /usr/lib/systemd/system/spamass-milter-root.service has the same problem. I need spamass-milter-root to be able to write to the spamassassin socket so it can communicate with spamd. Recommendations requested. PS - I'm not using tmpfiles.d, I'm using systemd's RuntimeDirectory=spamassassin RuntimeDirectoryMode=770 ... to create the /run directory.
Re: RHEL7: spamass-milter-postfix==>spamassassin
> Am 27.11.2017 um 19:37 schrieb Colony.three: > >> Yes spamass-milter-postfix(root) is running fine, again you >> underestimate me Harald. >> So it is postfix==>milter==>spamassassin. But my actual question here >> is how does that last connexion get made? >> >> as i showed you >> >> /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g >> sa-milt -r 8.0 -i 10.0.0.0/24 -- -s 10485760 >> --socket=/run/spamassassin/spamassassin.sock --connect-retries=10 >> >> -p socket: path to create socket (the milter socket postfix connects to) >> -- spamc args: pass the remaining flags to spamc >> --socket (the spamd scoket the milter connects to) Ah, I've finally seen that stray '--' which differentiates the spamass-milter command from the spamc command. Thank you Harald, that helps alot. I guess by default spamass-milter tries to communicate on the tcp:socket using spamc. I wonder how many hundreds of sysadmins have gotten killed by that one, without knowing why?
Re: RHEL7: spamass-milter-postfix==>spamassassin
Yes spamass-milter-postfix(root) is running fine, again you underestimate me Harald. And now that I've determined a bug in the spamasassin.service file, that is running fine too, with the addition of RuntimeDirectory=spamassassin RuntimeDirectoryMode=770 ... which actually creates the -missing- socket directory. You are explaining that I need to set up the milter, although I actually need that -and- milter-postfix. These are set up fine, and are listening for postfix connections on the milter socket. So it is postfix==>milter==>spamassassin. But my actual question here is how does that *last* connexion get made? How does the milter communicate with spamassassin? Again, I gather that it's through spamc, but I'd like to understand the exact mechanism, to be sure it's functional. Client/server? Ok, is there anything else I need to set up or monitor? > Original Message > Subject: Re: RHEL7: spamass-milter-postfix==>spamassassin > Local Time: November 27, 2017 9:31 AM > UTC Time: November 27, 2017 5:31 PM > From: h.rei...@thelounge.net > To: Colony.three > > Am 27.11.2017 um 18:28 schrieb Colony.three: > >> Yes I've done this, but the question is how does the milter communicate >> with SA? >> >> spamass-milter --help >> man spamass-milter >> >> /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g >> sa-milt -r 8.0 -i 10.0.0.0/24 -- -s 10485760 >> --socket=/run/spamassassin/spamassassin.sock --connect-retries=10 >> >> and yes in doubt you clone the sysetmd unit to >> /etc/systemd/system/spamass-milter.service >> >> disable and stop the running service before, systemctl enable will then >> pick your override file >> >>> Original Message >>> Subject: Re: RHEL7: spamass-milter-postfix==>spamassassin >>> Local Time: November 27, 2017 9:13 AM >>> UTC Time: November 27, 2017 5:13 PM >>> From: h.rei...@thelounge.net >>> To: Colony.three colony.th...@protonmail.ch, >>> users@spamassassin.apache.org users@spamassassin.apache.org >>> Am 27.11.2017 um 17:58 schrieb Colony.three: >>> >>> Anyone know how spamass-milter-postfix communicates with spamassassin? >>> There's a postfix socket, but no setting AFAICT for the milter to >>> reach >>> SA. I gather that the mechanism may be through clamc, but I have no >>> proof that this is actually the case. >>> It seems that everyone is resigned to leaving spamassassin on a >>> tcp:port, which I don/t like for security reasons >>> >>> usermod -a -G sa-milt postfix
Re: spamd Will Not Create unix:socket
I suspect you need an entry in /etc/tmpfiles.d so that directory gets > created at boot time. > > Google tmpfiles.d or see this redhat blog page: > https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-systemd-tmpfiles-on-rhel7/ Indeed there is no tmpfiles in the spamassassin package. (I've never heard of this in 22 years) How can this be, in the 21st Century? As I'd suspected, everyone is settling for the tcp:port. What should I do about this, if anything? Fix it just for myself, or let someone else know?
RHEL7: spamass-milter-postfix==>spamassassin
Anyone know how spamass-milter-postfix communicates with spamassassin? There's a postfix socket, but no setting AFAICT for the milter to reach SA. I gather that the mechanism may be through clamc, but I have no proof that this is actually the case. It seems that everyone is resigned to leaving spamassassin on a tcp:port, which I don/t like for security reasons.
spamd Will Not Create unix:socket
I have fought with this for days, and finally had to hotwire it. But I'd like to understand what's going on. RHEL7 with spamassassin 3.4.0 and spamass-milter-postfix 0.4.0. /etc/sysconfig/spamassassin SPAMDOPTIONS="--daemonize --create-prefs --max-children=5 --username=spamd --groupname=spamd --socketpath=/run/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=660 --ipv4-only" spamassassin.service: [Unit] Description=Spamassassin daemon After=syslog.target network.target PartOf=spamassassin-update.service [Service] Type=forking PIDFile=/run/spamd.pid EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd ExecStart=/usr/bin/spamd --pidfile /run/spamd.pid $SPAMDOPTIONS StandardOutput=syslog StandardError=syslog Restart=always [Install] WantedBy=multi-user.target It simply would not create /run/spamassassin directory on boot. It is supposed to create it automatically like clamd does, since /run is wiped at each boot. To make it work I finally had to add: ExecStartPre=/usr/bin/mkdir /run/spamassassin ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin SELinux is set to Permissive, so that's not it. Any ideas?
