On 08/09/2018 01:01 AM, Lee wrote:
it does, so you have to flag your local zones as rpz-passthru.
Thank you again Lee. You gave me exactly what I needed and wanted to know.
I finally got around to configuring my RPZ to filter IPv4
Special-Purpose Address Registry as per IANA's definition.
On 2018-10-24 07:24, Timothy Metzinger wrote:
There's no security in obscurity. Automated port scanners will sweep
your system in a couple of seconds.
There is *limited* security in obscurity but it's a valid layer.
Obviously insufficient as an only layer...
As a trivial example, I get
On 10/24/2018 07:24 AM, Timothy Metzinger wrote:
There's no security in obscurity.
Obscurity by itself is not security.
Obscurity can be one many layers of security.
Automated port scanners will sweep your system in a couple of seconds.
Yes, automated scanners can scan all the ports on a
On 10/24/2018 06:15 AM, G.W. Haywood via bind-users wrote:
A server on a non-standard port is often neglected. Its security may
be less well maintained than one that is intentionally public.
Why and how do you make that correlation?
Are you implying that some people think that because
I agree on using non-standard ports as well.
Moving SSH to a non-standard port is a perfect example of how to actually ID
bad actors. It follows that any host connecting to 22 is clearly traffic that
needs to be dropped and blocked. And if that host is blocked then any other
connections it
On 10/24/2018 03:58 AM, Matus UHLAR - fantomas wrote:
It uses routing tables to decide this, so you can force it to use
alternative route.
It's also possible to use the routing table to specify which source IP
is used for a given route.
This is handy to specify the source IP to use if you
Maybe port scanners will find open ports pretty quickly, but I've found
that using non-standard ports is helpful in reducing traffic, at least.
For example, SSH on port 22 gets lots of SYNs but moving it elsewhere,
and making 22 totally unresponsive discourages most such attempts. This
increases
There's no security in obscurity. Automated port scanners will sweep your
system in a couple of seconds.
Tim Metzinger
From: bind-users on behalf of G.W. Haywood
via bind-users
Sent: Wednesday, October 24, 2018 12:15:10 PM
To: bind-users@lists.isc.org
Subject: Re: Question about visibility
Hi there,
On Wed, 24 Oct 2018, Hardy, Andrew wrote:
Further to the original post, as well as not creating a DNS record
and "possibly" adding robot.txt with appropriate content, as
discussed, I presume that if I run the http server on a personally
selected unprivileged port then it is very
Further to the original post, as well as not creating a DNS record and
"possibly" adding robot.txt with appropriate content, as discussed, I
presume that if I run the http server on a personally selected unprivileged
port then it is very "unlikely" the site pages will be
indexed/discovered/etc
> I've checked the serve-stale status, which is currently off.
> # rndc serve-stale status
> _default: off (stale-answer-ttl=1 max-stale-ttl=604800)
> _bind: off (stale-answer-ttl=1 max-stale-ttl=604800)
>
> Is this a normal behavior, that in the "rndc dumpdb" nevertheless the TTL in
> the form
Stern, Eli wrote:
> Using the client side of Bind in a similar manner to the "resolve"
> sample (resolve.c).
>
> How does one force the queries to be sent via a specific network device?
Look at the -b option in `lib/sample/resolve.c`.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Rockall,
On 24.10.18 09:47, Stern, Eli wrote:
Using the client side of Bind in a similar manner to the "resolve" sample
(resolve.c).
How does one force the queries to be sent via a specific network device?
E.g. using the "bind()" system call or ioctl(SO_BINDTODEVICE)?
you can only configure outgoing
Using the client side of Bind in a similar manner to the "resolve" sample
(resolve.c).
How does one force the queries to be sent via a specific network device?
E.g. using the "bind()" system call or ioctl(SO_BINDTODEVICE)?
OS: Linux.
14 matches
Mail list logo
