Re: laptop protection in an office network
Hi.
On Sat, 29 Aug 2015 20:40:47 +0100
Brian <ad44@cityscape.co.uk> wrote:
> On Sat 29 Aug 2015 at 22:18:00 +0300, Reco wrote:
>
> > Hi.
> >
> > On Sat, 29 Aug 2015 20:01:40 +0100
> > Brian <ad44@cityscape.co.uk> wrote:
> >
> > > On Sat 29 Aug 2015 at 21:39:21 +0300, Reco wrote:
> > >
> > > > Hi.
> > > >
> > > > On Sat, 29 Aug 2015 13:25:28 -0500
> > > > rlharris@oplink.net wrote:
> > > >
> > > > > On Sat, August 29, 2015 6:53 am, tomas@tuxteam.de wrote:
> > > > > > Also netstat (issued from your laptop) gives insight. For example
> > > > > > 'netstat - -lntu' shows you the TCP or UDP listening sockets. If you are
> > > > > > root (or sudo, of course), the extra option -p tells you which process is
> > > > > > "at the other side" listening.
> > > > > >
> > > > > > Note that the dhcp client itself (which you need to get an IP address to
> > > > > > take part in your customer's network) puts you already at some risk,
> > > > > > depending on how it's configured.
> > > > >
> > > > > Here is the output from the laptop:
> > > > >
> > > > > # netstat -lntup
> > > > > Active Internet connections (only servers)
> > > > > Prot Rec Snd Local Address Foreign State PID/Program name
> > <skip>
> > > > > #
> > > > >
> > > > > Regrettably, the formatting of the output does not consider the need to
> > > > > include the output in the body of an e-mail, so editing was required to
> > > > > remove excess spaces so as to prevent every line from being wrapped.
> > > >
> > > >
> > > > Something like this should save you from the most troubles provided
> > > > that you don't plan to use your laptop as a print server or NFS:
> > > >
> > <skip>
> > > >
> > > >
> > > > Of course, it's *very* simplistic set of rules (for example, someone
> > > > may consider accepting ssh connections from arbitrary hosts a bad idea),
> > > > but it should work.
> > >
> > > Why does he need any iptables rules? I see nothing at risk there. It
> > > seems to me he can be confident his computer is safe.
> >
> > You need to look better. As of now, this laptop:
> >
> > 1) Has NFS portmapper open for no good reason.
> >
> > 2) Has some (possibly badly configured) tcp service port 9999.
> >
> > 3) Has possibly misconfigured SSH (i.e. PasswordAuthentication yes - a
> > bad idea for untrusted network).
>
> Covering up such problems with iptables doesn't tackle such problems.
On the contrary, it does. Since nobody can connect to the problem
service from the outside - it's irrelevant whenever the service is
secure or not.
> Why not fix them at source?
I dunno. Some people are reluctant to remove stuff. Especially if the
"stuff" in question is installed by "Standard" task of d-i.
Adding stuff on top of "standard" installation is easier to grasp.
> > > > Two things I'm unsure of are:
> > > >
> > > > 1) Avahi's udp 5353. I don't see any value in mDNS (especially in office
> > > > network), but YMMV.
> > >
> > > There is much value in mDNS in an office network with CUPS nowadays.
> >
> > Provided that an office network allows multicasts *and* it's not a
> > all-Windows shop *and* they did not forget to allow dnssd server-side -
> > it's a possibility. Chances for all this are slim IMO.
>
> No mDNS then. No printing.
Clarification needed.
Are you suggesting that disabling Avahi also disables CUPS? It's not
true.
Are you suggesting that with disabling Avahi CUPS looses ability to
print? It's not true too.
Or are you suggesting that with Avahi disabled a client is unable to
print using *known* CUPS over the network? It's also a false statement.
Reco
Reply to: