HW and SW threats: how to block?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HW and SW threats: how to block?

Fedora mailing list
Good afternoon,

background:
In the past few months, I've seen a few articles on the internet about coin mining, also called cryptojacking.  Seems that in a variety of ways, software can be loaded onto remote computers and then run to mine crypto-currency, often without the user knowing it.  This is done to make money, sometimes for good purposes, but sometimes for malicious people or organizations.  The running of most such scripts is barely noticeable (deliberately!), but some can take up so much cpu and/or gpu so as to fry the processors (by overheating them).

question:
I realize there's no perfect protection.  But based on the knowledge and experience of the members of this list, which of the coin-mining blockers available for Firefox is best (most effective)?

thanks,
Bill.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
On 04/10/2018 12:18 PM, home user via users wrote:
> Good afternoon,
>
> background:
> In the past few months, I've seen a few articles on the internet about coin mining, also called cryptojacking.  Seems that in a variety of ways, software can be loaded onto remote computers and then run to mine crypto-currency, often without the user knowing it.  This is done to make money, sometimes for good purposes, but sometimes for malicious people or organizations.  The running of most such scripts is barely noticeable (deliberately!), but some can take up so much cpu and/or gpu so as to fry the processors (by overheating them).
>
> question:
> I realize there's no perfect protection.  But based on the knowledge and experience of the members of this list, which of the coin-mining blockers available for Firefox is best (most effective)?

I've never understood the underlying concept of bitcoin/xmr/whatever
mining. Currency (money) is usually tied, ultimately, to some physical
thing. This just seems nebulous. Are they using our systems to come up
with better cryptography? I just don't get it.

Anyway, my top 7:

1. Never let Firefox (or Chrome or any web browser) install software on
your machine without your explicit approval. Never ever! Bad dog!

2. If you download something and want to install it but aren't 100% sure
about, deploy it into a scratch directory and run it in a sandbox first:

        https://fedoraproject.org/wiki/Sandboxing

or run it in a VM. Make sure the sandboxed program doesn't do anything
nefarious before you install it normally.

3. Keep your system up to date ("dnf --refresh upgrade" often).

4. Use a highly restrictive firewall. Mine's set up so that NOTHING
unsolicited gets in except ssh from specific IPs and DNS responses.

5. Don't disable SELinux. This may be a pain, but it can catch some
nasty stuff.

6. Track what processes your machine is running most of the time and
look for ones that seem suspicious (running "ps aux" as root can be your
friend).

7. I have a Raspberry Pi that I use to run nmap against my machines to
see if they have open ports I'm not expecting. This also helps protect
against trojans.

Your mileage may vary and others here on the list will certainly chime
in. Always keep in mind the old adage:

        "Just because I'm paranoid doesn't mean they AIN'T out to get
        me!"

Good luck!
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-               Duct Tape + Magic Marker = Label Maker!              -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Matthew Miller-2
On Tue, Apr 10, 2018 at 01:03:18PM -0700, Rick Stevens wrote:
> I've never understood the underlying concept of bitcoin/xmr/whatever
> mining. Currency (money) is usually tied, ultimately, to some physical
> thing. This just seems nebulous. Are they using our systems to come up
> with better cryptography? I just don't get it.

The basic idea of cryptocurrency is that instead of "some physical
thing", they are tied to a different limited resource: compute time.
Hence, the "mining".

--
Matthew Miller
<[hidden email]>
Fedora Project Leader
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Joe Zeff
In reply to this post by Rick Stevens-3
On 04/10/2018 01:03 PM, Rick Stevens wrote:
> 4. Use a highly restrictive firewall. Mine's set up so that NOTHING
> unsolicited gets in except ssh from specific IPs and DNS responses.
>

That's a good idea, but remember, DNS responses aren't unsolicited;
they're replies to queries you sent out.

> 5. Don't disable SELinux. This may be a pain, but it can catch some
> nasty stuff.

And not just malicious code, either.  SELinux used to prevent Google
Earth from running because of something called "text redirection."
Looking it up, it's a way to hook into an interrupt so that your code
gets executed first, then the regular code.  This was a common way to
hook in TSR programs back in the MS-DOS days, and several could be
daisy-chained to the keyboard interrupt.  Not only is it a way to add
malware to a program, it can cause strange problems if the program
crashes and/or doesn't clean up properly on exit.  I'm not accusing
Google of offering malware, just of using outmoded methods to connect
their programs to the system.  Later, of course, they cleaned up their
act and SELinux stopped blocking them.  It also caused problems with one
BOINC project about a decade or so ago because it was trying to walk
*all* of /proc for no good reason.  Enough of us reported it that the
maintainers pulled it until they could fix the bug.  Again, not malware,
but still something that needed correcting.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
In reply to this post by Matthew Miller-2
On 04/10/2018 01:11 PM, Matthew Miller wrote:
> On Tue, Apr 10, 2018 at 01:03:18PM -0700, Rick Stevens wrote:
>> I've never understood the underlying concept of bitcoin/xmr/whatever
>> mining. Currency (money) is usually tied, ultimately, to some physical
>> thing. This just seems nebulous. Are they using our systems to come up
>> with better cryptography? I just don't get it.
>
> The basic idea of cryptocurrency is that instead of "some physical
> thing", they are tied to a different limited resource: compute time.
> Hence, the "mining".

Yes, I get that, but what is being "created"? What are the providers of
the mining algorithms trying to accomplish by bribing us with
cryptocurrency to use our machines? With the SETI project, there was a
stated goal there (use the spare CPU cycles to help decipher the radio
signals we've gotten, looking for a possible ET transmission).
Cryptocurrency doesn't seem to have such a stated goal (or I just missed
it).

Like I said, I just don't get it and I'm a bit skeptical about possibly
helping someone do something evil. But that's just me.

I don't mean this thread to devolve into a cryptocurrency pro-vs-anti
thing. I was just stating my position. I don't and won't do mining.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-    If Windows isn't a virus, then it sure as hell is a carrier!    -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
In reply to this post by Joe Zeff
On 04/10/2018 01:22 PM, Joe Zeff wrote:
> On 04/10/2018 01:03 PM, Rick Stevens wrote:
>> 4. Use a highly restrictive firewall. Mine's set up so that NOTHING
>> unsolicited gets in except ssh from specific IPs and DNS responses.
>>
>
> That's a good idea, but remember, DNS responses aren't unsolicited;
> they're replies to queries you sent out.

True, but old DNS uses UDP and thus the responses aren't "related" to a
given query (a stateful firewall couldn't necessarily determine that an
incoming DNS UDP reply was solicited or not).

>> 5. Don't disable SELinux. This may be a pain, but it can catch some
>> nasty stuff.
>
> And not just malicious code, either.  SELinux used to prevent Google
> Earth from running because of something called "text redirection."
> Looking it up, it's a way to hook into an interrupt so that your code
> gets executed first, then the regular code.  This was a common way to
> hook in TSR programs back in the MS-DOS days, and several could be
> daisy-chained to the keyboard interrupt.  Not only is it a way to add
> malware to a program, it can cause strange problems if the program
> crashes and/or doesn't clean up properly on exit.  I'm not accusing
> Google of offering malware, just of using outmoded methods to connect
> their programs to the system.  Later, of course, they cleaned up their
> act and SELinux stopped blocking them.  It also caused problems with one
> BOINC project about a decade or so ago because it was trying to walk
> *all* of /proc for no good reason.  Enough of us reported it that the
> maintainers pulled it until they could fix the bug.  Again, not malware,
> but still something that needed correcting.

Another one SELinux keeps from running is ZoneMinder (ZM) or other
webapps that use Perl. I put in a lot of rules to let ZM run at my
house. They're carefully crafted, I know what the rules do (and they're
all ZM-specific), but those who don't grok SELinux will disable SELinux
or put it in permissive mode to run ZM (and other programs like it).
Not good.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-        Brain:  The organ with which we think that we think.        -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Bruno Wolff III
On Tue, Apr 10, 2018 at 13:40:44 -0700,
  Rick Stevens <[hidden email]> wrote:
>True, but old DNS uses UDP and thus the responses aren't "related" to a
>given query (a stateful firewall couldn't necessarily determine that an
>incoming DNS UDP reply was solicited or not).

I think related is fudged for UDP by noting destination and source IPs and
port numbers and allowing inbound UDP packets that match those IP and port
numbers through for some period of time (my memory is 5 minutes). This will
work for most DNS.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
On 04/10/2018 02:03 PM, Bruno Wolff III wrote:

> On Tue, Apr 10, 2018 at 13:40:44 -0700,
>  Rick Stevens <[hidden email]> wrote:
>> True, but old DNS uses UDP and thus the responses aren't "related" to a
>> given query (a stateful firewall couldn't necessarily determine that an
>> incoming DNS UDP reply was solicited or not).
>
> I think related is fudged for UDP by noting destination and source IPs
> and port numbers and allowing inbound UDP packets that match those IP
> and port numbers through for some period of time (my memory is 5
> minutes). This will work for most DNS.

I seem to recall the same thing, that iptables opens incoming UDP port
53 for some period of time if it saw an outgoing UDP port 53 request.
And I, like you, can't recall what that period was--although I think
it was 60 seconds. That's still more than the the basic Linux resolver
library's limit.

You can have an "options" section in the /etc/resolv.conf file:

        options timeout:<somevalue>

If such a line is not present, the default timeout is 5 seconds and the
limit is capped at 30 seconds (according to the man page).

I think I've seen a resolution hang much longer than that--specifically
starting sendmail with a broken resolver. It might have been be either
sendmail itself or the old SysV script retrying the startup that caused
the hang.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-  Time: Nature's way of keeping everything from happening at once.  -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Ed Greshko-2
On 04/11/18 07:27, Rick Stevens wrote:
> I seem to recall the same thing, that iptables opens incoming UDP port
> 53 for some period of time if it saw an outgoing UDP port 53 request.
> And I, like you, can't recall what that period was--although I think
> it was 60 seconds. That's still more than the the basic Linux resolver
> library's limit.


That isn't how DNS requests work.

When a client makes a DNS request the destination port is 53 and the source port is a
random high port. 

Frame 3: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
Ethernet II, Src: PcsCompu_16:b2:62 (08:00:27:16:b2:62), Dst: Synology_76:13:a8
(00:11:32:76:13:a8)
Internet Protocol Version 4, Src: 192.168.1.191, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 43629, Dst Port: 53
Domain Name System (query)

The client then listens on that same random port and the sever response is from
source port 53

Frame 4: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits)
Ethernet II, Src: Synology_76:13:a8 (00:11:32:76:13:a8), Dst: PcsCompu_16:b2:62
(08:00:27:16:b2:62)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.191
User Datagram Protocol, Src Port: 53, Dst Port: 43629
Domain Name System (response)

--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
On 04/10/2018 06:13 PM, Ed Greshko wrote:

> On 04/11/18 07:27, Rick Stevens wrote:
>> I seem to recall the same thing, that iptables opens incoming UDP port
>> 53 for some period of time if it saw an outgoing UDP port 53 request.
>> And I, like you, can't recall what that period was--although I think
>> it was 60 seconds. That's still more than the the basic Linux resolver
>> library's limit.
>
>
> That isn't how DNS requests work.
>
> When a client makes a DNS request the destination port is 53 and the source port is a
> random high port. 
>
> Frame 3: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
> Ethernet II, Src: PcsCompu_16:b2:62 (08:00:27:16:b2:62), Dst: Synology_76:13:a8
> (00:11:32:76:13:a8)
> Internet Protocol Version 4, Src: 192.168.1.191, Dst: 192.168.1.1
> User Datagram Protocol, Src Port: 43629, Dst Port: 53
> Domain Name System (query)
>
> The client then listens on that same random port and the sever response is from
> source port 53
>
> Frame 4: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits)
> Ethernet II, Src: Synology_76:13:a8 (00:11:32:76:13:a8), Dst: PcsCompu_16:b2:62
> (08:00:27:16:b2:62)
> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.191
> User Datagram Protocol, Src Port: 53, Dst Port: 43629
> Domain Name System (response)

Yes, I probably didn't say it well. I was inferring that if an outgoing
UDP destination port 53 request was sent, then I think the iptables
conntrack plugin opens incoming UDP traffic with a source port of 53
for some period of time, since this was (theoretically) a DNS request
that's expecting an answer.

Sorry if I wasn't clear and I'm not 100% sure if conntrack actually does
the heavy lifting. I've never looked at the code.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-              Never eat anything larger than your head              -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Ed Greshko
On 04/11/18 09:46, Rick Stevens wrote:

> On 04/10/2018 06:13 PM, Ed Greshko wrote:
>> On 04/11/18 07:27, Rick Stevens wrote:
>>> I seem to recall the same thing, that iptables opens incoming UDP port
>>> 53 for some period of time if it saw an outgoing UDP port 53 request.
>>> And I, like you, can't recall what that period was--although I think
>>> it was 60 seconds. That's still more than the the basic Linux resolver
>>> library's limit.
>>
>> That isn't how DNS requests work.
>>
>> When a client makes a DNS request the destination port is 53 and the source port is a
>> random high port. 
>>
>> Frame 3: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
>> Ethernet II, Src: PcsCompu_16:b2:62 (08:00:27:16:b2:62), Dst: Synology_76:13:a8
>> (00:11:32:76:13:a8)
>> Internet Protocol Version 4, Src: 192.168.1.191, Dst: 192.168.1.1
>> User Datagram Protocol, Src Port: 43629, Dst Port: 53
>> Domain Name System (query)
>>
>> The client then listens on that same random port and the sever response is from
>> source port 53
>>
>> Frame 4: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits)
>> Ethernet II, Src: Synology_76:13:a8 (00:11:32:76:13:a8), Dst: PcsCompu_16:b2:62
>> (08:00:27:16:b2:62)
>> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.191
>> User Datagram Protocol, Src Port: 53, Dst Port: 43629
>> Domain Name System (response)
> Yes, I probably didn't say it well. I was inferring that if an outgoing
> UDP destination port 53 request was sent, then I think the iptables
> conntrack plugin opens incoming UDP traffic with a source port of 53
> for some period of time, since this was (theoretically) a DNS request
> that's expecting an answer.
>
> Sorry if I wasn't clear and I'm not 100% sure if conntrack actually does
> the heavy lifting. I've never looked at the code.
OK, you had originally said "opens incoming UDP port 53" when it should have been the
"random port".

Yes, conntrack is the module which controls this.  I believe you can modify the time
by changing the value of /proc/sys/net/netfilter/nf_conntrack_udp_timeout or maybe
nf_conntrack_udp_timeout_stream.  I'm guessing the former.  The little documentation
I found with a quick search was....

nf_conntrack_udp_timeout - INTEGER (seconds)
    default 30

nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
    default 180

    This extended timeout will be used in case there is an UDP stream
    detected.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Ed Greshko
On 04/11/18 10:45, Ed Greshko wrote:

>
> Yes, conntrack is the module which controls this.  I believe you can modify the time
> by changing the value of /proc/sys/net/netfilter/nf_conntrack_udp_timeout or maybe
> nf_conntrack_udp_timeout_stream.  I'm guessing the former.  The little documentation
> I found with a quick search was....
>
> nf_conntrack_udp_timeout - INTEGER (seconds)
>     default 30
>
> nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
>     default 180
>
>     This extended timeout will be used in case there is an UDP stream
>     detected.
>
FWIW, I did verify it to be 30 seconds the entry is held....

[root@f27k ~]# host cnn.com 1.1.1.1 > /dev/null ; sleep 29 ; conntrack -L -p udp
--dport 53 | grep 1.1.1.1
conntrack v1.4.4 (conntrack-tools): 4 flow entries have been shown.
udp      17 0 src=192.168.1.191 dst=1.1.1.1 sport=56648 dport=53 src=1.1.1.1
dst=192.168.1.191 sport=53 dport=56648 mark=0 secctx=system_u:object_r:unlabeled_t:s0
use=1
udp      17 0 src=192.168.1.191 dst=1.1.1.1 sport=36316 dport=53 src=1.1.1.1
dst=192.168.1.191 sport=53 dport=36316 mark=0 secctx=system_u:object_r:unlabeled_t:s0
use=1
udp      17 0 src=192.168.1.191 dst=1.1.1.1 sport=56690 dport=53 src=1.1.1.1
dst=192.168.1.191 sport=53 dport=56690 mark=0 secctx=system_u:object_r:unlabeled_t:s0
use=1

[root@f27k ~]# host cnn.com 1.1.1.1 > /dev/null ; sleep 30 ; conntrack -L -p udp
--dport 53 | grep 1.1.1.1
conntrack v1.4.4 (conntrack-tools): 1 flow entries have been shown.


--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Gordon Messmer-2
In reply to this post by Rick Stevens-3
On 04/10/2018 06:46 PM, Rick Stevens wrote:
> Yes, I probably didn't say it well. I was inferring that if an outgoing
> UDP destination port 53 request was sent, then I think the iptables
> conntrack plugin opens incoming UDP traffic with a source port of 53
> for some period of time, since this was (theoretically) a DNS request
> that's expecting an answer.


It's slightly more intelligent than that.  Only "related" traffic will
be allowed to return.  In the case of UDP, that means that the source
and destination IP address must match, and the source and destination
ports must match the original request as well.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

jdow
In reply to this post by Rick Stevens-3
On 20180410 18:46, Rick Stevens wrote:

> On 04/10/2018 06:13 PM, Ed Greshko wrote:
>> On 04/11/18 07:27, Rick Stevens wrote:
>>> I seem to recall the same thing, that iptables opens incoming UDP port
>>> 53 for some period of time if it saw an outgoing UDP port 53 request.
>>> And I, like you, can't recall what that period was--although I think
>>> it was 60 seconds. That's still more than the the basic Linux resolver
>>> library's limit.
>>
>>
>> That isn't how DNS requests work.
>>
>> When a client makes a DNS request the destination port is 53 and the source port is a
>> random high port.
>>
>> Frame 3: 77 bytes on wire (616 bits), 77 bytes captured (616 bits)
>> Ethernet II, Src: PcsCompu_16:b2:62 (08:00:27:16:b2:62), Dst: Synology_76:13:a8
>> (00:11:32:76:13:a8)
>> Internet Protocol Version 4, Src: 192.168.1.191, Dst: 192.168.1.1
>> User Datagram Protocol, Src Port: 43629, Dst Port: 53
>> Domain Name System (query)
>>
>> The client then listens on that same random port and the sever response is from
>> source port 53
>>
>> Frame 4: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits)
>> Ethernet II, Src: Synology_76:13:a8 (00:11:32:76:13:a8), Dst: PcsCompu_16:b2:62
>> (08:00:27:16:b2:62)
>> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.191
>> User Datagram Protocol, Src Port: 53, Dst Port: 43629
>> Domain Name System (response)
>
> Yes, I probably didn't say it well. I was inferring that if an outgoing
> UDP destination port 53 request was sent, then I think the iptables
> conntrack plugin opens incoming UDP traffic with a source port of 53
> for some period of time, since this was (theoretically) a DNS request
> that's expecting an answer.
>
> Sorry if I wasn't clear and I'm not 100% sure if conntrack actually does
> the heavy lifting. I've never looked at the code.

Rick, how do you handle coin miners that are written into a page's javascript
and executed while you are still on the page? SELinux isn't particularly going
to solve that issue very well. If the http(s) connection stays alive while you
are on the page to support updates it can also support mining results through
the same link.

{o.o}   Joanne
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Fedora mailing list
In reply to this post by Fedora mailing list
Interesting posts, but they've strayed.

The first article I saw on coin mining is here:
"https://finance.yahoo.com/news/hackers-using-victims-computers-mine-cryptocurrencies-154915570.html".
I saw another in CNN's finance web site, but I can't find it now.  The first article says "Browser-based cryptominers can force your computer to mine monero even after you think you’ve left the offending site that launched the mining operation behind.".  Also, some web site "recently began informing users who have ad blockers installed that their computers will be used to mine cryptocurrencies while they are on the site.".  So web sites can
*detect that your browser is using ad blockers; and
* then run coin mining on your computer to make up for revenue lost by blocking their ads.
That first article also talks about coin mining destroying hardware.

The threat is real.  Ad-blockers are not sufficient.  So let's please get back to the original question.  There are several coin-mining blockers available for Firefox.  Based on your experience, which is most effective?  I (and probably others) would welcome your advice on this.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Fedora mailing list
Allegedly, on or about 12 April 2018, home user via users sent:
> Ad-blockers are not sufficient.  So let's please get back to the
> original question.  There are several coin-mining blockers available
> for Firefox.  Based on your experience, which is most effective?

I would hazard a guess that script and Flash blockers would kill them.

--
[tim@localhost ~]$ uname -rsvp
Linux 4.15.10-200.fc26.x86_64 #1 SMP Thu Mar 15 17:14:41 UTC 2018 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.

Windows (TM) [Typhoid Mary].  They refuse to believe that there's anything
wrong with it, but everyone else knows Windows is a disease that spreads.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Rick Stevens-3
On 04/12/2018 09:53 AM, Tim via users wrote:
> Allegedly, on or about 12 April 2018, home user via users sent:
>> Ad-blockers are not sufficient.  So let's please get back to the
>> original question.  There are several coin-mining blockers available
>> for Firefox.  Based on your experience, which is most effective?
>
> I would hazard a guess that script and Flash blockers would kill them.

And again, if you don't allow your browser or mail client to install
software (which is a spectacularly bad idea in the first place) and
you're careful about which links you click and which packages you
download and install, it's sort of a moot point.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-   UNIX is actually quite user friendly.  The problem is that it's  -
-              just very picky of who its friends are!               -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Eddie G. O'Connor Jr.
I don't know if this will top post or not since I'm replying via cellphone. But I'd like to chime in on a few points.

First off? I think crypto-currency is stupid. There, I said it. Yes it's my opinion, and I know there are those who will disagree with me and I'm fine with that. But it still doesn't change the fact that I think it's stupid. Bear with me for a moment: you basically run your machine night and day, trying to decipher some code...and THATS supposed to gain you this digital "coin" that is the equivalent to REAL MONEY? has NO ONE thought this through? How can money be MADE by the consuming of CPU cycles!? LoL! I'm sorry, I'm just a sarcastic guy from NY, but to me? it's HILARIOUS.

Also, I have always been suspicious of ANYTHING that tries to install or run ANYTHING without my explicit consent! This was one of the reasons why I left Windows to begin with! How many of you remember the times you'd be working on something important...only to have your system slow to a crawl while "Windows Installs Important Updates"? and then, not even being able to do anything until it was done or until it prompted you to restart your machine? Supposedly those days are over right? LoL! If I open Firefox or Midori and I notice anything strange happening? like my system becomes incredibly slow? I'd shut down the browser...and run ClamAV....then RKhunter....then Chrootkit. That's never happened to me since I don't allow things to run in FF without prompting me first...(as in some sites informing me that if I want to see the embedded video on their page I have to enable Adobe Flash, which I don't do. I prefer to read the content I came for, and then leave!) I also run BleachBit every month. And if I see any file I don't recognize? or that I know for a fact doesn't belong on my hard drive? it gets deleted. I know I might sound like a paranoid tin-foil hat wearin' conspiracy-theorist, but with the revelations of FB....and other recent exposures of personal data being stolen, hacked, sold, brokered, or otherwise being out of the control of "We The People", I think I would prefer to err on the side of caution.

And finally, to try to answer the OP's question: There is no magic "cure-all" when it comes to protecting your Linux systems, except determination, and diligence. When you have a Linux machine, whether it's a server....laptop....or desktop, you have to constantly do administration on it. And while it might sound tedious, the alternative is loss of control of your PC. And you can't be "lazy" when it comes to protecting your machine(s). No leaving updates from last month sitting in your Software center. No ignoring articles that warn you of upcoming or existing threats, do your homework, and focus on always being safe while online...no clicking on anything that you aren't sure is safe. No opening emails that don't come from sanctioned and verified emails. (For Pete's sake use a spamblocker!....or else create rules for your inbox allowing ONLY those email addresses. It may sound hard but once you have a system and methods in place? You'll find it's a lot easier than you think!!

Just my two cents....

On Thu, Apr 12, 2018, 7:05 PM Rick Stevens <[hidden email]> wrote:
On 04/12/2018 09:53 AM, Tim via users wrote:
> Allegedly, on or about 12 April 2018, home user via users sent:
>> Ad-blockers are not sufficient.  So let's please get back to the
>> original question.  There are several coin-mining blockers available
>> for Firefox.  Based on your experience, which is most effective?
>
> I would hazard a guess that script and Flash blockers would kill them.

And again, if you don't allow your browser or mail client to install
software (which is a spectacularly bad idea in the first place) and
you're careful about which links you click and which packages you
download and install, it's sort of a moot point.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [hidden email] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-   UNIX is actually quite user friendly.  The problem is that it's  -
-              just very picky of who its friends are!               -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]

_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Fedora mailing list
In reply to this post by Fedora mailing list
> ...I think crypto-currency is stupid...
I agree.  That's why some people and organizations use coin mining.  They get us to do all that grunt work for them.  They use our cpu, our gpu, our electricity, and our money, and wear out our hardware.

> Also, I have always been suspicious...
I agree.  I have my browsers and e-mail clients set to not download/install anything without my permission.  But I'm human, and I make mistakes.  I even try to shut down automatic updating if/when I can figure out how to do that (sometimes very difficult for home users such as me).

> ...ClamAV
I didn't realize that ClamAV is available for Linux.  So I looked it up in wikipedia (I know, it's not the most authoritative place to look).  Overall, it's effectiveness is so-so.  I'll dig into ClamAV more later.

> ...Chrootkit...
I assume you mean "chkrootkit".  I've been running that at least weekly for about five years.  I learned about it from members of this list.

> ...RKhunter...
I've been running that at least weekly for about five years.  I learned about it from members of this list.

> ...BleachBit...
I didn't realize that this is available for Linux.  I'll dig into it more later.

> ...There is no magic "cure-all"...
I agree, and I said this in the first sentence of the "question" part of my original post.  Everything said in that last paragraph are things I'm already doing.  I've been doing patches ("dnf upgrade --refresh") weekly for about 5 years, and I upgrade to the next Fedora release about every 6 months.

> ...if you don't allow your browser or mail client to install software...
I've been following this advice for years.

> ...top 7...
(1,3,5,7)  I've been following these for years.
(2-sandboxing and vm)  I really need to learn about these.
(4-firewall)  I think I've got this set properly, but I'm not sure.  Firewalls seem v-e-r-y complicated, and are over my head.  I'm trusting that the thread I started last summer about hundreds of external attempts to remotely log in to my work station fixed this.
(6-"ps -aux")  I did this a short while ago, but not as root.  256 processes!  ...most unfamiliar to me.  It would take a real expert to recognize something that doesn't belong.

Thank-you for the discussion and suggestions.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HW and SW threats: how to block?

Samuel Sieb
In reply to this post by Rick Stevens-3
On 04/12/2018 04:04 PM, Rick Stevens wrote:
> And again, if you don't allow your browser or mail client to install
> software (which is a spectacularly bad idea in the first place) and
> you're careful about which links you click and which packages you
> download and install, it's sort of a moot point.

It's not about installing something.  A website can run javascript on
your browser (unless you're using the mentioned javascript blockers
which cripple most sites).  And apparently a website could have
javascript keep running even after you leave the site.  This has
possibly been corrected by Firefox.  I don't remember all the details.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
12