Author: Alexander

  • How to reduce a possibility of brute force attacks on WordPress

    How to reduce a possibility of brute force attacks on WordPress

    Until the moment when CleanTalk launched a security plugin, I didn’t pay much attention to the security of the admin account of WordPress and relied only on the complexity of the password.

    The most dangerous thing is when the bots use brute-force; pick up the password to the administrator account of the site. This can lead to very serious problems, as the attacker gets full access to the administrator account. On your website can be added malicious code, the site can be added to a botnet and participate in other attacks or the spread of viruses. The consequences for the reputation can be very sad.

    When the security plugin was launched I began to receive reports on the work of the plugin in which specify the statistics of failed login attempts to the admin account of WordPress. And for each day of such attempts was from 4 to 25, from different IP addresses. These were attempts of bots password guessing.

    What I noticed:

    1. Bots knew my login and password was selected to it.
    2. I do not use the default username Admin and changed it.
    3. In the blog there are other admin accounts, but attempts to break them for a few days of observation did not happen.

    Wondering how the bots found out my account and why not try to hack other accounts of administrators? Quite simply, under my account I place posts and write comments, and other accounts are made for employees, host and other people that perform actions only in the dashboard of the website.

    Based on this, I realized that the bots find out the login via the parsing of pages. Many publish posts and comments from the admin account.

    For example, you publish a blog post; the link to the author will be like this http://example.com/author/admin***/. Bots browsing the code of your website looking for recordings of this type on all pages of the website and collect links from all accounts.

    The same thing will happen if you write a comment from the admin account, only the link will be a bit of a different kind http://example.com/members/admin***/

    Even if you once published a post or comment from admin account, then the bots will find it and will try to crack it.

    I described one of the possible scenarios of obtaining a list of accounts for hacking, there may be others. But experience has shown that if the WordPress administrator account is not used for publications and comments on the website, its bots do not know.

    What to do in order to minimize the possibility of hacking the account of the administrator of the website.

    1. Not to publish posts and comments from the administrator account.
    2. Create an account for each administrator with another role such as Author or Editor. It all depends on your needs.
    3. Change the current administrator user. Attention! Before that, you need to backup your website and databases. I can’t recommend this and if you do this at your own risk, as this may lead to undesirable consequences.

    You will need to create a new user with administrator rights and a user with another role such as Author. Login to the dashboard with the new account and test the capabilities of the Administrator to manage site, settings and users.

    Go to the “Users” and delete the previous admin account, WordPress will ask you to whom to reassign the articles and comments, here is useful pre-created user Author. Reassign articles on it and in the future use to publish posts and comments.

    These actions can be done for other accounts administrators. But for most WordPress users would rather to install one of the plugins for protection from brute-force attacks, such as plugin Security & Firewall from CleanTalk.

  • A brief history of passwords from the P to the S: birth, death and the zombie apocalypse

    A brief history of passwords from the P to the S: birth, death and the zombie apocalypse

    The attack on the World Trade Center towers on 11 September 2001 claimed the lives of 658 employees of the financial company Cantor Fitzgerald. Its Director Howard Lutnick lost that day his brother, faced with an unprecedented problem. And it wasn’t even that the company’s servers, including backup, was also buried under the rubble. Information was partly available, but it was closed behind hundreds of accounts of perished colleagues. For assistance was attracted experts from the company Microsoft, they have used powerful servers for fast brute-force — from data access depended on the existence of the company, and it was necessary to time for the first opening of trading after the attacks. To accelerate the breaking could personal data of the victims. Lutnick had to call relatives, and, at the most inopportune moment, ask them a series of questions: the wedding day, the name of the college or university, the dog’s name.

    (more…)

  • API Method to Getting Country Code by IP Address.

    We are pleased to announce the launch of a new API method.

    Now you can get a country code to identify the country by IP address by one API call.

    The API method returns a 2 letters country code (US, UK, CN and etc) or full country name (Germany, Canada) for an IP address. Limit to the number of data is 1000.

    The instruction of how to use this method you can find here.
    https://cleantalk.org/help/api-ip-info-country-code

  • CleanTalk launches a project to ensure the safety of websites

    CleanTalk launches a major project to create a cloud service for the safety of websites. The project will include several functions: protect the site against brute force attacks, vulnerability scanner and virus removal.

    Each function will have a number of features which help you easily keep the website safe from hackers.

    (more…)

  • Visualization of attacks, anomalies and security breaches with OpenGraphiti

    Those who visit our headquarters in San Jose (Cisco Systems) always amazes large video wall that displays a picture of attacks in real time with the ability to drill after touching certain areas of the screen.

    However, like any map attacks, and I have collection of already 34, any such visualization is ineffective in real life. Show to superiors, show to journalists, to include in any movie… It’s all useful, but not very applicable in practice. Usually you have your own data sets that are generated by your protection. And you wonder what is happening in your network or directed at your network, but certainly not the beautiful card with the “ballistic missile attacks”, which are drawn by the absolute majority of companies offering visualization services attacks.

    (more…)

  • Phishing on a new level: Cloudflare + Protonmail + Unvalidated Redirects – set of young Fisher

    “… you come to me, and you ask something, but you don’t ask with respect …”

    Vito Corleone

    Phishing is still the most popular and most successful type of hacker attacks. It’s simple, attacked is not the software, not servers, not networks, and the most vulnerable components of information systems – users. I often meet with phishing, as a single, to personal addresses, and mass attacks. In most cases, it is awkwardly composed letters and clumsily made phishing pages. Until recently most of these attacks frustrated at the user level: letters or just ignored (as the signs of phishing was very obvious) or in the worst case, the letters are forwarded to customer support with the question “is it safe to enter your password on this page?”. Of course, some part of users still underway, but in percentage terms, it was really low. But just last week I was faced with a phishing attack, which surprised me. I did some analysis and found out how it was organized and what tools were used.

    (more…)

  • Best practices to protect e-commerce sites

    Best practices to protect e-commerce sites

    Online shopping has always attracted intruders: it is a source of credit card data (now almost irrelevant); user data; data about orders and market trends (consumer demand); a traffic source; manipulation with the discount coupons, etc. An e-commerce site may be attacked as intruders in “free hunting” (non-targeted attack) and by the request of unfair competition. Recently are popular different kinds of DoS/DDoS attacks, as to disable a competitor and as a tool for blackmail.

    In this topic, I will describe best practices for the protection of e-commerce sites.

    (more…)

  • Protect SSH from brute-force on any port

    Today I was interested in the survey whether it is necessary to move SSH to a nonstandard port. The survey is not as interesting as the way the author @zivot_je_cudo to protect SSH from brute-force password: after wrong connection attempts to block new attempts within 20 seconds. The delay apparently chosen empirically on the basis of two opposite requests: to not lock yourself in case of misspelling a long time, and at the same time, make life difficult for the picker. I want to share my way to resist brute-force, which is used for several years. It has two advantages:

    • it gives me more attempts to set the correct password
    • but at the same time blocks the brute force “forever”.

    How can I achieve these two opposite goals?

    I use module iptables called hashlimit, which is able to count the number of packets in a certain period of time and after a while to reset the counter.
    Everything is done by three rules:

    iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m hashlimit –hashlimit 1/hour –hashlimit-burst 2 –hashlimit-mode srcip –hashlimit-name SSH –hashlimit-htable-expire 60000 -j ACCEPT

    iptables -A INPUT -p tcp -m tcp –dport 22 –tcp-flags SYN,RST,ACK SYN -j DROP

    iptables -A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT

    What makes the second and the third rule is clear. The most interesting in the first: it allows two connection attempts for an hour. Once you exceed 2 attempts for a specified time, rule with -j ACCEPT stops working, the user instead of this goes into the following rule with -j DROP (exactly the same way you can put TARPIT).

    After that, you will not be able to connect, and starts the countdown 60,000 milliseconds, after which information about your attempt to “become rotten” (parameter –hashlimit-htable-expire). That is you really are not come to wait 1 hour, and just only 1 minute. The whole ruse is that if you cannot wait this time and try again to connect, the packet will be killed, and the counter is again reset back to is  initial state –  1 minute! Thus, if you are impatient and stupid bruteforcer and will hammer away the port after blocking, you’ll prolong your ban with each attempt! That is, you will ban yourself forever!

    Good user on the contrary has multiple connection attempts without waiting between them, before he get into the “bath”.

    hashlimit module saves its state in the / proc – initially it’s empty:

    # cat /proc/net/ipt_hashlimit/SSH

    after the first connection attempt information gets there:

    # cat /proc/net/ipt_hashlimit/SSH
    55 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 11533000 230400000 115000000

    the first number is the number of seconds remaining, you can see how it evenly ticking:

    # cat /proc/net/ipt_hashlimit/SSH
    20 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 117429000 230400000 115000000

    After I did it, I really wanted to check it out. And wow! The ball comes to the player! I immediately began to brute-force by some Chinese. The first four attempts passed, and further he stupidly knocked the closed door within the hour (!). During this entire hour he managed to check only four passwords! Then, apparently, he tired.

    Thus solved two problems:

    — if the user suddenly sealed, he didn’t have to wait long for new attempts

    — bruteforcer themselves driven into an “eternal” ban.

    What if you suddenly with a few attempts were not able to enter your password? Do not fuss – wait a minute, and calmly try a few more times.

    And if you again failed – it is better to go to sleep, in this state it is better not to go into the console :))

    Good luck.

    P.S. And yes, I almost forgot — I have SSH on non-standard port 🙂

    UPD: A little about setting hashlimit.

    UPD2: How to achieve the same with a more recent common module: one, two.

    UPD3: Of course the method is suitable not only for protection from password guessing on SSH, but can be used for various other services, where too often the connection indicates something is wrong.

    UPD4: The connections limit using the SSHD.

    This text is a translation of the article “Защищаем SSH от брутфорса на любом порту”  published by Евгений Лисицкий on habrahabr.ru.

    About the CleanTalk service

    CleanTalk is a cloud service to protect websites from spam bots. CleanTalk uses protection methods that are invisible to the visitors of the website. This allows you to abandon the methods of protection that require the user to prove that he is a human (captcha, question-answer etc.).

  • How to strengthen the protection of passwords of “12345” from brute-force attack

    Object: Web login form.
    Given task: to strengthen the protection of the user’s account from the selection of a simple password to his account, using a minimum of resources.

    What is the minimum of resources? It does not use a table-reference to block by IP-address and User-Agent. Do not use unnecessary requests to the system; do not clutter up the system with unnecessary authorization cycles.

    And, to do the magic requirement — even if the bot will enter the required username and password… do not let him enter, but the real user to let.

    Is it possible to do that? In theory, of course not. But in practice, and in private, under certain conditions, it proved to be quite possible.
    Welcome under cut for details.

    So, let’s assume that our user has login “test” and password “12345”. Vile bot has connected dictionary-generated passwords and are ready to work at a speed of 700 passwords per second. It knows that the login user is “test”. Situation breath-taking: the password “12345” will be calculated over very small time. The user, meanwhile, opened the website and started to enter the username and password in a web form login.

    Let’s make changes in the authorization system, while none of them has started its work, and the trouble has not yet happened.

    Magic will be in the third variable to be “glued” to the login-password pair. I called her touch.

    Every time someone gets (attention: gets, not ask!) the login and password, the date “touch” for user “test” is updated to the current date-time:

    login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.

    Suppose that the bot is started the first iteration and was offered the password “1” for login “test” ‘2014-12-13 15:00:00’. Triggered the login_check controller that reads from the database a couple of login and password that no one “touched” as much as 2 seconds! Where do these 2 seconds?! About it further.

    Such a pair of login and password is found. The difference between the last «touch» and the current time – 1 hour. So record successfully returned to our request.

    First login-password pair are matched and login_check concludes that «test / 12345″ is not equal to «test / 1.” The controller returns «auth error». And then the date «touch» for user «test» is updated to the current: “13/12/2014 15:00:00”.

    The bot proceeds to the next iteration: tries the password “2”.

    The speed of a bot is measured by microseconds. It tries to log in immediately: in the ’13/12/2014 15:00:00 “.

    And here comes into play our algorithm – a condition for the parameter «touch» is not already running. 2 seconds have not yet passed. Fail.

    Modified by our logic controller «login_check» cannot get a couple of login and password.

    The record exists, but its date of “touch,” is too “fresh”.

    And it is not part of the sample. And if such pair of login and password is not present, then the controller will respond to the bot “auth error”.

    The bot does not give up, continues to guess, and finally comes to a correct password “12345”.

    The probability that it is current attempt will return success – and is extremely small. 1/700 for each login attempt! That is, if earlier it was 1:1, now 1:700. And the faster bot is, the more likely that it is waiting for fail.

    As a result, only a very small part of the password will be really checked. The rest will get false positives, even if they are correct.

    What about the user?

    Let’s start with the user. The user, in contrast to the bot enters data into a web form by hands across the keyboard and watching the visual organs on the monitor. And the flexibility of its algorithmic abilities much better than the bot. In fact, the user in some way artificial intelligence. So, part of the logic is already in it. And we’re going to use it!

    When the user sees the authorization error, he often rewrites the password again. Even if he just enter the password himself. Even if the password is filled automatically from password manager. I did this even before I applied system of protection of simple passwords.

    Yes, I promised to tell you about two seconds. I am telling:

    Two seconds is the optimum time for which the user carries out operations on data correction and makes the following login attempt. In those two seconds the user completely fits. If the user does not have time – he can always try again and this time the operation touch is probably already canceled.

    In conclusion.

    What happens if the bot will know about a 2-second delay? If we apply our test data, this means that the efficiency of the bot will decrease: only 1 attempt to crack the password instead of 1400.

    P. S. I’d like to hear the criticism because the system is already implemented in one project and have not yet created any ticket with the problem of access to the system.

    Thanks in advance.

    The main disadvantage of this method is the ability to block the bot authorization for the user whose account is trying to crack. In the activity of the bot the user will see the same error log and the author assumes the user is accessing tech support with the question of authorization.

    About the CleanTalk service

    CleanTalk is a cloud service to protect websites from spam bots. CleanTalk uses protection methods that are invisible to the visitors of the website. This allows you to abandon the methods of protection that require the user to prove that he is a human (captcha, question-answer etc.).

    This text is a translation of the article “Как усилить защиту паролей «12345» от brute-force атаки”  published by Дмитрий on habrahabr.ru.

  • Fraud Prevention with CleanTalk

    CleanTalk started to provide its database of IP addresses for banks, payment services, and the companies, evaluating the risk of fraud that strengthens the existing security system of the organization bringing it to a new level.

    Fraud can happen anywhere in the eCommerce world.
    It doesn’t matter if you’re running a small online business or are an owner of a retail chain.

    It’s hard to estimate the true scale of fraud in business, but it’s a serious issue. Fraud isn’t only related to monetary loss, but can also harm your reputation and brand image. Online business owners need to prepare for fraudulent activities so they can detect and prevent them.

    CleanTalk is one of the leaders of the anti-spam protection for websites, has a database of IP addresses involved in spam attacks and in addition to spam, the IP addresses are used by hackers and for other types of attacks, including for fraud.

    Every day CleanTalk receives information about spam attacks from 40-60 thousands of IP addresses. The entire base of spam active IP is about 20 000 000 IP addresses.

    The presence of IP addresses in the blacklist is one of the risk factors, saying that the transaction can be suspicious and it is worth considering carefully. This helps to eliminate the threat of fraud before it gets realized.

    Using database of CleanTalk, you can greatly reduce the risks of online transactions and used as an additional factor in assessing the risks.

    Partnership to reduce the risk of fraud is already appreciated and used by a number of large companies.

    CleanTalk identifies spam bots, using its own algorithms to estimate the parameters of visitors, on the basis of these tests it formed its own database of spam bots. Checking existing comments is made on the basis of the nearly 2 million of certain spam bots. Detailed statistic allows CleanTalk customers to control the whole process.

    “The team CleanTalk has been developing a cloud spam protection system for five years and has created a truly reliable anti-spam service designed for you to guarantee your safety,” For more information visit www.cleantalk.org.