Rich,
I suggest the following
minimal-responses yes; - set this global
blackhole { address_match_list }; - use the address_match_list file on
your pf.conf (freebsd)
with this combo, your bind should refuse queries when it's out-of-zone.
additional-from-auth yes;
additional-from-cache no;
You should be complying with BCP 38 [http://tools.ietf.org/html/bcp38]
for Inbound Network Filtering which will reduce a lot of unwanted
packets getting into your network.
Our inbound (Cisco) ACL looks like the following and I check up on the
bogon addresses
The spoofed ip's are coming from the outside world as real legitimate IP's.
They are not coming internally and then heading outwards. We have to allow
port 53 traffic from the internet because we publish a dozen domains or so,
and also cache for our customers. The question is why does the server
As we've already pointed out it is something in the way your system is
configured (you're doing everything in global options instead of using
views to separate the different classes of users) and that you are
running both authoritative and caching functions on the same server.
You can create 2
You can create 2 views authorised and everyone else which both
reference the same domain zone files so you dont need to duplicate the
zones.
On a secondary, the zone files in different views, even if identical,
need to be
distinct.
Also, if you're allowing dynamical updating and the views
On 1 February 2013 18:42, John Wobus jw...@cornell.edu wrote:
On a secondary, the zone files in different views, even if identical, need
to be
distinct.
Also, if you're allowing dynamical updating and the views need to serve
identical
versions of the zone, then you need to arrange things so
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
On 1/31/13 7:05 PM, rich carroll wrote:
antispoof log quick for em0 inet
but that did not trigger on any of the requests.
This leads to nowhere in your specific case, check 'pfctl -sr' and the
docs[1] to learn how this rule expands.
[1] http://www.openbsd.org/faq/pf/filter.html#antispoof
--
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
Currently our ISP's bind9 server is experiencing a lot of traffic. It looks
like we are being used to attack ip addresses. We do have our own domains
that host as well as resolving for our customers.
I have an acl for our subnets and we allow-recursion and allow-query-cache
for those subnets. The
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
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
In message caovd2ajeognmbkjj7dou9que2xkt4iz6+lrko2_1w3zusti...@mail.gmail.com
, rich carroll writes:
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;
I'm not entirely sure about the allow-query { any; }; option you
have configured in the main options section, by default bind allows
queries from all anyway, try removing this and see if that fixes the
issue, it could be having that set is somehow overriding some of the
other statements.
Steve
I think this is one of those reasons why mixing caching/recursion with
authoritative is bad.
I think the option needed is 'additional-from-cache no;', but its only
effective if 'recursion no' is done in global options ... or in a view?
Hmm, wonder if view is the answerperhaps try
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
16 matches
Mail list logo
