fail2ban setting.

https://www.howtogeek.com/675010/how-to-secure-your-linux-computer-with-fail2ban/

https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-7

Let's begin by writing a very simple version of jail.local. Open a new file using nano (or your editor of choice):

sudo nano /etc/fail2ban/jail.local

Paste the following:

/etc/fail2ban/jail.local

[DEFAULT]
# Ban hosts for one hour:
bantime = 3600

# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = iptables-multiport

[sshd]
enabled = true

This overrides three settings: It sets a new default bantime for all services, makes sure we're using iptables for firewall configuration, and enables the sshd jail.
Exit and save the new file (in nano, press Ctrl-X to exit, y to save, and Enter to confirm the filename). Now we can restart the fail2ban service using systemctl:

sudo systemctl restart fail2ban

The systemctl command should finish without any output. In order to check that the service is running, we can use fail2ban-client:

sudo fail2ban-client status

Output
Status
|- Number of jail:      1
`- Jail list:   sshd

You can also get more detailed information about a specific jail:

sudo fail2ban-client status sshd

Explore Available Settings

The version of jail.local we defined above is a good start, but you may want to adjust a number of other settings. Open jail.conf, and we'll examine some of the defaults. If you decide to change any of these values, remember that they should be copied to the appropriate section of jail.local and adjusted there, rather than modified in-place.

sudo nano /etc/fail2ban/jail.conf

Default Settings for All Jails

First, scroll through the [DEFAULT] section.

ignoreip = 127.0.0.1/8

You can adjust the source addresses that Fail2ban ignores by adding a value to the ignoreip parameter. Currently, it is configured not to ban any traffic coming from the local machine. You can include additional addresses to ignore by appending them to the end of the parameter, separated by a space.

bantime = 600

The bantime parameter sets the length of time that a client will be banned when they have failed to authenticate correctly. This is measured in seconds. By default, this is set to 600 seconds, or 10 minutes.

findtime = 600
maxretry = 3

The next two parameters that you want to pay attention to are findtime and maxretry. These work together to establish the conditions under which a client should be banned.
The maxretry variable sets the number of tries a client has to authenticate within a window of time defined by findtime, before being banned. With the default settings, Fail2ban will ban a client that unsuccessfully attempts to log in 3 times within a 10 minute window.

destemail = root@localhost
sendername = Fail2Ban
mta = sendmail

If you wish to configure email alerts, you may need to override the destemail, sendername, and mta settings. The destemail parameter sets the email address that should receive ban messages. The sendername sets the value of the "From" field in the email. The mta parameter configures what mail service will be used to send mail.

action = $(action_)s

This parameter configures the action that Fail2ban takes when it wants to institute a ban. The value action_ is defined in the file shortly before this parameter. The default action is to simply configure the firewall to reject traffic from the offending host until the ban time elapses.
If you would like to configure email alerts, you can override this value from action_ to action_mw. If you want the email to include the relevant log lines, you can change it to action_mwl. You'll want to make sure you have the appropriate mail settings configured if you choose to use mail alerts.

Settings for Individual Jails

After [DEFAULT], we'll encounter sections configuring individual jails for different services. These will typically include a port to be banned and a logpath to monitor for malicious access attempts. For example, the SSH jail we already enabled in jail.local has the following settings:

/etc/fail2ban/jail.local

[sshd]

port    = ssh
logpath = %(sshd_log)s

In this case, ssh is a pre-defined variable for the standard SSH port, and %(sshd_log)s uses a value defined elsewhere in Fail2ban's standard configuration (this helps keep jail.conf portable between different operating systems).
Another setting you may encounter is the filter that will be used to decide whether a line in a log indicates a failed authentication.
The filter value is actually a reference to a file located in the /etc/fail2ban/filter.d directory, with its .conf extension removed. This file contains the regular expressions that determine whether a line in the log is bad. We won't be covering this file in-depth in this guide, because it is fairly complex and the predefined settings match appropriate lines well.
However, you can see what kind of filters are available by looking into that directory:

ls /etc/fail2ban/filter.d

If you see a file that looks to be related to a service you are using, you should open it with a text editor. Most of the files are fairly well commented and you should be able to tell what type of condition the script was designed to guard against. Most of these filters have appropriate (disabled) sections in jail.conf that we can enable in jail.local if desired.
For instance, pretend that we are serving a website using Nginx and realize that a password-protected portion of our site is getting slammed with login attempts. We can tell Fail2ban to use the nginx-http-auth.conf file to check for this condition within the /var/log/nginx/error.log file.
This is actually already set up in a section called [nginx-http-auth] in our /etc/fail2ban/jail.conf file. We would just need to add an enabled parameter for the nginx-http-auth jail to jail.local:

/etc/fail2ban/jail.local

[DEFAULT]
# Ban hosts for one hour:
bantime = 3600

# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = iptables-multiport

[sshd]
enabled = true

[nginx-http-auth]
enabled = true

And restart the fail2ban service:

sudo systemctl restart fail2ban

Monitor Fail2ban Logs and Firewall Configuration

It's important to know that a service like Fail2ban is working as-intended. Start by using systemctl to check the status of the service:

sudo systemctl status fail2ban

If something seems amiss here, you can troubleshoot by checking logs for the fail2ban unit since the last boot:

sudo journalctl -b -u fail2ban

Next, use fail2ban-client to query the overall status of fail2ban-server, or any individual jail:

sudo fail2ban-client status

sudo fail2ban-client status jail_name

Follow Fail2ban's log for a record of recent actions (press Ctrl-C to exit):

sudo tail -F /var/log/fail2ban.log

List the current rules configured for iptables:

sudo iptables -L

Show iptables rules in a format that reflects the commands necessary to enable each rule:

sudo iptables -S

unordered_set / unordered_map with custom object in C++

http://stackoverflow.com/questions/17016175/c-unordered-map-using-a-custom-class-type-as-the-key

To be able to use std::unordered_map (or one of the other unordered associative containers) with a user-defined key-type, you need to define two things: A hash function; this must be a class that overrides operator() and calculates the hash value given an object of the key-type. One particularly straight-forward way of doing this is to specialize the std::hash template for your key-type. A comparison function for equality; this is required because the hash cannot rely on the fact that the hash function will always provide a unique hash value for every distinct key (i.e., it needs to be able to deal with collisions), so it needs a way to compare two given keys for an exact match. You can implement this either as a class that overrides operator(), or as a specialization of std::equal, or – easiest of all – by overloading operator==() for your key type (as you did already). The difficulty with the hash function is that if your key type consists of several members, you will usually have the hash function calculate hash values for the individual members, and then somehow combine them into one hash value for the entire object. For good performance (i.e., few collisions) you should think carefully about how to combine the individual hash values to ensure you avoid getting the same output for different objects too often. A fairly good starting point for a hash function is one that uses bit shifting and bitwise XOR to combine the individual hash values. For example, assuming a key-type like this:   struct Key { std::string first; std::string second; int third; bool operator==(const Key &other) const { return (first == other.first && second == other.second && third == other.third); } }; Here is a simple hash function (adapted from the one used in the cppreference example for user-defined hash functions): namespace std { template <> struct hash<Key> { std::size_t operator()(const Key& k) const { using std::size_t; using std::hash; using std::string; // Compute individual hash values for first, // second and third and combine them using XOR // and bit shifting: return ((hash()(k.first) ^ (hash()(k.second) << 1)) >> 1) ^ (hash()(k.third) << 1); } }; } With this in place, you can instantiate a std::unordered_map for the key-type: int main() { std::unordered_map<Key,std::string> m6 = { { {"John", "Doe", 12}, "example"}, { {"Mary", "Sue", 21}, "another"} }; } It will automatically use std::hash as defined above for the hash value calculations, and the operator== defined as member function of Key for equality checks. If you don't want to specialize template inside the std namespace (although it's perfectly legal in this case), you can define the hash function as a separate class and add it to the template argument list for the map: struct KeyHasher { std::size_t operator()(const Key& k) const { using std::size_t; using std::hash; using std::string; return ((hash()(k.first) ^ (hash()(k.second) << 1)) >> 1) ^ (hash()(k.third) << 1); } }; int main() { std::unordered_map<Key,std::string,KeyHasher> m6 = { { {"John", "Doe", 12}, "example"}, { {"Mary", "Sue", 21}, "another"} }; } How to define a better hash function? As said above, defining a good hash function is important to avoid collisions and get good performance. For a real good one you need to take into account the distribution of possible values of all fields and define a hash function that projects that distribution to a space of possible results as wide and evenly distributed as possible. This can be difficult; the XOR/bit-shifting method above is probably not a bad start. For a slightly better start, you may use the hash_value and hash_combine function template from the Boost library. The former acts in a similar way as std::hash for standard types (recently also including tuples and other useful standard types); the latter helps you combine individual hash values into one. Here is a rewrite of the hash function that uses the Boost helper functions: #include struct KeyHasher { std::size_t operator()(const Key& k) const { using boost::hash_value; using boost::hash_combine; // Start with a hash value of 0 . std::size_t seed = 0; // Modify 'seed' by XORing and bit-shifting in // one member of 'Key' after the other: hash_combine(seed,hash_value(k.first)); hash_combine(seed,hash_value(k.second)); hash_combine(seed,hash_value(k.third)); // Return the result. return seed; } }; And here’s a rewrite that doesn’t use boost, yet uses good method of combining the hashes: namespace std { template <> struct hash<Key> { size_t operator()( const Key& k ) const { // Compute individual hash values for first, second and third // http://stackoverflow.com/a/1646913/126995 size_t res = 17; res = res * 31 + hash()( k.first ); res = res * 31 + hash()( k.second ); res = res * 31 + hash()( k.third ); return res; } }; }

random number generation in C++. with better distribution.

random number generation in C++.  with better distribution.


int getRand() //generater random number between 1 to 5
{
    std::default_random_engine generator;
    generator.seed(std::random_device()());
    std::uniform_int_distribution distribution(1,5);
    int randomNumber = distribution(generator);
    return randomNumber;
}

firefox cache management

http://lifehacker.com/5687850/speed-up-firefox-by-moving-your-cache-to-ram-no-ram-disk-required

Since your computer can access data in RAM faster than on a hard drive, moving cached data to RAM can improve your page load times. In Firefox, all you need to do to move your caches to RAM is open up about:config and make a few tweaks.

Once you get into about:config, type browser.cache into the filter bar at the top. Find browser.cache.disk.enable and set it to false by double clicking on it. You'll then want to set browser.cache.memory.enable to true (mine seemed to already be set as such), and create a new preference by right clicking anywhere, hitting New, and choosing Integer. Call the preference browser.cache.memory.capacity and hit OK. In the next window, type in the number of kilobytes you want to assign to the cache (for example, typing 100000 would create a cache of 100,000 kilobytes or 100 megabytes). A value of -1 will tell Firefox to dynamically determine the cache size depending on how much RAM you have.

linux iptables

https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/

Methods to Stop SSH Brute Force Attacks
There are basically four approaches to dealing with SSH brute force attacks:

    Restrict SSH access by IP address
    Change SSH to another Port
    Use intrusion prevention tools to dynamically block access
    Rates limit SSH sessions using IPTables

All of these approaches have theirs benefits and drawbacks.

While restricting SSH access by IP address is the most secure method, such restrictions are often not possible when dealing with web hosting services as you have multiple users with constantly changing IP addresses.

Changing the SSH port may defeat bot scans but does little against targeted attacks.  Also, this usually just frustrates your users.

Intrusion prevention tools like fail2ban and denyhosts have their place but they are subject to log based attacks.  These tools essential analyze logs using regular expressions.  Hackers have found ways around both of these tools in the past.

Lastly, you have a great tool to block ssh brute force attacks right on your server: IPtables.
Using IPtables to Stop SSH Brute Force Attacks

I like to think of this approach similar to flow rates with pipes.  Bigger pipes allow more water to flow.  Smaller pipes can handle less water.

control ssh access with iptables

To block a SSH brute force attack, we just need to slow down the flow of requests. We can do this by rate-limiting requests to SSH with iptables.

Essentially, we create a smaller pipe for new SSH sessions.  This slows brute force attacks to a point where they become ineffective.

The iptables rules are relatively simple.
   
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP

This rule will block an IP if it attempts more than 3 connections per minute to SSH. Notice that the state is set to NEW. This means only new connections not established ones are impacted. Established connections are the result of a successful SSH authentication, so users who authenticate properly will not be blocked.

If you need to see what’s being done, you may want to log these drops. You can do so by setting up a log rule and then using these rules instead.
   
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j LOGDROP



please use iptables-persistent; it's the easy way: Install iptables-persistent:

    sudo apt-get install iptables-persistent

After it's installed, you can save/reload iptables rules anytime:

    sudo /etc/init.d/iptables-persistent save
    sudo /etc/init.d/iptables-persistent reload

Ubuntu joypad setting

install jstest for joypad
sudo apt-get install jstest-gtk

test if joypad is working by following command.
jstest /dev/input/js0

ubuntu 16.04 medafen sound fix

Ubuntu fix mednafen broken sound

setting file is created under .mednafen in user directory after a user executes mednafen once
//mednafen-09x.cfg

The configuration would be:

;Select sound output device.
sound.device sexyal-literal-default

;Select sound driver.
sound.driver SDL