Re: Customize log messages?

[Viktor Dukhovni]

> On Dec 4, 2016, at 12:58 AM, @lbutlr  wrote:
> 
>> MAIL FROM<"> type='text/javascript'>alert('xss');"@example.com>
> 
> That result in "501 5.5.4 Syntax: MAIL FROM:"

There's a missing ":" after FROM.  In any case, even if a particular
exploit mechanism fails, or even all attacks happen to fail, what
you're doing is still unwise.

-- 
Viktor.

Re: Customize log messages?

On 12/3/16 2:57 PM, Wietse Venema wrote:

Proof of concept:

  MAIL FROM<"alert('xss');"@example.com>


That result in "501 5.5.4 Syntax: MAIL FROM:"

Re: Customize log messages?

[Wietse Venema]

Wietse Venema:
> @ lbutlr:
> > > Careful with that.  To easy to create a script injection vector.  Bash is 
> > > not
> > > a good language in which to construct safely quoted remote content for 
> > > injection
> > > into a suitable HTML skeleton.
> > 
> > Injection from where? the script is only accessible to the root user on 
> > the mail server and only checks /var/log/maillog (or the log specified 
> > at the top of the script). There's no remote content involved.
> 
> Injection from the SMTP port.

SMTP session:

  220 mail.example.com
  EHLO client.example
  ...
  MAIL FROM<"some HTML code inside double quotes"@example.com>

Proof of concept:

  MAIL FROM<"alert('xss');"@example.com>

If you read this with a web browser, the following may be more readable:

  MAIL FROM"script 
type='text/javascript'alert('xss');/script"@example.com

Wietse

Re: Customize log messages?

[Wietse Venema]

@ lbutlr:
> > Careful with that.  To easy to create a script injection vector.  Bash is 
> > not
> > a good language in which to construct safely quoted remote content for 
> > injection
> > into a suitable HTML skeleton.
> 
> Injection from where? the script is only accessible to the root user on 
> the mail server and only checks /var/log/maillog (or the log specified 
> at the top of the script). There's no remote content involved.

Injection from the SMTP port.

Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[Wietse Venema]

rich.gre...@hushmail.com:
> $ telnet example.com 25
> Trying 87.138.xxx.yyy...
> Connected to example.com.
> Escape character is '^]'.
> 220 example.com ESMTP Postfix (Ubuntu)
> ehlo example.com
> 250-example.com
> 250-PIPELINING
> 250-SIZE 1024
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN

Per my earlier advice:
- Do not enable SASL auth in main.cf. 
- Do not enable SASL auth on port 25 in master.cf.

Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[Wietse Venema]

rich.gre...@hushmail.com:
> I suspected that was a typo.  I figured it out.
> 
> I made those changes, when I attempt an AUTH LOGIN, I get back "535 5.7.8 
> Error: authentication failed: UGFzc3dvcmQ6" which seems to be appropriate. 

You still have AUTH enabled on port 25.

Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[rich . greder]

On 12/3/2016 at 10:45 AM, "John Fawcett"  wrote:
>
>On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
>> Here I am, replying to my own post again.  What I said in the 
>prior post wasn't entirely true.  I realized that I used the wrong 
>password in my prior attempt.  I am still granted access to the 
>SMTP service after authenticating in plaintext on port 25.
>>
>> So I'm somewhat confused how to prevent/discourage users from 
>sending their authentication detail in the clear when there are 
>secure methods that exist (such as, $ openssl s_client -starttls 
>smtp -connect example.com:587)
>>
>>
>> $ telnet example.com 25
>> Trying 87.138.xxx.yyy...
>> Connected to example.com.
>> Escape character is '^]'.
>> 220 example.com ESMTP Postfix (Ubuntu)
>> ehlo example.com
>> 250-example.com
>> 250-PIPELINING
>> 250-SIZE 1024
>> 250-VRFY
>> 250-ETRN
>> 250-STARTTLS
>> 250-AUTH PLAIN LOGIN
>> 250-AUTH=PLAIN LOGIN
>> 250-ENHANCEDSTATUSCODES
>> 250-8BITMIME
>> 250 DSN
>> AUTH LOGIN
>> 334 VXNlcm5hbWU6
>> dXNlckBleGFtcGxlLmNvbQ==
>> 334 UGFzc3dvcmQ6
>> eW91IHdvdWxkIGRlY29kZSB0aGlz
>> 235 2.7.0 Authentication successful
>> quit
>>
>>
>> Thanks
>>
>Sounds as though you have not disabled auth on port 25, so you have
>still got
>
>smtpd_sasl_auth_only=yes
>

You mean, 'smtpd_tls_auth_only=yes' ?

>for the smtpd service. You may have configured that in main.cf by 
>changing the default value or in master.cf for the specific smtpd 
>entry.
>

In the main.cf, I have set globally

smtpd_tls_auth_only = yes

and in the master.cf, just to make sure, I have:

submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_auth_only=yes

So yes, after changing no -> yes in the main.cf, I get the permissions that I 
want.

>John

Re: Prevention of sending authentication via plaintext on port 25.

[Victoriano Giralt]

El 03/12/16 a las 17:25, rich.gre...@hushmail.com escribió:

> So I'm somewhat confused how to prevent/discourage users from sending
> their authentication detail in the clear when there are secure methods
> that exist (such as, $ openssl s_client -starttls smtp -connect
> example.com:587)

We would be much better equipped to help you if you shared the output of
your postconf -n and, maybe, master.cf so we can see what your actual
configuration looks like and tell you what you have to change to achieve
what you need.

-- 
Victoriano Giralt CIO
  University of Malaga
+34952131415  SPAIN
==
Note: signature.asc is the electronic signature of present message
A: Yes.
> Q: Are you sure ?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email ?



signature.asc
Description: OpenPGP digital signature

Re: Customize log messages?

On 12/3/16 9:53 AM, Bastian Blank wrote:

On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:

Injection from where? the script is only accessible to the root user
on the mail server and only checks /var/log/maillog (or the log
specified at the top of the script). There's no remote content
involved.


The contents of the log are from remote sources.


The contents of the logs are from postfix.

Re: Customize log messages?

[Bastian Blank]

On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:
> Injection from where? the script is only accessible to the root user
> on the mail server and only checks /var/log/maillog (or the log
> specified at the top of the script). There's no remote content
> involved.

The contents of the log are from remote sources.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Re: Prevention of sending authentication via plaintext on port 25.

[John Fawcett]

correcting my own typo now

On 12/03/2016 05:44 PM, John Fawcett wrote:
> On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
>> Here I am, replying to my own post again.  What I said in the prior post 
>> wasn't entirely true.  I realized that I used the wrong password in my prior 
>> attempt.  I am still granted access to the SMTP service after authenticating 
>> in plaintext on port 25.
>>
>> So I'm somewhat confused how to prevent/discourage users from sending their 
>> authentication detail in the clear when there are secure methods that exist 
>> (such as, $ openssl s_client -starttls smtp -connect example.com:587)
>>
>>
>> $ telnet example.com 25
>> Trying 87.138.xxx.yyy...
>> Connected to example.com.
>> Escape character is '^]'.
>> 220 example.com ESMTP Postfix (Ubuntu)
>> ehlo example.com
>> 250-example.com
>> 250-PIPELINING
>> 250-SIZE 1024
>> 250-VRFY
>> 250-ETRN
>> 250-STARTTLS
>> 250-AUTH PLAIN LOGIN
>> 250-AUTH=PLAIN LOGIN
>> 250-ENHANCEDSTATUSCODES
>> 250-8BITMIME
>> 250 DSN
>> AUTH LOGIN
>> 334 VXNlcm5hbWU6
>> dXNlckBleGFtcGxlLmNvbQ==
>> 334 UGFzc3dvcmQ6
>> eW91IHdvdWxkIGRlY29kZSB0aGlz
>> 235 2.7.0 Authentication successful
>> quit
>>
>>
>> Thanks
>>
> Sounds as though you have not disabled auth on port 25, so you have
> still got
>
> smtpd_sasl_auth_enable=yes
>
> for the smtpd service. You may have configured that in main.cf by changing 
> the default value or in master.cf for the specific smtpd entry.
>
> John
>
>

Re: Prevention of sending authentication via plaintext on port 25.

[John Fawcett]

On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
> Here I am, replying to my own post again.  What I said in the prior post 
> wasn't entirely true.  I realized that I used the wrong password in my prior 
> attempt.  I am still granted access to the SMTP service after authenticating 
> in plaintext on port 25.
>
> So I'm somewhat confused how to prevent/discourage users from sending their 
> authentication detail in the clear when there are secure methods that exist 
> (such as, $ openssl s_client -starttls smtp -connect example.com:587)
>
>
> $ telnet example.com 25
> Trying 87.138.xxx.yyy...
> Connected to example.com.
> Escape character is '^]'.
> 220 example.com ESMTP Postfix (Ubuntu)
> ehlo example.com
> 250-example.com
> 250-PIPELINING
> 250-SIZE 1024
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> AUTH LOGIN
> 334 VXNlcm5hbWU6
> dXNlckBleGFtcGxlLmNvbQ==
> 334 UGFzc3dvcmQ6
> eW91IHdvdWxkIGRlY29kZSB0aGlz
> 235 2.7.0 Authentication successful
> quit
>
>
> Thanks
>
Sounds as though you have not disabled auth on port 25, so you have
still got

smtpd_sasl_auth_only=yes

for the smtpd service. You may have configured that in main.cf by changing the 
default value or in master.cf for the specific smtpd entry.

John

Re: Customize log messages?

On 12/3/16 1:48 AM, Viktor Dukhovni wrote:

On Dec 2, 2016, at 1:30 AM, @lbutlr  wrote:

I have a bash script that does it, and when a user wants this, I simply set up 
a crontab for them. Usually after a week or so they want it turned off. The 
script sends them a lightly styled HTML table in the email.

The heart of the script is:

if [ "$REJECT" = 1 ]; then
  echo 'IP addressClaimed address'
bzgrep "$MATCHPAT" $LOGF | grep -i reject | egrep 'from=<[^>]+>' | grep -v 
"Protocol error" | \
 grep -v "$EXCLUDE" | sort -u | sed 's/from=,[]:' | grep -v 
rejected | \
 awk '{print "REJECTED"$16""$20""}'
  fi

Careful with that.  To easy to create a script injection vector.  Bash is not
a good language in which to construct safely quoted remote content for injection
into a suitable HTML skeleton.


Injection from where? the script is only accessible to the root user on 
the mail server and only checks /var/log/maillog (or the log specified 
at the top of the script). There's no remote content involved.

Re: TLS issue

On 12/2/16 12:16 PM, Wietse Venema wrote:


With 'no shared ciphers' happening frequently, do we want to set
up a TLS troubleshooting document, or is the decision tree too
complex for such a document to be useful?

Considering how often the question is asked, probably.

However, I think the error message in the logs is partly to blame since 
it will come up in a grep search for 'error'. (yes, people should grep 
for "error:" but they don't.)


Instead of "Protocol error;" I'd suggest maybe "no protocol match;" or 
similar wording that doesn't include 'error'.

Re: Azure Active Directory

On 12/2/16 4:32 PM, Petri Riihikallio wrote:


As long as saslauthd can bind against it like a regular Active Directory
(=LDAP) server, it should work without special configuration inside
postfix.

Does Azure AD support LDAP?

Yes.

Re: What is the number means?

On 12/2/16 2:34 PM, Michael Munger wrote:


Linux man page numbers.


The man page numbers have nothing to do with Linux.

Re: Prevention of sending authentication via plaintext on port 25.

[rich . greder]

Here I am, replying to my own post again.  What I said in the prior post wasn't 
entirely true.  I realized that I used the wrong password in my prior attempt.  
I am still granted access to the SMTP service after authenticating in plaintext 
on port 25.

So I'm somewhat confused how to prevent/discourage users from sending their 
authentication detail in the clear when there are secure methods that exist 
(such as, $ openssl s_client -starttls smtp -connect example.com:587)


$ telnet example.com 25
Trying 87.138.xxx.yyy...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix (Ubuntu)
ehlo example.com
250-example.com
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH LOGIN
334 VXNlcm5hbWU6
dXNlckBleGFtcGxlLmNvbQ==
334 UGFzc3dvcmQ6
eW91IHdvdWxkIGRlY29kZSB0aGlz
235 2.7.0 Authentication successful
quit


Thanks

On 12/3/2016 at 10:03 AM, rich.gre...@hushmail.com wrote:
>
>I suspected that was a typo.  I figured it out.
>
>I made those changes, when I attempt an AUTH LOGIN, I get back 
>"535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6" which seems 
>to be appropriate. 
>
>So the user is no longer rewarded with access to the SMTP services 
>when they attempt to connect using this method, such as sending a 
>plaintext password on port 25.  Obviously, user irresponsibility 
>can't be prevented, but at least they are denied access for 
>attempting to connect in an irresponsible manner.  So yes, I can 
>see how this works.
>
>Thanks
>
>On 12/3/2016 at 9:49 AM, "Wietse Venema"  
>wrote:
>>
>>John Fawcett:
>>> On 12/03/2016 04:10 PM, Wietse Venema wrote:
>>> > rich.gre...@hushmail.com:
>>> >> There are ports that exist for encrypted transfer of this 
>data
>>> >> (such as 465, 587).  What is the current state of the art for
>>> >> preventing the user's client software from being able to do 
>>this
>>> >> (sending their authentication details plaintext)?  Is it 
>safe 
>>to
>>> >> simply block this port external to the machine, for example, 
>>in
>>> >> the router?
>>> > Don't enable SASL auth on port 25.
>>> >
>>> > Do require smtpd_tls_auth_only=yes on port 587.
>>> >
>>> > This is easiest implemented by seting smtpd_sasl_auth_enable 
>>and
>>> > smtpd_tls_auth_only in the master.cf entry for the port 587 
>>service,
>>> > and not setting them in main.cf.
>>> >
>>> > submission inet n   -   n   -   -   smtpd
>>> >   -o syslog_name=postfix/submission
>>> >   -o smtpd_tls_security_level=encrypt
>>> >   -o smtpd_sasl_auth_enable=yes
>>> >   -o smtpd_sasl_auth_only=yes
>>> >   -o smtpd_reject_unlisted_recipient=no
>>> >   -o smtpd_client_restrictions=$mua_client_restrictions
>>> >   -o smtpd_helo_restrictions=$mua_helo_restrictions
>>> >   -o smtpd_sender_restrictions=$mua_sender_restrictions
>>> >   -o smtpd_recipient_restrictions=
>>> >   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>>> >   -o milter_macro_daemon_name=ORIGINATING
>>> >
>>> > (similar for the obsolete 'smtps' service on port 465).
>>> >
>>> > mua_client_restrictions, mua_helo_restrictions, 
>>mua_sender_restrictions
>>> > can then be specified in main.cf.
>>> >
>>> >   Wietse
>>> 
>>> Wietse
>>> 
>>> this looks like a typo
>>> 
>>> -o smtpd_sasl_auth_only=yes
>>> 
>>> that should be
>>> 
>>> -o smtpd_tls_auth_only=yes
>>> 
>>> in line with your comment above the config.
>>
>>Yes.
>>
>>  Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[rich . greder]

I suspected that was a typo.  I figured it out.

I made those changes, when I attempt an AUTH LOGIN, I get back "535 5.7.8 
Error: authentication failed: UGFzc3dvcmQ6" which seems to be appropriate. 

So the user is no longer rewarded with access to the SMTP services when they 
attempt to connect using this method, such as sending a plaintext password on 
port 25.  Obviously, user irresponsibility can't be prevented, but at least 
they are denied access for attempting to connect in an irresponsible manner.  
So yes, I can see how this works.

Thanks

On 12/3/2016 at 9:49 AM, "Wietse Venema"  wrote:
>
>John Fawcett:
>> On 12/03/2016 04:10 PM, Wietse Venema wrote:
>> > rich.gre...@hushmail.com:
>> >> There are ports that exist for encrypted transfer of this data
>> >> (such as 465, 587).  What is the current state of the art for
>> >> preventing the user's client software from being able to do 
>this
>> >> (sending their authentication details plaintext)?  Is it safe 
>to
>> >> simply block this port external to the machine, for example, 
>in
>> >> the router?
>> > Don't enable SASL auth on port 25.
>> >
>> > Do require smtpd_tls_auth_only=yes on port 587.
>> >
>> > This is easiest implemented by seting smtpd_sasl_auth_enable 
>and
>> > smtpd_tls_auth_only in the master.cf entry for the port 587 
>service,
>> > and not setting them in main.cf.
>> >
>> > submission inet n   -   n   -   -   smtpd
>> >   -o syslog_name=postfix/submission
>> >   -o smtpd_tls_security_level=encrypt
>> >   -o smtpd_sasl_auth_enable=yes
>> >   -o smtpd_sasl_auth_only=yes
>> >   -o smtpd_reject_unlisted_recipient=no
>> >   -o smtpd_client_restrictions=$mua_client_restrictions
>> >   -o smtpd_helo_restrictions=$mua_helo_restrictions
>> >   -o smtpd_sender_restrictions=$mua_sender_restrictions
>> >   -o smtpd_recipient_restrictions=
>> >   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>> >   -o milter_macro_daemon_name=ORIGINATING
>> >
>> > (similar for the obsolete 'smtps' service on port 465).
>> >
>> > mua_client_restrictions, mua_helo_restrictions, 
>mua_sender_restrictions
>> > can then be specified in main.cf.
>> >
>> >Wietse
>> 
>> Wietse
>> 
>> this looks like a typo
>> 
>> -o smtpd_sasl_auth_only=yes
>> 
>> that should be
>> 
>> -o smtpd_tls_auth_only=yes
>> 
>> in line with your comment above the config.
>
>Yes.
>
>   Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[Wietse Venema]

John Fawcett:
> On 12/03/2016 04:10 PM, Wietse Venema wrote:
> > rich.gre...@hushmail.com:
> >> There are ports that exist for encrypted transfer of this data
> >> (such as 465, 587).  What is the current state of the art for
> >> preventing the user's client software from being able to do this
> >> (sending their authentication details plaintext)?  Is it safe to
> >> simply block this port external to the machine, for example, in
> >> the router?
> > Don't enable SASL auth on port 25.
> >
> > Do require smtpd_tls_auth_only=yes on port 587.
> >
> > This is easiest implemented by seting smtpd_sasl_auth_enable and
> > smtpd_tls_auth_only in the master.cf entry for the port 587 service,
> > and not setting them in main.cf.
> >
> > submission inet n   -   n   -   -   smtpd
> >   -o syslog_name=postfix/submission
> >   -o smtpd_tls_security_level=encrypt
> >   -o smtpd_sasl_auth_enable=yes
> >   -o smtpd_sasl_auth_only=yes
> >   -o smtpd_reject_unlisted_recipient=no
> >   -o smtpd_client_restrictions=$mua_client_restrictions
> >   -o smtpd_helo_restrictions=$mua_helo_restrictions
> >   -o smtpd_sender_restrictions=$mua_sender_restrictions
> >   -o smtpd_recipient_restrictions=
> >   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
> >   -o milter_macro_daemon_name=ORIGINATING
> >
> > (similar for the obsolete 'smtps' service on port 465).
> >
> > mua_client_restrictions, mua_helo_restrictions, mua_sender_restrictions
> > can then be specified in main.cf.
> >
> > Wietse
> 
> Wietse
> 
> this looks like a typo
> 
> -o smtpd_sasl_auth_only=yes
> 
> that should be
> 
> -o smtpd_tls_auth_only=yes
> 
> in line with your comment above the config.

Yes.

Wietse

Re: Prevention of sending authentication via plaintext on port 25.

[John Fawcett]

On 12/03/2016 04:10 PM, Wietse Venema wrote:
> rich.gre...@hushmail.com:
>> There are ports that exist for encrypted transfer of this data
>> (such as 465, 587).  What is the current state of the art for
>> preventing the user's client software from being able to do this
>> (sending their authentication details plaintext)?  Is it safe to
>> simply block this port external to the machine, for example, in
>> the router?
> Don't enable SASL auth on port 25.
>
> Do require smtpd_tls_auth_only=yes on port 587.
>
> This is easiest implemented by seting smtpd_sasl_auth_enable and
> smtpd_tls_auth_only in the master.cf entry for the port 587 service,
> and not setting them in main.cf.
>
> submission inet n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_sasl_auth_only=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_client_restrictions=$mua_client_restrictions
>   -o smtpd_helo_restrictions=$mua_helo_restrictions
>   -o smtpd_sender_restrictions=$mua_sender_restrictions
>   -o smtpd_recipient_restrictions=
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING
>
> (similar for the obsolete 'smtps' service on port 465).
>
> mua_client_restrictions, mua_helo_restrictions, mua_sender_restrictions
> can then be specified in main.cf.
>
>   Wietse

Wietse

this looks like a typo

-o smtpd_sasl_auth_only=yes

that should be

-o smtpd_tls_auth_only=yes

in line with your comment above the config.

John

Re: Prevention of sending authentication via plaintext on port 25.

[Wietse Venema]

rich.gre...@hushmail.com:
> There are ports that exist for encrypted transfer of this data
> (such as 465, 587).  What is the current state of the art for
> preventing the user's client software from being able to do this
> (sending their authentication details plaintext)?  Is it safe to
> simply block this port external to the machine, for example, in
> the router?

Don't enable SASL auth on port 25.

Do require smtpd_tls_auth_only=yes on port 587.

This is easiest implemented by seting smtpd_sasl_auth_enable and
smtpd_tls_auth_only in the master.cf entry for the port 587 service,
and not setting them in main.cf.

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

(similar for the obsolete 'smtps' service on port 465).

mua_client_restrictions, mua_helo_restrictions, mua_sender_restrictions
can then be specified in main.cf.

Wietse

Re: Customize log messages?

[Wietse Venema]

Viktor Dukhovni:
> 
> > On Dec 2, 2016, at 1:30 AM, @lbutlr  wrote:
> > 
> > I have a bash script that does it, and when a user wants this, I simply set 
> > up a crontab for them. Usually after a week or so they want it turned off. 
> > The script sends them a lightly styled HTML table in the email.
> > 
> > The heart of the script is:
> > 
> > if [ "$REJECT" = 1 ]; then
> >  echo 'IP addressClaimed address'
> >bzgrep "$MATCHPAT" $LOGF | grep -i reject | egrep 'from=<[^>]+>' | grep 
> > -v "Protocol error" | \
> > grep -v "$EXCLUDE" | sort -u | sed 's/from=,[]:' | grep 
> > -v rejected | \
> > awk '{print "REJECTED > class=\"right\">"$16""$20""}'
> >  fi
> 
> Careful with that.  To easy to create a script injection vector.
> Bash is not a good language in which to construct safely quoted
> remote content for injection into a suitable HTML skeleton.

In the AWK script, ``gsub(/[<>"]/, "_"); print...'' might do the job.

Wietse

Prevention of sending authentication via plaintext on port 25.

[rich . greder]

I love to go and see what I can get away with using telnet.  I decided to send 
and check email from the command line.

Since I consider my test location to be low risk, I decided to try to send my 
password plaintext over port 25.  I was a moderately surprised that it did 
work, as seen below in the typescript.  Now imagine that if I was hosting for 
more people than just a few family members, any arbitrary user could, perhaps 
out of ignorance or convenience, be choosing to send their password plaintext.  
In the event of someone sniffing the authentication data, they would be able to 
transmit emails using a shell script, which concerns me.

There are ports that exist for encrypted transfer of this data (such as 465, 
587).  What is the current state of the art for preventing the user's client 
software from being able to do this (sending their authentication details 
plaintext)?  Is it safe to simply block this port external to the machine, for 
example, in the router?

Thanks...

$ telnet example.com 25
Trying 87.138.xxx.yyy...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix (Ubuntu)
helo example
250 example.com
ehlo example
250-example.com
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH LOGIN
334 VXNlcm5hbWU6
dXNlckBleGFtcGxlLm9yZw==
334 UGFzc3dvcmQ6
cGFzc3dvcmQ=
235 2.7.0 Authentication successful
mail from: 
250 2.1.0 Ok
rcpt to: 
250 2.1.5 Ok
data
354 End data with .
From:  
To: Rich Greder 
Subject: Testing
This is a test.
.

250 2.0.0 Ok: queued as BFDEB3FE30
quit
221 2.0.0 Bye
Connection closed by foreign host.

Re: Customize log messages?

[Viktor Dukhovni]

> On Dec 2, 2016, at 1:30 AM, @lbutlr  wrote:
> 
> I have a bash script that does it, and when a user wants this, I simply set 
> up a crontab for them. Usually after a week or so they want it turned off. 
> The script sends them a lightly styled HTML table in the email.
> 
> The heart of the script is:
> 
> if [ "$REJECT" = 1 ]; then
>  echo 'IP addressClaimed address'
>bzgrep "$MATCHPAT" $LOGF | grep -i reject | egrep 'from=<[^>]+>' | grep -v 
> "Protocol error" | \
> grep -v "$EXCLUDE" | sort -u | sed 's/from=,[]:' | grep -v 
> rejected | \
> awk '{print "REJECTED class=\"right\">"$16""$20""}'
>  fi

Careful with that.  To easy to create a script injection vector.  Bash is not
a good language in which to construct safely quoted remote content for injection
into a suitable HTML skeleton.

-- 
Viktor.