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.
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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Duct Tape + Magic Marker = Label Maker! - ----------------------------------------------------------------------
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".
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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If Windows isn't a virus, then it sure as hell is a carrier! - ----------------------------------------------------------------------
On 04/10/2018 01:03 PM, Rick Stevens wrote:
- 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.
- 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.
On 04/10/2018 01:22 PM, Joe Zeff wrote:
On 04/10/2018 01:03 PM, Rick Stevens wrote:
- 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).
- 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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Brain: The organ with which we think that we think. - ----------------------------------------------------------------------
On Tue, Apr 10, 2018 at 13:40:44 -0700, Rick Stevens ricks@alldigital.com 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.
On 04/10/2018 02:03 PM, Bruno Wolff III wrote:
On Tue, Apr 10, 2018 at 13:40:44 -0700, Rick Stevens ricks@alldigital.com 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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Time: Nature's way of keeping everything from happening at once. - ----------------------------------------------------------------------
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)
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 ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Never eat anything larger than your head - ----------------------------------------------------------------------
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.
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.
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.
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
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-cryptocu...". 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.
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.
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 ricks@alldigital.com - - 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! - ----------------------------------------------------------------------
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 ricks@alldigital.com 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 ricks@alldigital.com -
- 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 -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
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.
On Sat, 14 Apr 2018 00:20:28 -0700 Samuel Sieb samuel@sieb.net wrote:
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.
I think that closing the tab ends the javascript access for that site. But I'm running noscript, so it might be that it is noscript, and not firefox, enforcing that. I also run cookie autodelete, and that might end access for a site because any cookies it created are deleted when the tab is closed. I say this because when I close a tab for a site that I've logged into, and then open a new tab for it, I have to enable javascript and log in for that site again.
This is complicated, because of the way the web works. If everything displayed in the browser was created by the foreign web server, it would be simpler, though slower. Allowing foreign software to run in the client browser is a security hole, because there will always be bugs, or unintended access routes, in complex software for the bad guys to exploit. The binary for firefox is about 80 MBytes (the hg source repository is over 4 GBytes), that's a lot of attack surface.
...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.
-
Bruno Wolff III -
Ed Greshko -
Ed Greshko -
Eddie O'Connor -
Gordon Messmer -
home user -
jdow -
Joe Zeff -
Matthew Miller -
Rick Stevens -
Samuel Sieb -
stan -
Tim