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 |
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 |
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 |
headers
Marc Perkel | 1 May 2007 15:19

Re: IPTables Whitelisting


Mike Cardwell 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?
>
> Mike
>   

If everyone played by the rules then I could simply return a 421 on the
(Continue reading)

Permalink | Reply |
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 |
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 |

Gmane