<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: bemyak</title>
    <description>The latest articles on DEV Community by bemyak (@bemyak).</description>
    <link>https://dev.to/bemyak</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F81104%2F69d6810e-1d2b-4b60-a8f6-db20f9077f66.jpeg</url>
      <title>DEV Community: bemyak</title>
      <link>https://dev.to/bemyak</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/bemyak"/>
    <language>en</language>
    <item>
      <title>Useful linux daemons for better PC experience</title>
      <dc:creator>bemyak</dc:creator>
      <pubDate>Wed, 10 Jul 2019 08:51:55 +0000</pubDate>
      <link>https://dev.to/bemyak/useful-linux-daemons-for-better-pc-experience-560</link>
      <guid>https://dev.to/bemyak/useful-linux-daemons-for-better-pc-experience-560</guid>
      <description>&lt;p&gt;Hi, dev.to!&lt;/p&gt;

&lt;p&gt;Linux is great OS, but it's default behavior is usually optimized for servers. Since more and more developers use it as theirs main operating system, I thought that it would be nice to share several useful daemons that will make this experience a little bit smoother.&lt;/p&gt;

&lt;p&gt;I intentionally didn't include any installation instructions to stay distro-agnostic. If you are interested in one of them and want to have it in your system, please go carefully through installation and configuration instructions yourself. I don't want to break your system :)&lt;/p&gt;

&lt;h2&gt;
  
  
  Irqbalance
&lt;/h2&gt;


&lt;div class="ltag-github-readme-tag"&gt;
  &lt;div class="readme-overview"&gt;
    &lt;h2&gt;
      &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--A9-wwsHG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/github-logo-5a155e1f9a670af7944dd5e12375bc76ed542ea80224905ecaf878b9157cdefc.svg" alt="GitHub logo"&gt;
      &lt;a href="https://github.com/Irqbalance" rel="noopener noreferrer"&gt;
        Irqbalance
      &lt;/a&gt; / &lt;a href="https://github.com/Irqbalance/irqbalance" rel="noopener noreferrer"&gt;
        irqbalance
      &lt;/a&gt;
    &lt;/h2&gt;
    &lt;h3&gt;
      The irqbalance source tree - The new official site for irqbalance
    &lt;/h3&gt;
  &lt;/div&gt;
  &lt;div class="ltag-github-body"&gt;
    
&lt;div id="readme" class="md"&gt;
&lt;div class="markdown-heading"&gt;
&lt;h1 class="heading-element"&gt;What is Irqbalance&lt;/h1&gt;
&lt;/div&gt;
&lt;p&gt;Irqbalance is a daemon to help balance the cpu load generated by interrupts
across all of a systems cpus. Irqbalance identifies the highest volume
interrupt sources, and isolates each of them to a single unique cpu, so that
load is spread as much as possible over an entire processor set, while
minimizing cache miss rates for irq handlers.&lt;/p&gt;
&lt;div class="markdown-heading"&gt;
&lt;h2 class="heading-element"&gt;Building and Installing &lt;a href="https://travis-ci.org/Irqbalance/irqbalance" rel="nofollow noopener noreferrer"&gt;&lt;img src="https://camo.githubusercontent.com/6ddcf1286c3aeef2f6cacdcf70ec62e3a1110c80b60bf7d0f99a3cd12bf30fe7/68747470733a2f2f7472617669732d63692e6f72672f49727162616c616e63652f69727162616c616e63652e7376673f6272616e63683d6d6173746572" alt="Build Status"&gt;&lt;/a&gt;
&lt;/h2&gt;
&lt;/div&gt;
&lt;div class="highlight highlight-source-shell notranslate position-relative overflow-auto js-code-highlight"&gt;
&lt;pre&gt;./autogen.sh
./configure [options]
make
make install&lt;/pre&gt;

&lt;/div&gt;
&lt;div class="markdown-heading"&gt;
&lt;h2 class="heading-element"&gt;Developing Irqbalance&lt;/h2&gt;
&lt;/div&gt;
&lt;p&gt;Irqbalance is currently hosted on github, and so developers are welcome to use
the issue/pull request/etc infrastructure found there.&lt;/p&gt;
&lt;div class="markdown-heading"&gt;
&lt;h2 class="heading-element"&gt;Bug reporting&lt;/h2&gt;

&lt;/div&gt;
&lt;p&gt;When something goes wrong, feel free to send us bugreport by one of the ways
described above. Your report should include:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Irqbalance version you've been using (or commit hash)&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;/proc/interrupts&lt;/code&gt; output&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;irqbalance --debug&lt;/code&gt; output&lt;/li&gt;
&lt;li&gt;content of smp_affinity files - can be obtained by e.g
&lt;code&gt;$ for i in $(seq 0 300); do grep . /proc/irq/$i/smp_affinity /dev/null 2&amp;gt;/dev/null;&lt;/code&gt;…&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
  &lt;/div&gt;
  &lt;div class="gh-btn-container"&gt;&lt;a class="gh-btn" href="https://github.com/Irqbalance/irqbalance" rel="noopener noreferrer"&gt;View on GitHub&lt;/a&gt;&lt;/div&gt;
&lt;/div&gt;


&lt;p&gt;What does the description above mean in practice? Suppose we are running Intellij Idea and it decides that it is a good time to update indices - right in the middle of the compilation process while we are watching a nice film or peertube video.&lt;/p&gt;

&lt;p&gt;The &lt;code&gt;irqbalance&lt;/code&gt; daemon will try to keep that "heavy" process as far away from our video thread as possible. This means that despite cpu overloading the system won't "hang": the cursor will be me responsive and the video will continue playing.&lt;/p&gt;

&lt;p&gt;Nice thing to have, right?&lt;/p&gt;

&lt;h2&gt;
  
  
  haveged
&lt;/h2&gt;


&lt;div class="ltag-github-readme-tag"&gt;
  &lt;div class="readme-overview"&gt;
    &lt;h2&gt;
      &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--A9-wwsHG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/github-logo-5a155e1f9a670af7944dd5e12375bc76ed542ea80224905ecaf878b9157cdefc.svg" alt="GitHub logo"&gt;
      &lt;a href="https://github.com/jirka-h" rel="noopener noreferrer"&gt;
        jirka-h
      &lt;/a&gt; / &lt;a href="https://github.com/jirka-h/haveged" rel="noopener noreferrer"&gt;
        haveged
      &lt;/a&gt;
    &lt;/h2&gt;
    &lt;h3&gt;
      Entropy daemon ![Continuous Integration](https://github.com/jirka-h/haveged/workflows/Continuous%20Integration/badge.svg)
    &lt;/h3&gt;
  &lt;/div&gt;
  &lt;div class="ltag-github-body"&gt;
    
&lt;div id="readme" class="md"&gt;
&lt;p&gt;&lt;a rel="noopener noreferrer" href="https://github.com/jirka-h/haveged/workflows/Continuous%20Integration/badge.svg"&gt;&lt;img src="https://github.com/jirka-h/haveged/workflows/Continuous%20Integration/badge.svg" alt="Continuous Integration"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Haveged, an entropy source&lt;/p&gt;
&lt;p&gt;IMPORTANT UPDATE&lt;/p&gt;
&lt;p&gt;Starting from Linux kernel v5.4, the HAVEGED inspired algorithm has been included in the Linux kernel (see the &lt;a href="https://lore.kernel.org/lkml/alpine.DEB.2.21.1909290010500.2636@nanos.tec.linutronix.de/T/" rel="nofollow noopener noreferrer"&gt;LKML article&lt;/a&gt; and the Linux Kernel &lt;a href="https://github.com/torvalds/linux/commit/50ee7529ec4500c88f8664560770a7a1b65db72b" rel="noopener noreferrer"&gt;commit&lt;/a&gt;). Additionally, since v5.6, as soon as the CRNG (the Linux cryptographic-strength random number generator) gets ready, &lt;code&gt;/dev/random&lt;/code&gt; does not block on reads anymore (see &lt;a href="https://github.com/torvalds/linux/commit/30c08efec8884fb106b8e57094baa51bb4c44e32" rel="noopener noreferrer"&gt;this commit&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;I'm happy that these changes made it into the mainline kernel. It's pleasing to see that the main idea behind HAVEGED has sustained time test - it was published already in 2003 &lt;a href="https://www.irisa.fr/caps/projects/hipsor/publications/havege-tomacs.pdf" rel="nofollow noopener noreferrer"&gt;here.&lt;/a&gt; I'm also glad that the HAVEGE algorithm is being further explored and examined - see the &lt;a href="https://www.chronox.de/jent.html" rel="nofollow noopener noreferrer"&gt;CPU Jitter Random Number Generator.&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Please note that while the mainline Linux Kernel and HAVEGED are using the same concept to generate the entropy (utilizing the CPU jitter) the implementation is completely different. In this sense, HAVEGED can be viewed as another…&lt;/p&gt;
&lt;/div&gt;
  &lt;/div&gt;
  &lt;div class="gh-btn-container"&gt;&lt;a class="gh-btn" href="https://github.com/jirka-h/haveged" rel="noopener noreferrer"&gt;View on GitHub&lt;/a&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;br&gt;
In linux we have two random generators:&lt;code&gt;/dev/randon&lt;/code&gt; and &lt;code&gt;/dev/urandom&lt;/code&gt;. The first one is really fast, but it is predictable: one should not use it for any security-related things. The second one is more reliable, but can be very slow sometimes.

&lt;p&gt;The reason for that is that the kernel must collect enough entropy from outer sources (like CPU temperature, fan rpm and so on) to give you a truly random number. Even in a long time after boot the system may run out of entropy and processes will have to wait until there will be enough of it.&lt;/p&gt;

&lt;p&gt;I faced this several times, for example when I tried to connect via &lt;code&gt;ssh&lt;/code&gt; right after the system booted. The process have just "hung".&lt;/p&gt;

&lt;p&gt;To avoid this kind of issues you may install &lt;code&gt;haveged&lt;/code&gt; daemon. It uses additional algorithms to faster fill the entropy device and ensures that there is always enough of it.&lt;/p&gt;
&lt;h2&gt;
  
  
  fstrim
&lt;/h2&gt;

&lt;p&gt;Due to the architecture of SSDs, theirs memory chunks are "wearing out" when they are accessed. So it is a good idea to redistribute a load evenly between all chunks. To accomplish this we have to shuffle the data on the drive periodically.&lt;/p&gt;

&lt;p&gt;This operation is called TRIM and it can seriously prolong the life of your drive. More details and instructions can be found &lt;a href="https://www.digitalocean.com/community/tutorials/how-to-configure-periodic-trim-for-ssd-storage-on-linux-servers" rel="noopener noreferrer"&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;h2&gt;
  
  
  earlyoom
&lt;/h2&gt;


&lt;div class="ltag-github-readme-tag"&gt;
  &lt;div class="readme-overview"&gt;
    &lt;h2&gt;
      &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--A9-wwsHG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/github-logo-5a155e1f9a670af7944dd5e12375bc76ed542ea80224905ecaf878b9157cdefc.svg" alt="GitHub logo"&gt;
      &lt;a href="https://github.com/rfjakob" rel="noopener noreferrer"&gt;
        rfjakob
      &lt;/a&gt; / &lt;a href="https://github.com/rfjakob/earlyoom" rel="noopener noreferrer"&gt;
        earlyoom
      &lt;/a&gt;
    &lt;/h2&gt;
    &lt;h3&gt;
      earlyoom - Early OOM Daemon for Linux
    &lt;/h3&gt;
  &lt;/div&gt;
  &lt;div class="ltag-github-body"&gt;
    
&lt;div id="readme" class="md"&gt;
&lt;div class="markdown-heading"&gt;
&lt;h1 class="heading-element"&gt;earlyoom - The Early OOM Daemon&lt;/h1&gt;
&lt;/div&gt;
&lt;p&gt;&lt;a href="https://github.com/rfjakob/earlyoom/actions/workflows/ci.yml" rel="noopener noreferrer"&gt;&lt;img src="https://github.com/rfjakob/earlyoom/actions/workflows/ci.yml/badge.svg" alt="CI"&gt;&lt;/a&gt;
&lt;a href="https://github.com/rfjakob/earlyoomLICENSE" rel="noopener noreferrer"&gt;&lt;img src="https://camo.githubusercontent.com/6581c31c16c1b13ddc2efb92e2ad69a93ddc4a92fd871ff15d401c4c6c9155a4/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6c6963656e73652d4d49542d626c75652e737667" alt="MIT License"&gt;&lt;/a&gt;
&lt;a href="https://github.com/rfjakob/earlyoom/releases" rel="noopener noreferrer"&gt;&lt;img src="https://camo.githubusercontent.com/7cef9bde68a479bb24414b077944fc4dd4c2394f21adda6aa7ac0ba9a5d64d6e/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f72656c656173652f72666a616b6f622f6561726c796f6f6d2e737667" alt="Latest release"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The oom-killer generally has a bad reputation among Linux users. This may be
part of the reason Linux invokes it only when it has absolutely no other choice
It will swap out the desktop environment, drop the whole page cache and empty
every buffer before it will ultimately kill a process. At least that's what I
think that it will do. I have yet to be patient enough to wait for it, sitting
in front of an unresponsive system.&lt;/p&gt;
&lt;p&gt;This made me and other people wonder if the oom-killer could be configured to
step in earlier: &lt;a href="https://www.reddit.com/r/linux/comments/56r4xj/why_are_low_memory_conditions_handled_so_badly/" rel="nofollow noopener noreferrer"&gt;reddit r/linux&lt;/a&gt;, &lt;a href="http://superuser.com/questions/406101/is-it-possible-to-make-the-oom-killer-intervent-earlier" rel="nofollow noopener noreferrer"&gt;superuser.com&lt;/a&gt;, &lt;a href="http://unix.stackexchange.com/questions/38507/is-it-possible-to-trigger-oom-killer-on-forced-swapping" rel="nofollow noopener noreferrer"&gt;unix.stackexchange.com&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;As it turns out, no, it can't. At least using the in-kernel oom-killer
In the user space, however, we can do whatever we want.&lt;/p&gt;
&lt;p&gt;earlyoom wants to be simple and solid. It is written in pure C with no dependencies
An…&lt;/p&gt;
&lt;/div&gt;
  &lt;/div&gt;
  &lt;div class="gh-btn-container"&gt;&lt;a class="gh-btn" href="https://github.com/rfjakob/earlyoom" rel="noopener noreferrer"&gt;View on GitHub&lt;/a&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;br&gt;
Remember when we decided to launch Intellij Idea while watching a video? Let's imagine that we have only 8Gb of RAM - the amount that is totally insufficient for this (ARGH!).

&lt;p&gt;The Idea's JVM will first eat all &lt;code&gt;Xms&lt;/code&gt; then all &lt;code&gt;Xmx&lt;/code&gt; RAM, then we'll extend &lt;code&gt;Xmx&lt;/code&gt; it up to 6Gb, but there is also a &lt;code&gt;PermGen&lt;/code&gt; storage eating space and a movie and also you might want to run browser. The result is simple - we are terribly running out of memory.&lt;/p&gt;

&lt;p&gt;In cases like this, linux has a special mechanism called OOM-killer. When things goes bad like in the example above, linux just finds the most "greedy" process and kills it, so that other processes stay safe and alive. If it's not done than the computer will always be running "heavy" request that it is unable to satisfy and there will be no resources for anything else: the system will just hang.&lt;/p&gt;

&lt;p&gt;So, OOM-killer is your friend. The problem with it: it usually comes too late. The linux will fist try to move all your memory chunks to swap partition on disk drive and from that moment your desktop environment will freeze and whole system will become unresponsive. Much later, when linux ensures that there is only one way left, he'll call for killer. And unfortunately this behavior is not configurable (but you can call it manually, refer to the next section).&lt;/p&gt;

&lt;p&gt;&lt;code&gt;earlyoom&lt;/code&gt; can help you in this case. From docs:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;earlyoom checks the amount of available memory and free swap up to 10 times a second (less often if there is a lot of free memory). By default if both are below 10%, it will kill the largest process.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2&gt;
  
  
  &lt;a href="https://en.wikipedia.org/wiki/Magic_SysRq_key" rel="noopener noreferrer"&gt;SysRq&lt;/a&gt;
&lt;/h2&gt;
&lt;h6&gt;
  
  
  Well, technically it is not a daemon at all, but it still fits the list of "preventing your systems from becoming unresponsive" tricks.
&lt;/h6&gt;

&lt;p&gt;Missing &lt;code&gt;Ctrl&lt;/code&gt;+&lt;code&gt;Alt&lt;/code&gt;+&lt;code&gt;Del&lt;/code&gt; from Windows? It is a life-savior when things gone bad and we want to recover system somehow. In linux we've got a better solution, but you have to enable it first.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3nb8eo0a8djv1nozpr5k.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3nb8eo0a8djv1nozpr5k.jpg" alt="SysRq key" width="208" height="212"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Remember strange &lt;code&gt;SysRq&lt;/code&gt; key on your keyboard? It is magical! No, really, we call a shortcuts that involves it &lt;a href="https://en.wikipedia.org/wiki/Magic_SysRq_key" rel="noopener noreferrer"&gt;Magic SysRq keys&lt;/a&gt; :). You have two ways to enable it:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Add &lt;code&gt;sysrq_always_enabled=1&lt;/code&gt; to kernel boot parameters&lt;/li&gt;
&lt;li&gt;Add &lt;code&gt;kernel.sysrq=1&lt;/code&gt; to &lt;code&gt;sysctl&lt;/code&gt; configuration (usually &lt;code&gt;/etc/sysctl.conf&lt;/code&gt; or &lt;code&gt;/etc/sysctl.d/99-sysctl.conf&lt;/code&gt;)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;After that the whole list of commands from section header link becomes available. The most useful ones:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;SysRq&lt;/code&gt; + &lt;code&gt;F&lt;/code&gt;: Calls for OOM-killer&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;SysRq&lt;/code&gt; + &lt;code&gt;R&lt;/code&gt;,&lt;code&gt;E&lt;/code&gt;,&lt;code&gt;I&lt;/code&gt;,&lt;code&gt;S&lt;/code&gt;,&lt;code&gt;U&lt;/code&gt;,&lt;code&gt;B&lt;/code&gt;: Safely dumps caches to drive and performs a reboot.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;These key combinations are handled directly by the kernel and will help you to recover (or safely reboot) if nothing else helps.&lt;/p&gt;
&lt;h2&gt;
  
  
  fail2ban
&lt;/h2&gt;


&lt;div class="ltag-github-readme-tag"&gt;
  &lt;div class="readme-overview"&gt;
    &lt;h2&gt;
      &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--A9-wwsHG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/github-logo-5a155e1f9a670af7944dd5e12375bc76ed542ea80224905ecaf878b9157cdefc.svg" alt="GitHub logo"&gt;
      &lt;a href="https://github.com/fail2ban" rel="noopener noreferrer"&gt;
        fail2ban
      &lt;/a&gt; / &lt;a href="https://github.com/fail2ban/fail2ban" rel="noopener noreferrer"&gt;
        fail2ban
      &lt;/a&gt;
    &lt;/h2&gt;
    &lt;h3&gt;
      Daemon to ban hosts that cause multiple authentication errors
    &lt;/h3&gt;
  &lt;/div&gt;
  &lt;div class="ltag-github-body"&gt;
    
&lt;div id="readme" class="md"&gt;
&lt;div class="snippet-clipboard-content notranslate position-relative overflow-auto"&gt;&lt;pre class="notranslate"&gt;&lt;code&gt;                     __      _ _ ___ _               
                    / _|__ _(_) |_  ) |__  __ _ _ _  
                   |  _/ _` | | |/ /| '_ \/ _` | ' \ 
                   |_| \__,_|_|_/___|_.__/\__,_|_||_|
                   v1.1.0.dev1            20??/??/??
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;div class="markdown-heading"&gt;
&lt;h2 class="heading-element"&gt;Fail2Ban: ban hosts that cause multiple authentication errors&lt;/h2&gt;

&lt;/div&gt;
&lt;p&gt;Fail2Ban scans log files like &lt;code&gt;/var/log/auth.log&lt;/code&gt; and bans IP addresses conducting
too many failed login attempts. It does this by updating system firewall rules
to reject new connections from those IP addresses, for a configurable amount
of time. Fail2Ban comes out-of-the-box ready to read many standard log files,
such as those for sshd and Apache, and is easily configured to read any log
file of your choosing, for any error you wish.&lt;/p&gt;
&lt;p&gt;Though Fail2Ban is able to reduce the rate of incorrect authentication
attempts, it cannot eliminate the risk presented by weak authentication
Set up services to use only two factor, or public/private authentication
mechanisms if you really want to…&lt;/p&gt;
&lt;/div&gt;
  &lt;/div&gt;
  &lt;div class="gh-btn-container"&gt;&lt;a class="gh-btn" href="https://github.com/fail2ban/fail2ban" rel="noopener noreferrer"&gt;View on GitHub&lt;/a&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;br&gt;
Once I developed a web application at work and had a web server running in developer mode with logging all request. I forgot to turn it off before heading home and when I came back to an office in the morning - I was surprised! The log file was filled with tons of strange requests like:&lt;br&gt;


&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;404 GET /phpmyadmin/index.php
404 GET /ldap-accont-manager/index.php
404 GET /nextcloud/index.php
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Also, ssh log was filled with invalid authentication attempts. I notified our security expert and he confessed that it was he who scanned the network to find weak points :)&lt;/p&gt;

&lt;p&gt;Anyway,I thought that this situation is dangerous - you can sit in Moonbucks drinking coffee and at the same time someone bruteforces your ssh password. To prevent this kind of attacks meet &lt;code&gt;fail2ban&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This daemon monitors logs of various applications (apache, ssh and many more) for invalid auth attempts. If their count from one specific ip crosses the threshold, that ip is blocked using &lt;code&gt;iptables&lt;/code&gt; rule for some time. Stay safe :)&lt;/p&gt;

&lt;h2&gt;
  
  
  Conclusion
&lt;/h2&gt;

&lt;p&gt;Hope your enjoyed this (my fist) post. If you'll find any typos or mistakes - please PM me. If you have suggestions or something to add - leave a comment. Have a nice day!&lt;/p&gt;

</description>
      <category>linux</category>
    </item>
  </channel>
</rss>
