SCIENTIFIC-LINUX-USERS Archives

January 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Mon, 9 Jan 2017 14:04:50 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
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.)

ATOM RSS1 RSS2