Hi,
Some interesting ideas here. One thing that I would say is that we are not all
networking experts. I have to admit that some of the stuff you are talking
about goes over my head. I've not had cause to look at AD in any scope. Would
it be possible to point us in the direction of a useful (in this context)
Samba4 AD beginners primer to get started?
Thanks
Andy
---- On Wed, 15 Dec 2021 09:03:25 +0000 Alejandro olivan Alvarez
<alejandro.olivan.alva...@gmail.com> wrote ----
Hi list.
I've been reading this very interesting case of vulnerability
exploit ending in disaster, in a Linux environment... with Samba
around the mess. I would like just to share some thoughts
My partners of Automation dptm. that work with Win Based
Automation systems, do often face the need to bypass security
measures/restrictions self-imposed by Win systems regarding its
native samba versions and policies. The root problem being that,
often, for the shake of simplicity and usability, the whole system
relies on usage of samba version bellow 4, often they need to work
with NAS devices using smb v1 in guest mode, or very basic
workgroup protection, not to mention absolute lack of Active
Directory. They often need to edit Windows regedit to enable older
protocols of Samba in order to work... The think is: the trend of
enforcing Samba v4 with either MS AD or Samba4 AD is there for
good reason, there're many vulnerabilities found around CIFS/SMB
protocols along the times, and its very sad that ends up affecting
our beloved Linux ecosystem.
Since inter-operation with Windows machines is a very probable
use-case to be found for Rivendell deployments (typically
Dropboxes) I'm wondering whether a good practice for a
professional setup would be to look for a tighter integration
between Rivendell and Samba4 AD and or MS AD as part of Rivendell
install (this is, at Linux OS underlying levels, already done and
commented in this mailing list) specially when no MS AD is
present, so Rivendell server could get the role of AD Server,
integrate its Users database with samba, and enforce Samba v4
protocol around (My guess is that, eventually, an existing MS AD
could setup Rivendell Samba4 Domain as a trusted domain in a
domain forest, so they could co-exist and co-operate)
Good luck.
On 12/14/21 11:20 PM, Tim Camp wrote:
Excellent points Bill. In our case we had ssh ability to get into the
secure/studio side but secured and using a unusual port, they
didn't get through that, they got in through samba and the
samba server only exported one directory where the logs were
but as you said they apparently easily hacked in through that.
This is why they only effected machines were the
ones with smb connections to the windows server that was their
entry point.
Tim
WZEW
On Tue, Dec 14, 2021, 4:06 PM
Bill Putney <mailto:bi...@wwpc.com> wrote:
If you put
your important systems in a separate IP address space and use
a firewall for a router between the office space and the
secure space,
you can dictate what you let through the firewall on a
computer by
computer and application by application basis. Don't let
things go from
your office net to your secure net unless you really have to.
If you need to look at logs, have the server on your secure
network push
(rsync) those files to an office server regularly. The
bandwidth is
free, push it every minute if you want to. If you have things
that you
routinely need to send to the server on the secure network,
put them on
the office server and have a cron job on the secure server go
and ftp
the specific file(s) you want and run a post process script on
them if
needs be.
If you need to ssh or vnc into the secure system from the
office
systems, only allow those that actually need the access and
use a
password token method like SecurID that is used once and
changes every
minute. Then if the hacker snoops the keyboard on the office
computer,
they only have a minute to make it into your secure system and
you've
limited how useful that is to them. Don't use a file sharing
mechanism
that can't support strong fencing. I think Samba is easy to
implement
and easy to hack.
I guess how much trouble you want to go to depends on how
painful it is
if you get hacked. If you are going to tighten security, be
sure to give
a lot of thought about how you're going to make it work
"easily" for the
people that routinely need access to the systems. If you make
it so
arcane and hard to deal with, you're encouraging people within
the
organization to work around the security. Then you really have
a problem
trying to keep the bad guys out.
Bill Putney - WB6RFW
District 2 Commissioner - Port of Port Townsend
Chief Engineer - KPTZ
El Jefe de Contenido - Port Townsend Film Festival
Private Pilot-Single Engine Land | Airframe & Powerplant
Mechanic / Inspection Authorization
_______________________________________________
Rivendell-dev mailing list
mailto:Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
mailto:Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
