Re: [RDD] Ransonware attack

[Jake Tremper]

Seems reasonable, especially if you are doing key-only auth and keep your
SSH servers patched. I also like to use fail2ban or CSF + geoip filtering
to further cut down the flood profile.

On Fri, Dec 17, 2021 at 3:00 PM Rob Landry <41001...@interpring.com> wrote:

>
> What about reverse SSH tunnels? I use those, rather than VLANs, to access
> remote sites. A remote host ssh's to my machine and sets up a tunnel I
> can use to access the remote host, and from there, any other machine I
> need to access at the site.
>
>
> Rob
>
> --
> Не думай что всё пропели,
> Что бури все отгремели;
> Готовься к великой цели,
> А слава тебя найдёт.
>
>
> On Wed, 15 Dec 2021, Alejandro olivan Alvarez wrote:
>
> >
> >
> > 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 

Re: [RDD] Ransonware attack

[Rob Landry]

On Wed, 15 Dec 2021, Bill Putney wrote:


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


"I don't do Windows", except when I have to. In our company, amost 
everything is on Linux, but the traffic system requires Windows, so there 
is a Windows machine set up for that. There is another one at one station 
that retrieves segments of syndicated shows from a network.


It occurs to me that one answer might be to run Windows in a virtual 
machine on a Linux host, leaving the Linux host to manage all of the 
networking. But I've yet to try that.



Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.



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 

Re: [RDD] Ransonware attack

[Rob Landry]

What about reverse SSH tunnels? I use those, rather than VLANs, to access 
remote sites. A remote host ssh's to my machine and sets up a tunnel I 
can use to access the remote host, and from there, any other machine I 
need to access at the site.



Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.


On Wed, 15 Dec 2021, Alejandro olivan Alvarez wrote:




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 

Re: [RDD] Ransonware attack

[Fred Gleason]

On Dec 15, 2021, at 23:51, Brian  wrote:

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

One would hope. But, take a look at the currently unfolding horror-show with 
Log2j. That is a FOSS project, *very* widely deployed by Java shops, and had an 
egregious, easily exploitable zero-day flaw (severity level 10 out of 10) 
sitting in the open for years, but discovered only a few weeks ago.

(And before you ask: no, Rivendell does not use Java, and is not vulnerable to 
the Log2j flaw). :)

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

[Fred Gleason]

On Dec 15, 2021, at 23:43, Brian  wrote:

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

CIFS/SMB has historically had its share of both (flaws in the protocol as well 
as in an implementation). But overall you are correct - a flaw in one 
implementation will rarely if ever carry over to another (assuming that the two 
codebases are completely independent).

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| Every program has at least one bug and can be shortened by at   |
| least one instruction -- from which, by induction, one can deduce   |
| that every program can be reduced to one instruction which doesn't  |
| work.   |
| |
|  -- Anonymous   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[drew Roberts]

Crazy idea to follow...

On Wed, Dec 15, 2021 at 11:37 AM Fred Gleason 
wrote:

snip

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

Well, there's a good chance it is crazy... or at least overcomplicated for
little or no gain...

Don't set up samba and shares on the Riv instance.

Instead, set up a virtual machine. In the VM, put a stripped down version
of the OS on the riv machine or even a tiny/security distro. Configure
samba and the shares in the VM. Rsync in both directions between the samba
directories in the VM and matching directories on the RIV machine. Perhaps
watch the directories on both sides and initiate the rsyncs when the
dirs/files change.

As an install or post install option, set up the samba stuff on an actual
separate box and not in a VM.

all the best,

drew
-- 
Enjoy the *Paradise Island Cam* playing
*Bahamian Or Nuttin* - https://www.paradiseislandcam.com/
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Rich Gattie]

While this is no doubt a big headache and a ton of work for Tim, and I
empathize, this is also a very good discussion to help others avoid this.
I think this would make for a great page on the Wiki to have some of these
suggested measures available for everyone to have ready access to.

I only am wondering if it should be it's own subject/parent page or a child
page to like planning an installation.


73.
--Rich



On Wed, Dec 15, 2021 at 11:52 PM Brian  wrote:

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


-- 
-=:{ Rich Gattie, KB2MOB }:=-
Email: mob...@gmail.com
Web: http://x1radio.net
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

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

Re: [RDD] Ransonware attack

[Gavin Stephens]

As silly as it sounds, that's exactly how I get external files to my RD 
box from Windows, albeit USB HDD. It used to be via secure FTP only and 
limited to the IP of a particular Windows box. But I don't need remote 
access so I can get away with this.


The only Ethernet connection RD has is a separate subnet which also does 
share a different port on an Internet router with an NTP server on it, 
everything else blocked. So this could be a weak link.


On the Windows side, I don't use the "Server" or computer 
browser/netbios stuff for MS file sharing at all. I just don't trust it 
even for the convenience of drag and dropping files from a folder to a 
mapped drive.


Gav.

On 15/12/2021 7:51 am, Tim Camp wrote:
Well according to the forensics that have been done there is a nmb 
hack that works with with samba that allows one to use samba to place 
a ssh key on the samba connected machine and thus gain ssh root access.
I found out the computer science dept at the local university even 
demonstrates how this is done in one of their classes.
I have been advised to use read only nfs shares for connected windows 
boxes for reconciliation and the safest way to get the traffic and 
music logs seems to be to carry it down the hall on a usb. :)

The Secret Service cyber attack team that came here hates windows.
If not for the connected windows box I don't believe they ever would 
have gotten into the studio side of the network.


Tim
WZEW




On Tue, Dec 14, 2021 at 12:10 PM Rob Landry <41001...@interpring.com> 
wrote:


On Fri, 10 Dec 2021, Jake Tremper wrote:

> 2) Network segregation. An infection on the business side is
awful and
> hard to recover from. An infection on the business side that
jumps and
> wipes out the on-air machines is catastrophic. Isolated VLANs, when
> implemented properly, help greatly in this area.

The problem, unfortunately, is that a traffic machine has to be
able to
write a log file to the automation, and read aired log files from
it for
electronic reconciliation.

Traffic machines are typically on the office network, and are used
for
things like email.

Music scheduling software typically also runs on an office machine.
Programming people are forever getting songs and syndicated shows
off the
Internet to add to the audio library.

Both of these are potential malware vectors into an automation
systems.

The question is: even if someone exploits Samba to drop something
onto a
Rivendell machine, it goes into a Samba-writable folder, not
/var/snd. How
did they leverage that into access to other folders?


Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.


> and, not directly related to this one, but a good concept:
>
> 3) Untested backups are not backups. Test your backups
periodically and
> verify that you can actually recover from them.
>
> On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
>       Greetings,
> This past Sunday morning our four station had a cyber attack.
> They gained access through a windows server that we use for traffic
> and bookkeeping.
> Through this connection they exploited samba to place ssh keys
on many
> of our linux machines and erased all files on the control room pc's
> and erased /var/snd on our nfs server.
>
> They encrypted the windows server for ransome and just erased the
> linux machines they got access to.
>
> Trying to rebuild four radio stations from the ground up.
> We had backup on several drives but they were on the network so they
> got them as well.
>
> One issue if someone can help me with.
> I have recompiled rivendell on two control rooms and everything
works
> except no audio and no meters, Carts act like they are playing
but no
> output. I'm sure I have overlooked something, I've been up for days.
>
> Warning to all that Samba is a weak spot.
>
> Tim Camp
> WZEW-FM
> Mobile, Al.
>
>
>
>
>
> ___
> 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___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Tim Camp]

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

Re: [RDD] Ransonware attack

[Bill Putney]

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

Re: [RDD] Ransonware attack

[Fred Gleason]

On Dec 14, 2021, at 14:14, Rob Landry <41001...@interpring.com> wrote:

> USB keys can carry malware, too.
> 
> But more importantly, there's no one here to carry one. They're all working 
> from home.
> 
> It sounds like Samba needs to be disabled.

That can be done, by putting the contents of the ‘utility’ directories 
(‘/home/rd/traffic_export/’, ‘/home/rd/music_export/’, etc) on a completely 
different host (a Windows-based one would work fine) and mounting those shares 
remotely. That would greatly reduce the attack surface on the Rivendell system.

As for ‘/var/snd’, it’s a Really Bad Idea to have that mapped through Samba, 
even read-only. It’s isolated from direct user access for a reason.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| When playing Russian roulette the fact that the first shot got off  |
| safely is little comfort for the next.  |
| |
| -- Robert F. Feynman|
| "Personal Observations on the Reliability of the Shuttle"   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Rob Landry]

USB keys can carry malware, too.

But more importantly, there's no one here to carry one. They're all 
working from home.


It sounds like Samba needs to be disabled.


Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.


On Tue, 14 Dec 2021, Tim Camp wrote:


Well according to the forensics that have been done there is a nmb hack that
works with with samba that allows one to use samba to place a ssh key on the
samba connected machine and thus gain ssh root access.I found out the
computer science dept at the local university even demonstrates how this is
done in one of their classes.
I have been advised to use read only nfs shares for connected windows boxes
for reconciliation and the safest way to get the traffic and music logs
seems to be to carry it down the hall on a usb. :)
The Secret Service cyber attack team that came here hates windows.
If not for the connected windows box I don't believe they ever would have
gotten into the studio side of the network.

Tim
WZEW




On Tue, Dec 14, 2021 at 12:10 PM Rob Landry <41001...@interpring.com> wrote:
  On Fri, 10 Dec 2021, Jake Tremper wrote:

  > 2) Network segregation. An infection on the business side is
  awful and
  > hard to recover from. An infection on the business side that
  jumps and
  > wipes out the on-air machines is catastrophic. Isolated VLANs,
  when
  > implemented properly, help greatly in this area.

  The problem, unfortunately, is that a traffic machine has to be
  able to
  write a log file to the automation, and read aired log files
  from it for
  electronic reconciliation.

  Traffic machines are typically on the office network, and are
  used for
  things like email.

  Music scheduling software typically also runs on an office
  machine.
  Programming people are forever getting songs and syndicated
  shows off the
  Internet to add to the audio library.

  Both of these are potential malware vectors into an automation
  systems.

  The question is: even if someone exploits Samba to drop
  something onto a
  Rivendell machine, it goes into a Samba-writable folder, not
  /var/snd. How
  did they leverage that into access to other folders?


  Rob

  --
  Не думай что всё пропели,
  Что бури все отгремели;
  Готовься к великой цели,
  А слава тебя найдёт.


  > and, not directly related to this one, but a good concept:
  >
  > 3) Untested backups are not backups. Test your backups
  periodically and
  > verify that you can actually recover from them.
  >
  > On Fri, Dec 10, 2021 at 12:42 PM Tim Camp 
  wrote:
  >       Greetings,
  > This past Sunday morning our four station had a cyber attack.
  > They gained access through a windows server that we use for
  traffic
  > and bookkeeping.
  > Through this connection they exploited samba to place ssh keys
  on many
  > of our linux machines and erased all files on the control room
  pc's
  > and erased /var/snd on our nfs server.
  >
  > They encrypted the windows server for ransome and just erased
  the
  > linux machines they got access to.
  >
  > Trying to rebuild four radio stations from the ground up.
  > We had backup on several drives but they were on the network
  so they
  > got them as well.
  >
  > One issue if someone can help me with.
  > I have recompiled rivendell on two control rooms and
  everything works
  > except no audio and no meters, Carts act like they are playing
  but no
  > output. I'm sure I have overlooked something, I've been up for
  days.
  >
  > Warning to all that Samba is a weak spot.
  >
  > Tim Camp
  > WZEW-FM
  > Mobile, Al.
  >
  >
  >
  >  
  >
  > ___
  > 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

Re: [RDD] Ransonware attack

[Jake Tremper]

Sure, but none of these are use-cases where the (infection vector) office
machine would need read/write access to the *audio* files in /var/snd on a
Rivendell box, or the ability to *write* to the Rivendell DB, or access to
home dirs & SSH keys on a Rivendell machine, or access to the backups.
Maybe you wouldn't use VLANs in this case, but there are certainly robust
access controls for SSH, NFS, Samba, etc. that can be used to stop your
average "smash and grab" style data vandal from c99'ing or maliciously
keying your Rivendell machines. If you view your systems through the lense
of PoLP (https://en.wikipedia.org/wiki/Principle_of_least_privilege), you
end up light years ahead of many broadcast facilities, unfortunately.

On Tue, Dec 14, 2021 at 1:11 PM Rob Landry <41001...@interpring.com> wrote:

> On Fri, 10 Dec 2021, Jake Tremper wrote:
>
> > 2) Network segregation. An infection on the business side is awful and
> > hard to recover from. An infection on the business side that jumps and
> > wipes out the on-air machines is catastrophic. Isolated VLANs, when
> > implemented properly, help greatly in this area.
>
> The problem, unfortunately, is that a traffic machine has to be able to
> write a log file to the automation, and read aired log files from it for
> electronic reconciliation.
>
> Traffic machines are typically on the office network, and are used for
> things like email.
>
> Music scheduling software typically also runs on an office machine.
> Programming people are forever getting songs and syndicated shows off the
> Internet to add to the audio library.
>
> Both of these are potential malware vectors into an automation systems.
>
> The question is: even if someone exploits Samba to drop something onto a
> Rivendell machine, it goes into a Samba-writable folder, not /var/snd. How
> did they leverage that into access to other folders?
>
>
> Rob
>
> --
> Не думай что всё пропели,
> Что бури все отгремели;
> Готовься к великой цели,
> А слава тебя найдёт.
>
>
> > and, not directly related to this one, but a good concept:
> >
> > 3) Untested backups are not backups. Test your backups periodically and
> > verify that you can actually recover from them.
> >
> > On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
> >   Greetings,
> > This past Sunday morning our four station had a cyber attack.
> > They gained access through a windows server that we use for traffic
> > and bookkeeping.
> > Through this connection they exploited samba to place ssh keys on many
> > of our linux machines and erased all files on the control room pc's
> > and erased /var/snd on our nfs server.
> >
> > They encrypted the windows server for ransome and just erased the
> > linux machines they got access to.
> >
> > Trying to rebuild four radio stations from the ground up.
> > We had backup on several drives but they were on the network so they
> > got them as well.
> >
> > One issue if someone can help me with.
> > I have recompiled rivendell on two control rooms and everything works
> > except no audio and no meters, Carts act like they are playing but no
> > output. I'm sure I have overlooked something, I've been up for days.
> >
> > Warning to all that Samba is a weak spot.
> >
> > Tim Camp
> > WZEW-FM
> > Mobile, Al.
> >
> >
> >
> >
> >
> > ___
> > 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
>
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ransonware attack

[Tim Camp]

Well according to the forensics that have been done there is a nmb hack
that works with with samba that allows one to use samba to place a ssh key
on the samba connected machine and thus gain ssh root access.
I found out the computer science dept at the local university even
demonstrates how this is done in one of their classes.
I have been advised to use read only nfs shares for connected windows boxes
for reconciliation and the safest way to get the traffic and music logs
seems to be to carry it down the hall on a usb. :)
The Secret Service cyber attack team that came here hates windows.
If not for the connected windows box I don't believe they ever would have
gotten into the studio side of the network.

Tim
WZEW




On Tue, Dec 14, 2021 at 12:10 PM Rob Landry <41001...@interpring.com> wrote:

> On Fri, 10 Dec 2021, Jake Tremper wrote:
>
> > 2) Network segregation. An infection on the business side is awful and
> > hard to recover from. An infection on the business side that jumps and
> > wipes out the on-air machines is catastrophic. Isolated VLANs, when
> > implemented properly, help greatly in this area.
>
> The problem, unfortunately, is that a traffic machine has to be able to
> write a log file to the automation, and read aired log files from it for
> electronic reconciliation.
>
> Traffic machines are typically on the office network, and are used for
> things like email.
>
> Music scheduling software typically also runs on an office machine.
> Programming people are forever getting songs and syndicated shows off the
> Internet to add to the audio library.
>
> Both of these are potential malware vectors into an automation systems.
>
> The question is: even if someone exploits Samba to drop something onto a
> Rivendell machine, it goes into a Samba-writable folder, not /var/snd. How
> did they leverage that into access to other folders?
>
>
> Rob
>
> --
> Не думай что всё пропели,
> Что бури все отгремели;
> Готовься к великой цели,
> А слава тебя найдёт.
>
>
> > and, not directly related to this one, but a good concept:
> >
> > 3) Untested backups are not backups. Test your backups periodically and
> > verify that you can actually recover from them.
> >
> > On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
> >   Greetings,
> > This past Sunday morning our four station had a cyber attack.
> > They gained access through a windows server that we use for traffic
> > and bookkeeping.
> > Through this connection they exploited samba to place ssh keys on many
> > of our linux machines and erased all files on the control room pc's
> > and erased /var/snd on our nfs server.
> >
> > They encrypted the windows server for ransome and just erased the
> > linux machines they got access to.
> >
> > Trying to rebuild four radio stations from the ground up.
> > We had backup on several drives but they were on the network so they
> > got them as well.
> >
> > One issue if someone can help me with.
> > I have recompiled rivendell on two control rooms and everything works
> > except no audio and no meters, Carts act like they are playing but no
> > output. I'm sure I have overlooked something, I've been up for days.
> >
> > Warning to all that Samba is a weak spot.
> >
> > Tim Camp
> > WZEW-FM
> > Mobile, Al.
> >
> >
> >
> >
> >
> > ___
> > 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

Re: [RDD] Ransonware attack

[Rob Landry]

I just checked the system at the station where I happen to be today. They 
have /var/snd mapped as a Samba share, but it's read-only. I don't know 
why they need it mapped; I'll have to ask them.


They shouldn't be able to delete anything in /home/rd, let alone actual 
Rivendell software files; those are nowhere near any Samba-accessible 
folder.


At another group of stations, the traffic machine isn't on a network with 
a Rivendell system. A Raspberry Pi at the traffic office manages the 
uploading and downloading of logs to different stations' Rivendell 
systems, all of which are in different locations.


--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.


On Tue, 14 Dec 2021, chris cottingham wrote:


If I had to guess, Rivendell uses the same user/pass for all SAMBA shares. This 
simplifies administration. All the ransomware would need to do Is scan the host 
for shares and attach.

So, it complicates your administration but there really needs to be a limited 
account for traffic and scheduling that only allows r/w from those shares and 
explicitly denies access to the audio share.

Just my $0.02.



On 12/14/21, 10:11 AM, "rivendell-dev-boun...@lists.rivendellaudio.org on behalf of Rob 
Landry"  wrote:

   On Fri, 10 Dec 2021, Jake Tremper wrote:

   > 2) Network segregation. An infection on the business side is awful and
   > hard to recover from. An infection on the business side that jumps and
   > wipes out the on-air machines is catastrophic. Isolated VLANs, when
   > implemented properly, help greatly in this area.

   The problem, unfortunately, is that a traffic machine has to be able to
   write a log file to the automation, and read aired log files from it for
   electronic reconciliation.

   Traffic machines are typically on the office network, and are used for
   things like email.

   Music scheduling software typically also runs on an office machine.
   Programming people are forever getting songs and syndicated shows off the
   Internet to add to the audio library.

   Both of these are potential malware vectors into an automation systems.

   The question is: even if someone exploits Samba to drop something onto a
   Rivendell machine, it goes into a Samba-writable folder, not /var/snd. How
   did they leverage that into access to other folders?


   Rob

   --
   Не думай что всё пропели,
   Что бури все отгремели;
   Готовься к великой цели,
   А слава тебя найдёт.


   > and, not directly related to this one, but a good concept:
   >
   > 3) Untested backups are not backups. Test your backups periodically and
   > verify that you can actually recover from them.
   >
   > On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
   >   Greetings,
   > This past Sunday morning our four station had a cyber attack.
   > They gained access through a windows server that we use for traffic
   > and bookkeeping.
   > Through this connection they exploited samba to place ssh keys on many
   > of our linux machines and erased all files on the control room pc's
   > and erased /var/snd on our nfs server.
   >
   > They encrypted the windows server for ransome and just erased the
   > linux machines they got access to.
   >
   > Trying to rebuild four radio stations from the ground up.
   > We had backup on several drives but they were on the network so they
   > got them as well.
   >
   > One issue if someone can help me with.
   > I have recompiled rivendell on two control rooms and everything works
   > except no audio and no meters, Carts act like they are playing but no
   > output. I'm sure I have overlooked something, I've been up for days.
   >
   > Warning to all that Samba is a weak spot.
   >
   > Tim Camp
   > WZEW-FM
   > Mobile, Al.
   >
   >
   >
   >
   >
   > ___
   > 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

Re: [RDD] Ransonware attack

[chris cottingham]

If I had to guess, Rivendell uses the same user/pass for all SAMBA shares. This 
simplifies administration. All the ransomware would need to do Is scan the host 
for shares and attach. 

So, it complicates your administration but there really needs to be a limited 
account for traffic and scheduling that only allows r/w from those shares and 
explicitly denies access to the audio share. 

Just my $0.02.



On 12/14/21, 10:11 AM, "rivendell-dev-boun...@lists.rivendellaudio.org on 
behalf of Rob Landry"  wrote:

On Fri, 10 Dec 2021, Jake Tremper wrote:

> 2) Network segregation. An infection on the business side is awful and 
> hard to recover from. An infection on the business side that jumps and 
> wipes out the on-air machines is catastrophic. Isolated VLANs, when 
> implemented properly, help greatly in this area.

The problem, unfortunately, is that a traffic machine has to be able to 
write a log file to the automation, and read aired log files from it for 
electronic reconciliation.

Traffic machines are typically on the office network, and are used for 
things like email.

Music scheduling software typically also runs on an office machine. 
Programming people are forever getting songs and syndicated shows off the 
Internet to add to the audio library.

Both of these are potential malware vectors into an automation systems.

The question is: even if someone exploits Samba to drop something onto a 
Rivendell machine, it goes into a Samba-writable folder, not /var/snd. How 
did they leverage that into access to other folders?


Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.


> and, not directly related to this one, but a good concept:
> 
> 3) Untested backups are not backups. Test your backups periodically and
> verify that you can actually recover from them.
> 
> On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
>   Greetings,
> This past Sunday morning our four station had a cyber attack.
> They gained access through a windows server that we use for traffic
> and bookkeeping.
> Through this connection they exploited samba to place ssh keys on many
> of our linux machines and erased all files on the control room pc's
> and erased /var/snd on our nfs server.
> 
> They encrypted the windows server for ransome and just erased the
> linux machines they got access to.
> 
> Trying to rebuild four radio stations from the ground up.
> We had backup on several drives but they were on the network so they
> got them as well.
> 
> One issue if someone can help me with.
> I have recompiled rivendell on two control rooms and everything works
> except no audio and no meters, Carts act like they are playing but no
> output. I'm sure I have overlooked something, I've been up for days.
> 
> Warning to all that Samba is a weak spot.
> 
> Tim Camp
> WZEW-FM
> Mobile, Al.
> 
> 
> 
>  
> 
> ___
> 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

Re: [RDD] Ransonware attack

[Rob Landry]

On Fri, 10 Dec 2021, Jake Tremper wrote:

2) Network segregation. An infection on the business side is awful and 
hard to recover from. An infection on the business side that jumps and 
wipes out the on-air machines is catastrophic. Isolated VLANs, when 
implemented properly, help greatly in this area.


The problem, unfortunately, is that a traffic machine has to be able to 
write a log file to the automation, and read aired log files from it for 
electronic reconciliation.


Traffic machines are typically on the office network, and are used for 
things like email.


Music scheduling software typically also runs on an office machine. 
Programming people are forever getting songs and syndicated shows off the 
Internet to add to the audio library.


Both of these are potential malware vectors into an automation systems.

The question is: even if someone exploits Samba to drop something onto a 
Rivendell machine, it goes into a Samba-writable folder, not /var/snd. How 
did they leverage that into access to other folders?



Rob

--
Не думай что всё пропели,
Что бури все отгремели;
Готовься к великой цели,
А слава тебя найдёт.



and, not directly related to this one, but a good concept:

3) Untested backups are not backups. Test your backups periodically and
verify that you can actually recover from them.

On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:
  Greetings,
This past Sunday morning our four station had a cyber attack.
They gained access through a windows server that we use for traffic
and bookkeeping.
Through this connection they exploited samba to place ssh keys on many
of our linux machines and erased all files on the control room pc's
and erased /var/snd on our nfs server.

They encrypted the windows server for ransome and just erased the
linux machines they got access to.

Trying to rebuild four radio stations from the ground up.
We had backup on several drives but they were on the network so they
got them as well.

One issue if someone can help me with.
I have recompiled rivendell on two control rooms and everything works
except no audio and no meters, Carts act like they are playing but no
output. I'm sure I have overlooked something, I've been up for days.

Warning to all that Samba is a weak spot.

Tim Camp
WZEW-FM
Mobile, Al.



 

___
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

Re: [RDD] Ransonware attack

[Jake Tremper]

First of all, my condolences & best of luck with your recovery.

What hardware are you using? Take a look at /etc/asound.conf and see if
it's correct. You can use rdalsaconfig to generate a new one if needed.

A few takeaways for the peanut gallery since this is something that comes
up more and more in the broadcast industry:

1) Cold backups. Backups cost money & cold backups cost more money, but
you've got to have them. Offsite cold backups are best, but in general
something that can't just be blanked by an intruder is something that
should be at the top of everyone's list.

2) Network segregation. An infection on the business side is awful and hard
to recover from. An infection on the business side that jumps and wipes out
the on-air machines is catastrophic. Isolated VLANs, when implemented
properly, help greatly in this area.

and, not directly related to this one, but a good concept:

3) Untested backups are not backups. Test your backups periodically and
verify that you can actually recover from them.

On Fri, Dec 10, 2021 at 12:42 PM Tim Camp  wrote:

> Greetings,
>
> This past Sunday morning our four station had a cyber attack.
> They gained access through a windows server that we use for traffic and
> bookkeeping.
> Through this connection they exploited samba to place ssh keys on many of
> our linux machines and erased all files on the control room pc's and erased
> /var/snd on our nfs server.
>
> They encrypted the windows server for ransome and just erased the linux
> machines they got access to.
>
> Trying to rebuild four radio stations from the ground up.
> We had backup on several drives but they were on the network so they got
> them as well.
>
> One issue if someone can help me with.
> I have recompiled rivendell on two control rooms and everything works
> except no audio and no meters, Carts act like they are playing but no
> output. I'm sure I have overlooked something, I've been up for days.
>
> Warning to all that Samba is a weak spot.
>
> Tim Camp
> WZEW-FM
> Mobile, Al.
>
>
>
>
>
> ___
> 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

Re: [RDD] Ransonware attack

[Geoff Barkman]

Hi Tim
Sorry to hear about this. What a way to spend the weeks leading up to
Christmas.
If you were to grab a copy of one the pieces of audio from the /var/and,
and listen to it on another program eg audacity, does it have a physical
wave form that you can see and listen to?
Many thanks
Geoff Barkman



On Sat, Dec 11, 2021, 6:42 AM Tim Camp  wrote:

> Greetings,
>
> This past Sunday morning our four station had a cyber attack.
> They gained access through a windows server that we use for traffic and
> bookkeeping.
> Through this connection they exploited samba to place ssh keys on many of
> our linux machines and erased all files on the control room pc's and erased
> /var/snd on our nfs server.
>
> They encrypted the windows server for ransome and just erased the linux
> machines they got access to.
>
> Trying to rebuild four radio stations from the ground up.
> We had backup on several drives but they were on the network so they got
> them as well.
>
> One issue if someone can help me with.
> I have recompiled rivendell on two control rooms and everything works
> except no audio and no meters, Carts act like they are playing but no
> output. I'm sure I have overlooked something, I've been up for days.
>
> Warning to all that Samba is a weak spot.
>
> Tim Camp
> WZEW-FM
> Mobile, Al.
>
>
>
>
>
> ___
> 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

[RDD] Ransonware attack

[Tim Camp]

Greetings,

This past Sunday morning our four station had a cyber attack.
They gained access through a windows server that we use for traffic and
bookkeeping.
Through this connection they exploited samba to place ssh keys on many of
our linux machines and erased all files on the control room pc's and erased
/var/snd on our nfs server.

They encrypted the windows server for ransome and just erased the linux
machines they got access to.

Trying to rebuild four radio stations from the ground up.
We had backup on several drives but they were on the network so they got
them as well.

One issue if someone can help me with.
I have recompiled rivendell on two control rooms and everything works
except no audio and no meters, Carts act like they are playing but no
output. I'm sure I have overlooked something, I've been up for days.

Warning to all that Samba is a weak spot.

Tim Camp
WZEW-FM
Mobile, Al.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev