ipt_string, udp, dns problem...

ipt_string, udp, dns problem...

[Mark Steele]

Hi there,

I have a quick question regarding the iptables string module.

I'm currently under siege from a DOS attack which is aimed
at my name server. I believe the culprit is spoofing
his IP address, and sending DNS requests to various
recursive name servers for a domain which used to be
hosted in my servers. To block this, I am trying to use
a string match to drop the packets like so:

/usr/sbin/iptables -I INPUT -j DROP -p udp -s 0.0.0.0/0 -m \
string --string "militaire.org" --dport 53

I have noticed however, that this hasn't had much of a significant
effect, as my name server is still receiving the requests.

using "tcpdump udp dst port 53 -s 2000" I see:

17:56:39.071676 193.252.19.74.50963 > 66.199.166.5.53:  36126 A?
www.militaire.org. (35) (DF)

And the requests are getting through to my
name server. Any ideas on what I might
be doing wrong?

Here are the details:
kernel 2.4.19
iptables v1.2.7a
glibc 2.2.3
(Slackware 8.1)

Kernel options (on)
ip_tables
iptable_filter
ip_conntrack
ipt_state
ipt_LOG
ipt_string


Regards,


-- 
Mark Steele
Vice president recherche et developpement
Inet Technologies Inc.

Re: ipt_string, udp, dns problem...

[Antony Stone]

On Sunday 22 September 2002 10:34 am, Mark Steele wrote:

> Hi there,
>
> I have a quick question regarding the iptables string module.
>
> I'm currently under siege from a DOS attack which is aimed
> at my name server. I believe the culprit is spoofing
> his IP address, and sending DNS requests to various
> recursive name servers for a domain which used to be
> hosted in my servers. To block this, I am trying to use
> a string match to drop the packets like so:
>
> /usr/sbin/iptables -I INPUT -j DROP -p udp -s 0.0.0.0/0 -m \
> string --string "militaire.org" --dport 53
>
> I have noticed however, that this hasn't had much of a significant
> effect, as my name server is still receiving the requests.
>
> And the requests are getting through to my
> name server. Any ideas on what I might
> be doing wrong?

Yes.   You are assuming that a UDP port 53 packet corresponding to a lookup 
of militaire.org actually contains the literal string "militaire.org".

In fact it doesn't.   Specifically, the dot separating the domain name from 
the org is not an Ascii 46 (0x2E).

Try changing your string match to look for just "militaire" and see if that 
works.

Antony.

-- 

Software development can be quick, high-quality, or low-cost.

The customer gets to pick any two out of three.

Re: ipt_string, udp, dns problem...

[Anders Fugmann]

Mark Steele wrote:
> Hi there,
> 
> I have a quick question regarding the iptables string module.
> 
> I'm currently under siege from a DOS attack which is aimed
> at my name server. I believe the culprit is spoofing
> his IP address, and sending DNS requests to various
> recursive name servers for a domain which used to be
> hosted in my servers. To block this, I am trying to use
> a string match to drop the packets like so:
> 
> /usr/sbin/iptables -I INPUT -j DROP -p udp -s 0.0.0.0/0 -m \
> string --string "militaire.org" --dport 53
> 
Are you sure the communication is not TCP, and please drop the -s 
0.0.0.0/0, its redundant.

But.... This is not the way to do it. Iptables should not be confused 
with an application level filter. It should only be used to filter out 
at the lower levels of the OSI model.

I think that there is a nuch more generic way to stop this.
I guess that you are not hosting a master or slave DNS for the domain in 
question. Ths most usual setup for a DNS is to provide DNS services to 
anyone behind the firewall, and to be master or slave for only a few 
domains. Is seems like a configuration problem, if you are provinding 
DNS service for the whole internet.

Therefore you should configure your nameserver to allow queries from all 
clients behind the firewall, and only to service requests on the domains 
you are servicing from the internet.

In Bind9 the configuration would look something like this:

/* Bind9 configuration sample begins */

//ACL for machines that use the DNS as their primary.
acl "local" {
         { 10.0.0.0/23; 127.0.0.1; 80.xx.xx.98; };
};

//ACL for machines allowed yo do a zone transfer.
acl "backups" {
         { 80.xx.xx.54; 212.xx.xx.121;  };
};

options {
         allow-query    { "local"; };
         allow-transfer { "local"; };
};

// prime the server with knowledge of the root servers
zone "." {
         type hint;
         file "/etc/bind/db.root";
};

//Public zone.
zone "test.edu" {
         type master;
         file "/etc/bind/db.test.edu";
	//Allow anyone to query on this domain.
         allow-query { any; };
         allow-transfer { "backups"; };

};
/* Bind9 configuration sample ends */

Of course this is not a complete configuration, but I guess you get the 
idea. I have less experience with older version of Bind, so I cannot say 
if this will work, but I guess that not much has changed.

In general - I suggest all people having a firewall installed, to 
configure their machines in such a way that no firewall was nessesary 
(in IPtables terms - with no _filter_ rules applied). A Firewall is only 
an extra safeguard, which should not be used to hide misconfigured srvices.

Regards
Anders Fugmann

Re: ipt_string, udp, dns problem...

[Antony Stone]

On Sunday 22 September 2002 1:15 pm, Anders Fugmann wrote:

> Mark Steele wrote:
> > Hi there,
> >
> > I have a quick question regarding the iptables string module.
> >
> > I'm currently under siege from a DOS attack which is aimed
> > at my name server. I believe the culprit is spoofing
> > his IP address, and sending DNS requests to various
> > recursive name servers for a domain which used to be
> > hosted in my servers. To block this, I am trying to use
> > a string match to drop the packets like so:
> >
> > /usr/sbin/iptables -I INPUT -j DROP -p udp -s 0.0.0.0/0 -m \
> > string --string "militaire.org" --dport 53
>
> Are you sure the communication is not TCP, and please drop the -s
> 0.0.0.0/0, its redundant.

The communication for DNS *could* be over TCP, but the tcpdump output Mark 
included in the initial posting showed that it was coming over UDP (ie a 
simple client query, not a DNS-to-DNS zone transfer request).

I agree about removing the -s 0.0.0.0/0 - things like this make rules much 
harder to read.

> But.... This is not the way to do it. Iptables should not be confused
> with an application level filter. It should only be used to filter out
> at the lower levels of the OSI model.

Agreed !!!!!   I sometimes wish the --string match had never been included in 
netfilter at all, because it misleads people into thinking that netfilter can 
be used as a content filter.   It isn't a content filter !!!

> I guess that you are not hosting a master or slave DNS for the domain in
> question.

Actually I assumed from the initial posting that he was.   That was the 
reason why the requests end up on his DNS server from the various recursive 
name servers which Mark is getting the packets from.

If he wasn't running an authoritative name server for the domain in question 
then he shouldn't be getting any external requests at all.

> Ths most usual setup for a DNS is to provide DNS services to
> anyone behind the firewall, and to be master or slave for only a few
> domains. Is seems like a configuration problem, if you are providing
> DNS service for the whole internet.

Maybe Mark could clarify which of these situation applies ?

> I have less experience with older version of Bind, so I cannot say
> if this will work, but I guess that not much has changed.

You might be surprised :-)   There have been some *big* changes in the 
structure of Bind configuration files, and backward compatibility is not a 
safe thing to assume :-)

> In general - I suggest all people having a firewall installed, to
> configure their machines in such a way that no firewall was nessesary
> (in IPtables terms - with no _filter_ rules applied). A Firewall is only
> an extra safeguard, which should not be used to hide misconfigured srvices.

That's good advice.   Don't rely on a firewall to cover up known security 
problems.   Fix the problems and then use the firewall to stop the script 
kiddies bothering with your network at all.

Antony.

-- 

Most people are aware that the Universe is big.

 - Paul Davies, Professor of Theoretical Physics

Re: ipt_string, udp, dns problem...

[Antony Stone]

On Sunday 22 September 2002 10:34 am, Mark Steele wrote:

> I'm currently under siege from a DOS attack which is aimed
> at my name server. I believe the culprit is spoofing
> his IP address, and sending DNS requests to various
> recursive name servers for a domain which used to be
> hosted in my servers.

Why not remove your name server from the list of name servers for that domain 
in the whois database ?   Then the recursive name servers won't come and 
expect an answer from your machine.

Antony.

-- 

There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

Re: ipt_string, udp, dns problem...

[Mark Steele]

Hello again :)

Ok, I suppose I have to clear up a few things...

The communication is definitely udp. I'm using tinydns
(http://cr.yp.to/djbdns.html) as a name server. It only serves
authoritative requests (via udp), and has to be accessible from the
internet.

I cannot remove the domain from the whois database. Although
it does point to my name server, none of the domain contact information
is in my company's name. The domain in question was cut off
from our hosting service. (Although I suppose I could take it up with
the registrar)

The only real solution to this problem is probably to get
the recursive DNS servers from which this attack is originating
to block spoofed packets, and restrict access to their name
servers to their own network. I have already tried to get
this done, but unfortunately they haven't responded yet.

Therefore, since I cannot change the name server information
in the DNS root, and cannot stop serviing DNS requests to the
outside world, any ideas on what is incorrect with the rule
I put forth in the first place?

I've been looking at the packets comming in, and unless I'm mistaken,
either the string module doesn't work with udp, or I'm missing
something in my rule.

Here it is again, for convenience:

/usr/sbin/iptables -I INPUT -j DROP -p udp -m \
string --string "militaire.org" --dport 53


Just as a note, this isn't a very urgent problem. TinyDNS can easily
handle anything they can throw my way. I highly recommend
it as a replacement for some other well known and buggy name servers which
I won't name ;). The load on my server from this denial of service is
around less than 1% cpu and memory...

Regards,

-- 
Mark Steele
Vice president research and development
Inet Technologies Inc.
email: msteele@inet-technologies.com

> Mark Steele wrote:
>> Hi there,
>>
>> I have a quick question regarding the iptables string module.
>>
>> I'm currently under siege from a DOS attack which is aimed
>> at my name server. I believe the culprit is spoofing
>> his IP address, and sending DNS requests to various
>> recursive name servers for a domain which used to be
>> hosted in my servers. To block this, I am trying to use
>> a string match to drop the packets like so:
>>
>> /usr/sbin/iptables -I INPUT -j DROP -p udp -s 0.0.0.0/0 -m \
>> string --string "militaire.org" --dport 53
>>
> Are you sure the communication is not TCP, and please drop the -s
> 0.0.0.0/0, its redundant.
>
> But.... This is not the way to do it. Iptables should not be confused
> with an application level filter. It should only be used to filter out
> at the lower levels of the OSI model.
>
> I think that there is a nuch more generic way to stop this.
> I guess that you are not hosting a master or slave DNS for the domain in
>  question. Ths most usual setup for a DNS is to provide DNS services to
> anyone behind the firewall, and to be master or slave for only a few
> domains. Is seems like a configuration problem, if you are provinding
> DNS service for the whole internet.
>
> Therefore you should configure your nameserver to allow queries from all
>  clients behind the firewall, and only to service requests on the
> domains  you are servicing from the internet.
>
> In Bind9 the configuration would look something like this:
>
> /* Bind9 configuration sample begins */
>
> //ACL for machines that use the DNS as their primary.
> acl "local" {
>          { 10.0.0.0/23; 127.0.0.1; 80.xx.xx.98; };
> };
>
> //ACL for machines allowed yo do a zone transfer.
> acl "backups" {
>          { 80.xx.xx.54; 212.xx.xx.121;  };
> };
>
> options {
>          allow-query    { "local"; };
>          allow-transfer { "local"; };
> };
>
> // prime the server with knowledge of the root servers
> zone "." {
>          type hint;
>          file "/etc/bind/db.root";
> };
>
> //Public zone.
> zone "test.edu" {
>          type master;
>          file "/etc/bind/db.test.edu";
> 	//Allow anyone to query on this domain.
>          allow-query { any; };
>          allow-transfer { "backups"; };
>
> };
> /* Bind9 configuration sample ends */
>
> Of course this is not a complete configuration, but I guess you get the
> idea. I have less experience with older version of Bind, so I cannot say
>  if this will work, but I guess that not much has changed.
>
> In general - I suggest all people having a firewall installed, to
> configure their machines in such a way that no firewall was nessesary
> (in IPtables terms - with no _filter_ rules applied). A Firewall is only
>  an extra safeguard, which should not be used to hide misconfigured
> srvices.
>
> Regards
> Anders Fugmann