headers
Peter Bowyer | 1 May 2007 06:53
Gravatar

Re: IPTables Whitelisting

On 30/04/07, Mike Cardwell <exim-users <at> lists.grepular.com> wrote:
> Marc Perkel wrote:
>
> > This might be slightly off topic but I have something kind of tricky and
> > interesting in mind. I've been using a dummy IP address as my lowest MX
> > record as a way of getting rid of bot spam. And it's worked fairly well
> > but I'm trying to make it more interesting.
> >
> > What I'm doing now is pointing the lowest MX to a second IP on my lowest
> > MX server and what I want to do is open it up to a selected list of IP
> > addresses. Every 5 minutes I'm going to query a MySQL database and
> > create a list of IPs that will be allowed to talk to this lowest MX. All
> > other IPs will be blocked and forced to retry the higher MX which talks
> > to everything.
> >
> > I am not good with IP tables but what I need to do is perhaps create a
> > new chain of some sort (?) that I can wipe out and reload with new
> > values. I'll read the list and accept every IP in the list and then drop
> > all other IPs.
> >
> > Of course if there's something that can do this reading data out of me
> > database that would be great. But that's probably too much to ask.
> >
> > So - anyone have any ides on how to do this?
> >
> > BTW, Can't do a 4xx error because qmail servers will never retry higher
> > MX records if the see a 421 error. So the port has to be actually closed.
>
> "man iptables" and look for QUEUE. Then go to cpan.org and look at
> IPTables::IPv4::IPQueue. This will allow you to knock up a user space
(Continue reading)

Permalink | Reply | 5 comments |
headers
keith | 1 May 2007 06:59

Authentication - SPA password storage

My exim setup is using the SPA method of authentication, which is working
fine. The issue I have is that the usernames and passwords for this are
being held in a plain text file. Is there any way to at least get the
passwords encrypted, as having them held unencrypted seems to me to be a
possible security flaw (the file is only readable by the exim user, but
regardless of tthat it is still a file with un-encrypted passwords in it)

The config I am using for the authentication is as follows:

begin authenticators

spa:
  driver = spa
  public_name = NTLM
  server_password =
${lookup{$auth1}lsearch{/usr/exim/exim-users}{$value}fail}

Any ideas on how to encrypt the passwords and keep the SPA authenticaion
working?

Regards,
Keith.

--

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Permalink | Reply | 0 comments |
headers
Roger Keays | 1 May 2007 09:18
Picon

Easy VERPing with Exim

Hi all,

I've posted a blog showing an easy way to do VERP expansion with Exim:
http://www.gecko26.com/blog/exim_verp

This method uses a single redirect router to do the VERP expansion. When 
compared to using a transport, it is simpler to read and maintain, 
allows the recipient address to be rewritten as well as the return path 
and allows you to use your existing set of transports (e.g. local, 
remote, virtual) without having to add VERP capabilities to each.

Hope you like the article.

Roger

-- 
----------------------------------------
Ninth Avenue Software
p: +61 7 3137 1351 (UTC +10)
f: +61 7 3102 9141
w: http://www.ninthavenue.com.au
e: info <at> ninthavenue.com.au
----------------------------------------

--

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Cardwell | 1 May 2007 10:52

Re: IPTables Whitelisting

* on the Tue, May 01, 2007 at 05:53:45AM +0100, Peter Bowyer wrote:

>> "man iptables" and look for QUEUE. Then go to cpan.org and look at
>> IPTables::IPv4::IPQueue. This will allow you to knock up a user space
>> perl script to decide what to do with packets by talking to your db in
>> real time.
> Ah, now I looked into this a while back when Marc first talked about
> this technique. I investigated this method of controlling IPTables and
> came to the conclusion that it wouldn't do the job - once a packet has
> arrived in the userspace queue it's already been accepted - all you
> can do with it is drop it or carry on processing it, you can't reject
> it. You can't simulate 'nothing listening on this port'. So it's not
> suitable for the application Marc wants it for.
> 
> At least, that's how I read the documentation. I have been known to be
> wrong (yes, really...).

You look to be correct. But, while dropping the packet isn't ideal, the
overall outcome of doing that in this case is still the same as doing a
reject surely?

Mike

--

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Permalink | Reply | 3 comments |
headers
Peter Bowyer | 1 May 2007 10:58
Gravatar

Re: IPTables Whitelisting

On 01/05/07, Mike Cardwell <exim-users <at> lists.grepular.com> wrote:
> * on the Tue, May 01, 2007 at 05:53:45AM +0100, Peter Bowyer wrote:
>
> >> "man iptables" and look for QUEUE. Then go to cpan.org and look at
> >> IPTables::IPv4::IPQueue. This will allow you to knock up a user space
> >> perl script to decide what to do with packets by talking to your db in
> >> real time.
> > Ah, now I looked into this a while back when Marc first talked about
> > this technique. I investigated this method of controlling IPTables and
> > came to the conclusion that it wouldn't do the job - once a packet has
> > arrived in the userspace queue it's already been accepted - all you
> > can do with it is drop it or carry on processing it, you can't reject
> > it. You can't simulate 'nothing listening on this port'. So it's not
> > suitable for the application Marc wants it for.
> >
> > At least, that's how I read the documentation. I have been known to be
> > wrong (yes, really...).
>
> You look to be correct. But, while dropping the packet isn't ideal, the
> overall outcome of doing that in this case is still the same as doing a
> reject surely?

It would create a different error condition for the SMTP client the
other end - probably a 'connection timed out' rather than a
'connection refused'. This will certainly slow things down, and might
trigger different retry logic depending on the vagueries of the
implementation.

Peter
(Continue reading)

Permalink | Reply | 1 comment |
headers
Graeme Fowler | 1 May 2007 11:11

Re: IPTables Whitelisting

On Tue, 2007-05-01 at 09:58 +0100, Peter Bowyer wrote:
> It would create a different error condition for the SMTP client the
> other end - probably a 'connection timed out' rather than a
> 'connection refused'. This will certainly slow things down, and might
> trigger different retry logic depending on the vagueries of the
> implementation.

We're veering away from Exim specifically here, but for those who are
interested:

The netfilter QUEUE target is designed to pass things to userspace for
processing by an application able to hook the packet from the userspace
queues via the libipq API. The Perl IPTables::IPv4::IPQueue module is
one of these beasts.

Sadly, at present, libipq only has two verdicts it can pass back to the
kernel: NF_ACCEPT and NF_DROP.

If you want to implement an analogous verdict to the missing NF_REJECT,
then you have to pass NF_DROP to the kernel and then create an
appropriate ICMP packet in userspace and send it back to the source. You
can do this with the NetPacket::ICMP Perl module.

I spent some time playing with this a few months ago in order to do
packet filtering based on DNSBL lookups, but in the end I ran out of
time when a new member of the family arrived... I might get back to it
sooner or later.

Graeme
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graeme Fowler | 1 May 2007 11:15

Re: IPTables Whitelisting

On Tue, 2007-05-01 at 05:53 +0100, Peter Bowyer wrote:
> The only way I could think of doing this was a periodic rebuild of the
> static IPTables rules - which isn't particulary hard, nor particularly
> elegant. Have a look at Tom's 'timeban' script for inspiration - it's
> designed to work the other way round (reject an IP if it's in the
> database, else allow it), but that's easily fixed.

I'm not familiar with "timeban" so I don't know what it does
specifically. I make fairly heavy personal use of the iptables "recent"
and "hashlimit" modules - principally to prevent SSH dictionary attacks,
but they could just as easily be used to prevent people doing the stuff
Marc mentions.

Marc: before you ask about them, please read the iptables man page from
a recent version, and then if you have problems ask on a netfilter list.
This isn't the place.

Graeme

--

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Permalink | Reply | 0 comments |
headers
Renaud Allard | 1 May 2007 11:16

Re: IPTables Whitelisting


Marc Perkel wrote:
> This might be slightly off topic but I have something kind of tricky and 
> interesting in mind. I've been using a dummy IP address as my lowest MX 
> record as a way of getting rid of bot spam. And it's worked fairly well 
> but I'm trying to make it more interesting.
> 
> What I'm doing now is pointing the lowest MX to a second IP on my lowest 
> MX server and what I want to do is open it up to a selected list of IP 
> addresses. Every 5 minutes I'm going to query a MySQL database and 
> create a list of IPs that will be allowed to talk to this lowest MX. All 
> other IPs will be blocked and forced to retry the higher MX which talks 
> to everything.
> 
> I am not good with IP tables but what I need to do is perhaps create a 
> new chain of some sort (?) that I can wipe out and reload with new 
> values. I'll read the list and accept every IP in the list and then drop 
> all other IPs.
> 
> Of course if there's something that can do this reading data out of me 
> database that would be great. But that's probably too much to ask.
> 
> So - anyone have any ides on how to do this?
> 
> BTW, Can't do a 4xx error because qmail servers will never retry higher 
> MX records if the see a 421 error. So the port has to be actually closed.
> 
> 

Have a look at OpenBSD's spamd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Cooper | 1 May 2007 12:19
Favicon

Re: Help

Rohit Sakalle wrote:
> 
> Hello sir,
> 
> 
>                     Please tell me sir Why the second argument is used
> in local_scan i.e. **return_text. I have already read the document.
> Please give me a specific answer about why it's used.

Straight from the document, a very specific answer about why it's used.

<quote>
* return_text is an address which you can use to return a pointer to a
text string at the end of the function. The value it points to on entry
is NULL.
</quote>

So, when your function returns one of the following macro values and the
message is used as stated. You'll notice that some of them do use
**return_text, and some don't. In the manual it is referred to as "the
return text" or "a string of text".

The CAPITAL_LETTERS are the return values.

<quote>
The function must return an int value which is one of the following macros:

LOCAL_SCAN_ACCEPT

    The message is accepted. If you pass back a string of text, it is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olef van de Stadt | 1 May 2007 13:25
Picon

Strange TLS error

The following failure occurs when I run exim in debug mode:

 1796 SMTP<< STARTTLS
 1796 tls_certificate file /root/Certificates/Mail/mail.crt
 1796 tls_privatekey file /root/Certificates/Mail/mail.key
 1796 Initialized TLS
 1796 host in tls_verify_hosts? no (option unset)
 1796 host in tls_try_verify_hosts? no (option unset)
 1796 SMTP>> 220 TLS go ahead
 1796 Calling SSL_accept
 1796 LOG: MAIN
 1796   TLS error on connection from XXXXX (XXXXX) [XXXXXXX] (SSL_accept):
not in error state
 1796 TLS failed to start
 1796 SMTP<< ^A^C^A?x???^P??:??9??8??5??^V??^S??
 1796 SMTP>> 554 Security failure
 1796 LOG: smtp_connection MAIN

The "not in error state" thing concerns me, so I dug up the SSL manual
pages and changed a bit of code to add SSL_get_error(ssl, rc) to the log
line and I get (Note, this change was made around line 700 in
src/tls-openssl.c):

2007-05-01 13:11:23 TLS error on connection from XXXXX (XXXXX) [XXXXX]
(SSL_accept): not in error state [111]

Now the fun part, I cant seem to find any reference to errno '111' in the
manual pages, and why does ERR_get_error() return there is no error ?

Anyone here got a clue what may be wrong ?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane