Find and block failed SSH logins on CentOS

Got a problem with others trying to brute force the root password on your box?

I'm not running vsftpd, yet it's a similar process. My concern is limited to third-parties trying to access my box with SSH.
This is what I did:
Tecmint showed me how to grep the IPs:

# egrep "Failed|Failure" /var/log/secure
Apr  7 03:42:13 67 sshd[4868]: Failed password for root from 186.233.231.44 port 56075 ssh2
Apr  7 03:45:19 67 sshd[4871]: Failed password for root from 38.140.192.165 port 52138 ssh2
Apr  7 03:47:16 67 sshd[4874]: Failed password for root from 35.221.157.112 port 36306 ssh2
Apr  7 03:49:01 67 sshd[4877]: Failed password for root from 153.127.193.168 port 40604 ssh2
Apr  7 03:50:54 67 sshd[4881]: Failed password for root from 89.109.54.214 port 52268 ssh2
Apr  7 04:01:07 67 sshd[4900]: Failed password for root from 14.63.192.249 port 37507 ssh2
Apr  7 04:04:49 67 sshd[4905]: Failed password for root from 41.228.165.225 port 35462 ssh2
Apr  7 04:05:40 67 sshd[4909]: Failed password for root from 195.142.122.126 port 42548 ssh2
Apr  7 04:16:17 67 sshd[4914]: Failed password for root from 103.120.224.3 port 51416 ssh2
Apr  7 04:26:00 67 sshd[4919]: Failed password for root from 139.59.79.56 port 40074 ssh2
Apr  7 04:37:27 67 sshd[4925]: Failed password for root from 103.27.236.2 port 60528 ssh2
Apr  7 04:44:33 67 sshd[4968]: Failed password for root from 18.214.68.139 port 60896 ssh2
Apr  7 04:53:24 67 sshd[4991]: Failed password for root from 193.36.184.175 port 41408 ssh2
Apr  7 04:56:09 67 sshd[4995]: Failed password for root from 1.250.62.223 port 59052 ssh2
Apr  7 05:00:45 67 sshd[4998]: Failed password for root from 183.82.63.212 port 43840 ssh2
Apr  7 05:05:41 67 sshd[5016]: Failed password for root from 186.103.146.148 port 55982 ssh2
Apr  7 05:10:14 67 sshd[5038]: Failed password for root from 68.183.4.19 port 34894 ssh2

From there I updated my /etc/hosts.deny file to the following:

# /etc/hosts.deny
#
# hosts.deny    This file contains access rules which are used to
#               deny connections to network services that either use
#               the tcp_wrappers library or that have been
#               started through a tcp_wrappers-enabled xinetd.
#
#               The rules in this file can also be set up in
#               /etc/hosts.allow with a 'deny' option instead.
#
#               See 'man 5 hosts_options' and 'man 5 hosts_access'
#               for information on rule syntax.
#               See 'man tcpd' for information on tcp_wrappers
#
sshd: 186.233.231.44
sshd: 38.140.192.165
sshd: 35.221.157.112
sshd: 153.127.193.168
sshd: 89.109.54.214
sshd: 14.63.192.249
sshd: 41.228.165.225
sshd: 195.142.122.126
sshd: 103.120.224.3
sshd: 139.59.79.56
sshd: 103.27.236.2
sshd: 18.214.68.139
sshd: 193.36.184.175
sshd: 1.250.62.223
sshd: 183.82.63.212
sshd: 186.103.146.148
sshd: 68.183.4.19

Just let systemd know it needs to update changes, and voila. It's done.

# systemctl restart sshd

Deno, the new paradigm in writing full stack applications with Javascript

Deno is a new language paradigm. It’s a frontier where intelligent design decisions intersect with the bleeding edge of technology, and backed by a great community of open source contributors.

I’ve had the fortune of spending time with some of the contributors that helped guide my learning that I would like to share with you here.

Building Deno

It’s not just about cargo build, be sure to run tools/setup.py, update submodules, and run tools/build.py — these are explained much more well in the references below.

Flatbuffers in Deno

The primary benefit of Deno is although V8 exists in the runtime it’s abstracted away from end-users. Whereas Node was weighed down by having to directly interact with V8, Deno placed substantial consideration and effort to avoid having developers and contributors rely on interacting with V8, which benefits in a variety of ways:

• no longer having to deal with the subtle mishandlings that developers fear when it comes to using C++ 
• no longer having to know and interact with the inner workings of a very large code base that exists in V8
• leveraging the power of Rust’s benefits for resource management, concurrency, and parallelism

There’s also the issue of implementing best practices, and Flatbuffers enters the space here. Similar to Protobuf in that message parsing can be serialized and deserialized across a variety of languages, Flatbuffers can consume much less memory than Protocol Buffers, and work much more fast and smart.

This is only a sampling of what makes Deno exciting, and I haven’t even scratched the surface yet.

Check out the Flatbuffer declarations in src/msg.fbs

Essentially, the Typescript frontend will serialize messages to a Rust backend that’s managed by the Tokio framework (https://github.com/tokio-rs/tokio). The Rust backend deserializes the message, performs the task, serializes the response, and sends it back to the Typescript.

Navigating Deno

Open src/main.rs and proceed to navigate from there. One point to note is that the standard library exists as a submodule that can be found in the denoland at Github (https://github.com/denoland/).

I hope you check it out for yourself. Deno’s looking forward to a bright future, and it’s just getting started!

Resources:

Denolib Guide, a guide to Deno Core: https://github.com/denolib/guide

Awesome Deno, list of things related to Deno: https://github.com/denolib/awesome-deno

Guide to V8 for base familiarity: https://denolib.github.io/v8-docs/

mongoexport Unrecognized field 'snapshot'

Try to get your data out of Mongo and you may find yourself butting heads with

Unrecognized field 'snapshot' 

You should know there are options to skip including `snapshot` in your export query, my guess is this applies to dumps also.

https://github.com/mongodb/mongo-tools/blob/master/mongoexport/mongoexport.go

To get around this error, pass in the flag:

# mongoexport  --forceTableScan -d db_name -c collection_name > my_export.json

Error type 3: Activity class does not exist

This happens when you do the following

• connect your device/emulator
• run the app from Android Studio (AS)
• use/test the app and uninstall it from the device while it is still connected to your computer
• try to run the app again from AS

AS thinks you still have the app in your device.

tl;dr - To resolve this issue for connected devices you can uninstall with ADB:

$ adb shell pm list packages

package:com.foo.foo

$ adb uninstall com.foo.foo

Success

Run app from AS again after uninstalling with ADB.

Part 2: React in Electron

The ability to utilize next-gen building platforms without headache-free style

---

What headache? Are you a f**##$ idiot?!

There's no bigger headache for me than to exercise hours for build tools, and non-trivial development pipelines at the inception of a project.

React is a library who's intention is to simplify the development of user facing applications; and built by Facebook (Thanks Facebook!).

(Oh yeah, it uses Javascript.. That is pretty cool.)

---

RE: React, play well with Electron

    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.0.1/react.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.0.1/react-dom.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.8.1/axios.min.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.min.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.min.js"></script>

dependencies necessary for React to play with Electron, plus axios

Let's get some React to integrate!

Check out this awesome project at CodePen!

ok, plugging it in, you should have something similar to the project in this repo!

Part 1: Child process as prelude to interprocess communication

The child process as prelude to interprocess communication

---

What the hell are you talking about??
Not EMScripten, not any R&D cool finding, just some observation of using the Electron app pattern.

Electron is a cross-platform framework that glues system and browser via interprocess communications; and developed by Github (major thanks!).

(Oh yeah, it uses Javascript.. That is pretty cool.)

---

EE: Electron boiler, meet Express boiler

'use strict';

const electron = require('electron');
const app = electron.app;
const BrowserWindow = electron.BrowserWindow;
const url = 'http://127.0.0.1:1987';

let mainWindow, child;

function windowRouter(_route) {
  return url + '/' + (_route || '');
}

function renderWindow() {
  mainWindow = new BrowserWindow({width: 800, height: 600});
  mainWindow.loadURL(windowRouter());
  // default to inspector mode in Chromium
  mainWindow.webContents.openDevTools();
  mainWindow.on('closed', function() {
    mainWindow = null;
  });
}

function createWindow () {
  renderWindow();
  let exec = require('child_process').exec;
  child = exec('node ./server.js');
  child.stdout.on('data', function(data) {
      console.log('stdout: ' + data);
  });
  child.stderr.on('data', function(data) {
      console.log('stdout: ' + data);
  });
  child.on('close', function(code) {
      console.log('closing code: ' + code);
      child.kill();
  });
}

app.on('ready', createWindow);

app.on('window-all-closed', function () {
  if (process.platform !== 'darwin') {
    app.quit();
    child.kill();
  }
});

app.on('activate', function () {
  if (mainWindow === null) {
    createWindow();
  }
});

main.js

#!/usr/bin/env node
var express = require('express');
var app = module.exports = express();
var server = require('http').createServer(app);
var bodyParser = require('body-parser');
app.set('trust proxy', true);
app.use(bodyParser.json({limit: '50mb'}));
app.use(bodyParser.urlencoded({limit: '50mb', extended: true}));
app.use(require('cookie-parser')());

app.get('/', function(req, res) {
  console.log('GET /');
  res.send('<h1>foo lala</h1>');
})

var port = 1987;
var ipaddr = '127.0.0.1';
server.listen(port, ipaddr, function() {
  console.log('Express server listening on port ' + server.address().port + ' at ' + server.address().address);
});

server.js

npm start

> electron-quick-start@1.0.0 start /var/www/electron-quick-start
> electron main.js

stdout: Express server listening on port 1987 at 127.0.0.1

stdout: GET /

terminal

browser

The JS above was near identical, and the HTML was identical, to Electron's boilerplate, and package.json required modifying the additional packages. It's a good place to start!

JS E Patterns

Events in JS are pretty amazing, and notifications or emits or emissions or what have you are quite often fundamental to programming with JS. In the case of UI it's literally every user interaction; and for pubsub mechanisms the same also holds true.

JS has a method Event.stopPropagation that here I will make the case introduces an anti-pattern to your code.

Here's the scenario:

user clicks submit on a form button, the code would look like the following:

submit.onclick = function(e) {
e.preventDefault() // similar method here
// .. do your thing
e.stopPropagation(); // stop furthering the event
}

1) Event occurs, and there is one file, and one method that the event is used.

Stopping event propagation here is nominal. This is a good use case, although it wouldn't make much difference to use stopPropagation.

2) You have multiple files that have multiple event listener methods.

Using stopEventPropagation should be avoided because it can act as an anti-pattern, here's how:

Let's say we have two different methods, and in two different files:

method1, file1

function eListener1(e, p) {
// tasks of eL1
}

and

method2, file2

function eListener2(e, p) {
// tasks of eL2
}

By definition, the layout of your code is completely different in the two scenarios .. one you're very much in the same place, and the other you leave to the great open yonder, not knowing exactly why or who is going to use something from somewhere as you're buidling.

To stop event propagation here is a mistake, and it would block tasks including delegation, and future use cases. For instance, suppose that your event is currently active in eL1 above; and now you want to create another event listener in another class or file that you will call eListener3 to perform some task on the same event. You would not be able to do this with stopPropagation; in effect you've limited your own possibilities, and another rate limiting step added to the soup is now that method that I will argue should have been avoided.

Stopping propagation is appropriate for a terminal event, such as deleting an item that has a known end; and not for general user interaction events. Signing out, for instance, could be another use case, however, would be redundant in many cases.

For general events, it's wasted energy. The consideration for stopEventPropagation at the general event level is perhaps at the heart of the rift between TCP or UDP versus TCP/IP.

In general, it's a good idea to avoid exotic methods unless you know exactly why you're using them. However, if you are building massively scaled TCP/IP request based systems that send large amounts of data, then this may not apply to you. 

A potential or real benefit of stopEventPropagation is saving computing and/or bandwidth resources.

So what's someone to do without stopping propagation?? Glad you asked, it's the simple conditional. The key here is to add a unique identifier to your object (i.e. this.supercalifradgilisticexpialidocious = 'here it is';), and in every one of your listeners you'd have your conditionals:

function eListener3(e, p) {
if (e === 'click') {
switch (p.foo.supercalifradgilisticexpialidocious) {
case 'here it is': {
// do func
break;
}

default: break;
}
}
}