Re: [RDD] Ransonware attack

[Brian]

One more thought... Samba is Open Source, and I think you could make a case
that mature, established, widely-used open source software is generally
less exploitable than widely-used proprietary software of any age. The
reason for this being the fact that the source code is public.

With public source code in a mature codebase, all the low-hanging fruit has
been plucked years ago. The first place a would-be exploit creator is going
to look for vulnerabilities is the source code. Same with security
researchers. The whole world can clearly see the implementation of the
software, and so with something as widely deployed as Samba, errors will be
caught swiftly by anyone from a random software engineer perusing the
codebase out of curiosity to a security researcher being paid to find
vulnerabilities in open source software. It follows from the sheer number
of eyeballs looking at the code.

Brian


On Wed, Dec 15, 2021 at 8:43 PM Brian  wrote:

> On Wed, Dec 15, 2021 at 9:02 AM Alejandro olivan Alvarez <
> alejandro.olivan.alva...@gmail.com> wrote:
>
>> Being a Linux-only user, I would add that, IMHO (and risking to be
>> polemic) nothing is more secure regarding security fixes/updates on the SMB
>> protocol than MS Itself (Windows server environment, with AD)... MS will be
>> the first to detect AND DEPLOY any security fix for MS machines via Windows
>> Updates. A Linux machine, on the other hand, can live happily with
>> older/vulnerable samba packages for ages.
>>
> I'm not sure this conclusion follows from the premises. Samba on *nix is a
> totally independent implementation of the SMB/CIFS protocols that shares
> nothing in common with the MS implementations. 99.9% of the time
> vulnerabilities like the one described aren't caused by an inherent flaw in
> the protocol itself, but on one of the implementations of the protocol. If
> the vulnerability were in the protocol itself, that would generally require
> disabling the related feature of the protocol or rolling out a new version
> of the protocol itself, not just patching a bug. The actual coding bugs
> that could be exploited are nearly always going to be totally different –
> and in totally different places – from one implementation to the next.
>
> An exploit that works against Samba is *extremely* unlikely to work
> against Windows, and an exploit that works against Windows is *extremely*
> unlikely to work against Samba.
>
> Therefore, how fast Microsoft patches a vulnerability has no bearing on
> the relative security in practice of choosing Samba.
>
> On the other hand, Microsoft has the disadvantage of being considerably
> more widely deployed as an enterprise file server than Samba on *nix – and
> therefore a much juicier target for malicious attackers to spend their time
> developing exploits for.
> (Though I admit, one might reasonably make the case that the proliferation
> of Samba on Linux-based NAS appliances might actually make it an equally
> tempting target.)
>
> I think it's likely that exploitable vulnerabilities are less commonly
> discovered in Samba than in Windows, so even if they take longer to patch,
> it may still end up being the case that there are fewer days per year that
> a vulnerability could be actively exploited on Samba than on Windows. (I
> would need to compare the frequency/severity of CVEs on both platforms,
> taking number of days unpatched into account to say with certainty)
>
> To summarize:
> * MS is going to have a lot more exploits to patch to keep up with and on
> top of.
> * The exploits that work against MS will almost never work against Samba
> and vice versa.
> * Logically, the swiftness of Microsoft patching vulnerabilities in
> Windows has nothing to say one way or the other about the relative security
> of a Samba deployment.
>
> Brian
>
>
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Brian]

On Wed, Dec 15, 2021 at 9:02 AM Alejandro olivan Alvarez <
alejandro.olivan.alva...@gmail.com> wrote:

> Being a Linux-only user, I would add that, IMHO (and risking to be
> polemic) nothing is more secure regarding security fixes/updates on the SMB
> protocol than MS Itself (Windows server environment, with AD)... MS will be
> the first to detect AND DEPLOY any security fix for MS machines via Windows
> Updates. A Linux machine, on the other hand, can live happily with
> older/vulnerable samba packages for ages.
>
I'm not sure this conclusion follows from the premises. Samba on *nix is a
totally independent implementation of the SMB/CIFS protocols that shares
nothing in common with the MS implementations. 99.9% of the time
vulnerabilities like the one described aren't caused by an inherent flaw in
the protocol itself, but on one of the implementations of the protocol. If
the vulnerability were in the protocol itself, that would generally require
disabling the related feature of the protocol or rolling out a new version
of the protocol itself, not just patching a bug. The actual coding bugs
that could be exploited are nearly always going to be totally different –
and in totally different places – from one implementation to the next.

An exploit that works against Samba is *extremely* unlikely to work against
Windows, and an exploit that works against Windows is *extremely* unlikely
to work against Samba.

Therefore, how fast Microsoft patches a vulnerability has no bearing on the
relative security in practice of choosing Samba.

On the other hand, Microsoft has the disadvantage of being considerably
more widely deployed as an enterprise file server than Samba on *nix – and
therefore a much juicier target for malicious attackers to spend their time
developing exploits for.
(Though I admit, one might reasonably make the case that the proliferation
of Samba on Linux-based NAS appliances might actually make it an equally
tempting target.)

I think it's likely that exploitable vulnerabilities are less commonly
discovered in Samba than in Windows, so even if they take longer to patch,
it may still end up being the case that there are fewer days per year that
a vulnerability could be actively exploited on Samba than on Windows. (I
would need to compare the frequency/severity of CVEs on both platforms,
taking number of days unpatched into account to say with certainty)

To summarize:
* MS is going to have a lot more exploits to patch to keep up with and on
top of.
* The exploits that work against MS will almost never work against Samba
and vice versa.
* Logically, the swiftness of Microsoft patching vulnerabilities in Windows
has nothing to say one way or the other about the relative security of a
Samba deployment.

Brian
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Fred Gleason]

On Dec 15, 2021, at 12:02, Alejandro olivan Alvarez 
 wrote:
> If you look at debian security repo packages notes, and you look for samba, 
> you will find that, for the last vulnerability, found this 2021, only the 
> packaged sources for Debian Stable, testing and Sid have being patched with 
> the fix uploaded in samba.org . Older packaged versions, 
> including buster (which was stable until well within 2021) have not (probably 
> they can't due to aging code) been patched and are marked as 'vulnerable’.
> 
The situation it a bit different under RHEL-based distros (including CentOS). 
There, Redhat typically back ports security fixes into the version of the 
affected package being used on the distro, thus preserving ABI compatibility 
(which is, after all, one of the major reasons for having an ‘Enterprise’ 
distro at all). This is why the base version of the kernel on an RHEL system 
usually looks ancient, yet still has all known vulnerabilities patched; Redhat 
back ports the kernel fixes.

> Samba/Windows/SMB/etc has its vulnerabilities, like many other software, but 
> the difference here is that, the attack surface is far greater, since, out of 
> the dark, Windows computers become potential backdoors for our Linux 
> ecosystem.
> 
> Being a Linux-only user, I would add that, IMHO (and risking to be polemic) 
> nothing is more secure regarding security fixes/updates on the SMB protocol 
> than MS Itself (Windows server environment, with AD)... MS will be the first 
> to detect AND DEPLOY any security fix for MS machines via Windows Updates. A 
> Linux machine, on the other hand, can live happily with older/vulnerable 
> samba packages for ages.
> 
Totally agree.

> If I had to think of an ideal mixed Win-Linux environment for ease Dropbox 
> upload/ingestion, my recommendation would be to have a Rivendell machines 
> connecting as clients to a Windows Server, under AD (which is possible at OS 
> level, but I recall maybe it is not for rdimport/export/etc ), and mount the 
> remote share to read/ingest dropboxes, while the rest of the Win machines 
> mounting the same share to do the uploads. This way, all the Win files would 
> stay contained within the windows environment, subject to AD handshake all 
> the time and possibly under antivirus scrutiny... as we say here 'Juntos, 
> pero no revueltos' (toghether, but not mixed)
> 
I’ve seen sites do this. It works quite well. The downside is extra complexity 
with the concomitant reduction of overall reliability (two machines instead of 
one to break down, etc).

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| A room without books is like a body without a soul. |
| |
| -- Cicero   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Alejandro olivan Alvarez]

I would like to share some other thoughs here.

If you look at debian security repo packages notes, and you look for 
samba, you will find that, for the last vulnerability, found this 2021, 
only the packaged sources for Debian Stable, testing and Sid have being 
patched with the fix uploaded in samba.org. Older packaged versions, 
including buster (which was stable until well within 2021) have not 
(probably they can't due to aging code) been patched and are marked as 
'vulnerable'.


Samba/Windows/SMB/etc has its vulnerabilities, like many other software, 
but the difference here is that, the attack surface is far greater, 
since, out of the dark, Windows computers become potential backdoors for 
our Linux ecosystem.


Being a Linux-only user, I would add that, IMHO (and risking to be 
polemic) nothing is more secure regarding security fixes/updates on the 
SMB protocol than MS Itself (Windows server environment, with AD)... MS 
will be the first to detect AND DEPLOY any security fix for MS machines 
via Windows Updates. A Linux machine, on the other hand, can live 
happily with older/vulnerable samba packages for ages.


If I had to think of an ideal mixed Win-Linux environment for ease 
Dropbox upload/ingestion, my recommendation would be to have a Rivendell 
machines connecting as clients to a Windows Server, under AD (which is 
possible at OS level, but I recall maybe it is not for 
rdimport/export/etc ), and mount the remote share to read/ingest 
dropboxes, while the rest of the Win machines mounting the same share to 
do the uploads. This way, all the Win files would stay contained within 
the windows environment, subject to AD handshake all the time and 
possibly under antivirus scrutiny... as we say here 'Juntos, pero no 
revueltos' (toghether, but not mixed)


Cheers.

On 12/15/21 5:21 PM, Fred Gleason wrote:
On Dec 15, 2021, at 04:09, Andy Higginson > wrote:


Fred, is building some more security into the system something that 
could be incorporated into the Rivendell 4 build/setup while it is 
still in Beta?


As far as the installers are concerned, there are two main goals that 
we try to achieve:


1) Provide a “good experience”, in particular, a working, functional 
setup “out of the box” so that new users can see what Rivendell is and 
is capable of.


2) Install a good foundation, one that is reasonably secure, easy to 
update and to maintain according to industry best practices.


To an extent, these two goals tend to work against each other, 
especially with regard to the ’security’ metric. The first questions 
any new Rivendell user asks after getting the installer to work and 
playing the Test Tone cart typically are:


How do I load audio into this thing?

How do I get schedules (“logs”) into this thing?

How do I get as-played data out of this thing?

Or, in general: how do I transfer data in/out?

Given that our putative new user typically has limited (if any) Linux 
knowledge and indeed, limited or no formal IT experience at all, as 
well as that, in the overwhelming majority of cases, the data that 
these new users want to use resides on one or more Windows systems, 
our traditional approach for facilitating data transfer has been to 
provision, by default, a set of CIFS shares configured to allow 
‘guest’ access. That makes them easy to find and access by the typical 
moderately-knowledgeable Windows user. Unfortunately, it also makes 
them easy to find and access by the Black Hats if (when?) they manage 
to get access to the LAN to which the system is connected. Yes, the 
permissions on those shares can be tightened after installation so as 
to allow only users with the actual need for access to do so, but how 
many new users know how to do that? How many know that it’s even 
*necessary* to do that?


This is the fundamental tension that we have to deal with when setting 
up default installation environments. Sure, we could refrain from 
installing Samba and wind up with a more ‘secure’ setup, but only at 
the price of the user having to configure the requisite access (NFS? 
Remote mount a CIFS share on a Windows box? Install Samba?) All 
doable, but in no case immediately obvious for the average new user. 
For that user, doing any of those things is going to amount to getting 
thrown into the deep end of a very cold pool.


I guess, at the least, we could call out these sorts of issues in the 
‘Final Steps’ section of the instructions, along with pointers for 
various resources.

Cheers!


|-|
| Frederick F. Gleason, Jr. |             Chief Developer         |
|                           |             Paravel Systems         |
|-|
|   Real Users never know what they want, but they always know when   |
|   your program doesn't deliver it.         |
|         |
|                                                     -- 

Re: [RDD] Ransonware attack

[Fred Gleason]

On Dec 15, 2021, at 11:08, Bill Putney  wrote:
> Or to paraphrase Nancy Reagan "Just say NO to Windows.”
> 
Easy to say, but the awkward fact is that (AFAICT) nearly 100% of commercial 
scheduler systems (music and traffic) are Windows-based. The only exception 
that I know of (Jim Hardy’s ‘TrafficLight’ system) received a decidedly tepid 
response when he did a Linux-based release back in 2015. In audio production 
tools the situation is not quite so bleak (Ardour is a true pro-grade DAW, 
while there is the ever popular, and problematic, Audacity), but that’s an area 
where people tend to have their favorite tool and be highly resistant to 
change. And many if not most of those systems are Windows-based. (Heck, I know 
of one major Rivendell site that still uses, and loves, CoolEdit 2003. “Out of 
my cold, dead hands!”)

So, just saying “Interfacing with Windows isn’t supported” isn’t in the cards 
if you expect to be an actually relevant, viable option in Broadcast Automation.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| A program is a lot like a nose. Sometimes it runs, and sometimes it |
| blows.  |
| |
|  -- The Illiterati Programus, Canto I   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Compiling Rivendell

[Alejandro olivan Alvarez]

Hi.

I remember that issue in my early attempts to build debian Buster (then 
stable release) packages for rivendell 3.x


Apparently, CentOS 7 (I guess that came from previous) shipped 
versions/defaults for the building/linker environment allowed for math 
libraries not needed to be declared in tha header files, while in Buster 
(and I asume that's the trend for newer versions) that wasn't the case.


The way I solved that was by quilt patching the sources adding the math 
library on the troublesome files (don't recall on it).


As Rivendell is evolving under the qt5 branches towards more recent 
systems, I remember at some point Fred wiped out all those errors 
rendering all my tricks and hacks unnecessary... so, you may search in 
the commits to for math/pow10 building issues to get how to patch the code.


I think I still keep my notes on it...I will search for them just in case.

Regards.


On 12/15/21 5:14 PM, le père Léon wrote:

Le 10/12/2021 à 23:15, Tim Camp a écrit :

I remember this coming up before and have found some discussion on it,
but what is the final determination of what to do about pow10 in cae
causing make to error out?

http://caspian.paravelsystems.com/pipermail/rivendell-dev/2018-July/026975.html



___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Fred Gleason]

On Dec 15, 2021, at 04:09, Andy Higginson  wrote:

> Fred, is building some more security into the system something that could be 
> incorporated into the Rivendell 4 build/setup while it is still in Beta?

As far as the installers are concerned, there are two main goals that we try to 
achieve:

1) Provide a “good experience”, in particular, a working, functional setup “out 
of the box” so that new users can see what Rivendell is and is capable of.

2) Install a good foundation, one that is reasonably secure, easy to update and 
to maintain according to industry best practices.

To an extent, these two goals tend to work against each other, especially with 
regard to the ’security’ metric. The first questions any new Rivendell user 
asks after getting the installer to work and playing the Test Tone cart 
typically are:

How do I load audio into this thing?

How do I get schedules (“logs”) into this thing?

How do I get as-played data out of this thing?

Or, in general: how do I transfer data in/out?

Given that our putative new user typically has limited (if any) Linux knowledge 
and indeed, limited or no formal IT experience at all, as well as that, in the 
overwhelming majority of cases, the data that these new users want to use 
resides on one or more Windows systems, our traditional approach for 
facilitating data transfer has been to provision, by default, a set of CIFS 
shares configured to allow ‘guest’ access. That makes them easy to find and 
access by the typical moderately-knowledgeable Windows user. Unfortunately, it 
also makes them easy to find and access by the Black Hats if (when?) they 
manage to get access to the LAN to which the system is connected. Yes, the 
permissions on those shares can be tightened after installation so as to allow 
only users with the actual need for access to do so, but how many new users 
know how to do that? How many know that it’s even *necessary* to do that?

This is the fundamental tension that we have to deal with when setting up 
default installation environments. Sure, we could refrain from installing Samba 
and wind up with a more ‘secure’ setup, but only at the price of the user 
having to configure the requisite access (NFS? Remote mount a CIFS share on a 
Windows box? Install Samba?) All doable, but in no case immediately obvious for 
the average new user. For that user, doing any of those things is going to 
amount to getting thrown into the deep end of a very cold pool.

I guess, at the least, we could call out these sorts of issues in the ‘Final 
Steps’ section of the instructions, along with pointers for various resources.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
|   Real Users never know what they want, but they always know when   |
|   your program doesn't deliver it.  |
| |
|  -- Anonymous   |
|-|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Compiling Rivendell

[le père Léon]

Le 10/12/2021 à 23:15, Tim Camp a écrit :
> I remember this coming up before and have found some discussion on it,
> but what is the final determination of what to do about pow10 in cae
> causing make to error out?

http://caspian.paravelsystems.com/pipermail/rivendell-dev/2018-July/026975.html


-- 
Léon.

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Bill Putney]

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 + *Alejandro olivan Alvarez 
* 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  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
 

Re: [RDD] Ransonware attack

[Alejandro olivan Alvarez]

On 12/15/21 10:16 AM, Andy Higginson wrote:

Hi,

Some interesting ideas here.  One thing that I would say is that we 
are not all networking experts.


This December my last CISCO certification ends, and I'm not going to 
re-cert... and for a good reason: On the 10 years I've been working in 
my current job, only in one case, the entity, budget and complexity of 
the customer (A public/national radio network) networking infrastructure 
made applicable my CCNA/CCNP knowledge. In all other cases, I rarely 
find anything beyond a simple, flat, L2 broadcast domain (i.e a cheap 
un-managed or very simple managed switch with no data VLANs)... But 
here's the thing:


Once you gained access to a Linux (or windows, I guess, but I'm Linux 
user) host, it is VERY EASY to exploit a Layer 2 (VLANs) deployment by 
several techniques (I'm thinking on just a simple python script to scan 
for VLAN hopping exploit, to say a kiddies one) unless the network 
devices do feature AND have configured/enabled several security features 
(ARP spoofing, DHCP snooping, port security policies, etc, etc). That 
requires knowledge and usage of more expensive gear. But the thing is 
that, preventing of an attacker to gain access of an internal host in 
the first place is, by far, the single, most important point to put the 
focus on.



  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?


I like the onion/layered principle for a security approach, and, since 
network deployments can largely vary from organization and organization 
(and is something kinda 'external' to the software level) I like the 
idea of strengthening or provide guidelines for securing Rivendell 
deployments at the immediate practical use-case, software level.


Regarding SAMBA, AD and Rivendell, I think the very early measure would 
be to focus on securing SAMBA on its own (Rivendell/AD integration is 
something more of a Quality of Life than of security, and thus, of 
secondary order) on deployments where Dropboxes have to co-exist with 
Windows machines... The problem is that there are several 
use-cases/scenarios and the approach may differ from case to case (who's 
sharing? a Linux box? a win box? a NAS? are all Dropboxes in a 
centralized share? do Machines share on their own? is there an AD in 
place?...)


Best regards.



Thanks

Andy




 On Wed, 15 Dec 2021 09:03:25 + *Alejandro olivan Alvarez 
* 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 

Re: [RDD] Ransonware attack

[Andy Higginson]

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 + Alejandro olivan Alvarez 
 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  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 

Re: [RDD] Ransonware attack

[Andy Higginson]

Hi,





Reading through all of this, it sounds like it would be useful for there to be 
a wider discussion over how to configure a Rivendell (or other) playout system 
in a way that gives maximum protection to the audio network, whilst allowing 
users to be able to access the Rivendell system to be able to upload logs, 
audio etc.  From this, we could add some articles to the Wiki that would help 
others to be able to setup a secure system.  It would also be a good refresher 
to those of us who have existing systems in use and need to secure them.



Fred, is building some more security into the system something that could be 
incorporated into the Rivendell 4 build/setup while it is still in Beta?



Thanks



Andy___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Alejandro olivan Alvarez]

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 > 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