Hi, Richard,

I reject spoofed IPs more or less like this:

# Do some checks for obviously spoofed IP's
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 127.0.0.0/8 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 10.0.0.0/8 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 172.16.0.0/12 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 192.168.0.0/16 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 224.0.0.0/4 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 240.0.0.0/5 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -d 0.0.0.0 -j DROP
$IPT -t nat -A PREROUTING -p 42 -j DROP    # SDR protocol
$IPT -t nat -A PREROUTING -p 43 -j DROP
#===================

it depends of course a lot on OS, version, network topology
and variables set, so should be duely whittled and rasped away ...

DROP means here no reply, no log, total ignoring.

Of course this can work only if spoofed IPs fall into
official non-routable address ranges ...
And, inportant, I also reject multicasts which will not suite
in some cases.

rich carroll wrote:

Currently the box is running packet filter on freebsd.

I added:

antispoof log quick for em0 inet

but that did not trigger on any of the requests.

I am going to mess with views some time today, but if that doesn't stop
responses to requests from the outside, other then our domains, we will
move our domains back our registrar and let them do the publishing and only
use our dns servers for caching/recursing for our internal people and block
it from the outside.






On Thu, Jan 31, 2013 at 12:41 AM, Dmitri Tarkhov <tark...@dionaholding.ru>wrote:


One very simple question - do you filter spoofed IPs
at your firewalls?
And, BTW, a lot of other must be stuff, like ports 135-139 ...
(but that's another story)

Personally I reject spoofed IPs even without logging.


They are more then likely spoofed IP's and

someone is using our servers to attack people.


rich carroll wrote:

 acl "trusted" {

    xxx.xxx.xxx.0/20;
    xxx.xxx.xxx.0/23;
    xxx.xxx.xxx.0/22;
    xx.xxx.xxx.0/23;
    xx.xxx.xxx.0/23;
    xx.xxx.xxx.0/23;
    x.xx.xxx.0/21;
    x.xx.xx.0/24;
    xxx.xxx.xxx.0/24;
    localhost;
    localnets;
};

options {
   // Relative to the chroot directory, if any
   directory    "/etc/namedb";
   pid-file    "/var/run/named/pid";
   dump-file    "/var/dump/named_dump.db";
   statistics-file    "/var/stats/named.stats";
   allow-recursion { "trusted"; };
   allow-query    { any; };
   allow-query-cache { "trusted"; };

Its standard conf with the default stuff in it as well as a 24 zones or so
in it.



On Wed, Jan 30, 2013 at 3:30 PM, Steven Carr <sjc...@gmail.com> wrote:


So the response you received wasn't recursed ";; WARNING: recursion

requested but not available", so at least that ACL is holding up, but
it could be that the response you got is still being served from your
DNS server's cache. Can you share the exact configuration statements
you have implemented for allow-recursion and allow-query-cache and are
these options in the view stanza or in the global options?

Best practice is that authoritative and recursive DNS servers should
be completely separate.

Steve






------------------------------**------------------------------**
------------


______________________________**_________________
Please visit 
https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>to
 unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>

--
Best regards,
Dmitri Tarkhov


______________________________**_________________
Please visit 
https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>to
 unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>





------------------------------------------------------------------------

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
Best regards,
Dmitri Tarkhov

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to