On 2017-01-09 06:04, David Sommerseth wrote:
On 08/01/17 05:18, jdow wrote:
And in a fairly clean (no servers) install iptables opened wide for
brief periods can be considered "safe enough".
Absolutely right! Of course you should do a security assessment before
doing it, just to have an idea of the worst possible outcome and
consider if the risk is worth it or not. But in many cases, this might
be very sensible to do.
When I can I cheat this test. The new server machine initially sits behind the
existing firewall. {^_-}
With that in mind, I have an interesting mystery here. If I am running a
nameserver open to the local network (but firewalled off and configured to only
accept local queries) on a machine at say 192.168.159.3 and place that as the
nameserver into resolv.conf it does not work. But if I tell resolv.conf to use
127.0.0.1 it works. At the same time it fails to work for the local machine a
laptop connected to it on the local net getting an appropriate address, say
192.168.159.123, can use the name server.
Now, the obvious thing to do is use "nameserver localhost". But, to ease my mind
I'd REALLY like to know why "dig" behaves dramatically differently with
resolv.conf pointing to 192.168.159.3 when I use "dig www.foobar.com" (fails) or
"dig @192.168.159.3 www.foobar.com" (succeeds). This is a headscratcher for me.
Um, of course "dig @localhost www.foobar.com" also works in all cases.
Now, if you have a
telnetd running (but --- why would you do something so stupid?) opening
the firewall is suicidal.
Yes. But there might also be misconfigured inetd/xinetd services, http
servers providing information which should be restricted, databases,
various management interfaces, etc, etc. Hence the security assessment
is a practical exercise before doing such a stunt.
Now you've touched on a singular benefit of the "old tried and true ways". (Hey,
I had no internet at all when I was young. I had to resort to ham radio for my
techie fixes. BBS systems came in my 30s. So I have a right to be a fossil.
{^_-}) A quick look at "/etc/rc.d/rc5.d" very quickly showed you what was usable
and what was not. Then another look into /etc/xinetd.d perhaps opening a few
files completed the survey. With systemctl the search is not quite so obvious or
easy to read. With the old way a K in front means it's not running and an S in
front means it is. A 5 second sweep covers the biggest set of possible holes
before you open iptables wide.
Running 'ss -lntup' gives you a pretty good idea what the consequences
might be. Of course if the box is routing traffic to other subnets,
that may also increase the risk.
Nice, but it's not a quick parse with a (sigh) traditional 80 character wide
terminal window. (Yes, 132 is the other traditional width. It's er annoying to
use as it eats screen real estate too er broadly.)
Blanket disabling both of them at once, permanently is stupid beyond
belief, IMAO.
Yes!
Some people seem to be inherently suicidal. {^_-}
OTOH the people who got in so easily might figure it's a
honeypot or something and walk away. But that's a stretch.
You're probably right, especially if the purpose of an attack was to get
insight. If it was a drive-by-bot just wanting to install a spam-bot,
crawler or similar slave node, such details can just as well be ignored
on a target system.
Isn't it a civic duty to participate in huge DDoS attacks on "The Man?"
{O,o} Yes, Joanne is feeling a little punchy this "morning". (Just got up.)
