Or to paraphrase Nancy Reagan "Just say NO to Windows."

Let's look at solving this from the problem causing end. Hackers are flying blind unless it's an inside the organization attack. Anything you do to not be the normal Windoz way of doing things is going to make it really hard for them to figure out.

There are windows utilities that allow mounting *nix file systems. If it's something you just can't find it in your heart to disallow, at least just put the *nix utilities only on the Windoz computers that need file access and don't turn on Samba anything on the Rivendell machines.

- Bill

On 12/15/21 1:16 AM, Andy Higginson wrote:
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 <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
            Rivendell-dev@lists.rivendellaudio.org
            http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


        _______________________________________________
        Rivendell-dev mailing list
        Rivendell-dev@lists.rivendellaudio.org  
<mailto:Rivendell-dev@lists.rivendellaudio.org>
        http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev  
<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

--
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
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Reply via email to