"POSSIBLE BREAK-IN ATTEMPT!" in /var/log/secure — what does this mean?

Question

I'm needing a bit of help getting started with a code for my Java course (I had to miss this week and am rather helpless without what they learned) and would appreciate any input on what I'm doing. My goal is to create a code that calculates grades based on inputs.

Here's what the final should look like running:

Please enter the number of courses that you would like to calculate the Average Score, the Minimum Score and the Maximum Score: 2

Please enter the name of the course: CSC 201
Please enter a score for CSC 201 or type -1 to indicate that there is no more score for this course:
*input various values here*

The course name: CSC 201
Number of scores: 2
The average score: 80.0
The minimum score: 70
The maximum score: 90

I'm just... Not quite sure where to go. My base code's below, I just have no idea where to go beyond this, or even how to use Math.min and Math.max. Thanks for any help you can offer for ideas on how to go from here!

import java.util.Scanner;

public class GradeCalc {
    public static void main(String[] args) {
        Scanner input = new Scanner(System.in);
        System.out.println("Please enter the number of courses that you would like to ");
        System.out.println("calculate the Average Score, the Minimum Score, and the Maximum Score: ");
        int status = input.nextInt();
        
        // I am stuck here...
        // 
        // > Math.min()
        // > Math.max()
    }
}

Solution 1

Unfortunately this in now a very common occurrence. It is an automated attack on SSH which is using 'common' usernames to try and break into your system. The message means exactly what it says, it does not mean that you have been hacked, just that someone tried.

Solution 2

The "POSSIBLE BREAK-IN ATTEMPT" part specifically, is related to the "reverse mapping checking getaddrinfo failed" part. It means the person who was connecting didn't have forward and reverse DNS configured correctly. This is quite common, especially for ISP connections, which is where the "attack" was probably coming from.

Unrelated the the "POSSIBLE BREAK-IN ATTEMPT" message, the person is actually trying to break in using common user names and passwords. Do not use simple passwords for SSH; in fact the best idea to to disable passwords altogether and use SSH keys only.

Solution 3

"What exactly does "POSSIBLE BREAK-IN ATTEMPT" mean?"

This means that the netblock owner did not update the PTR record for a static IP within their range, and said PTR record is outdated, OR an ISP does not setup proper reverse records for its dynamic IP customers. This is very common, even for large ISPs.

You end up getting the msg in your log because someone coming from an IP with improper PTR records (due to one of the reasons above) is trying to use common usernames to try SSH into your server (possibly bruteforce attack, or maybe an honest mistake).

To disable these alerts, you have two choices:

1) If you have a static IP, add your reverse mapping to your /etc/hosts file (see more info here):

10.10.10.10 server.remotehost.com

2) If you have a dynamic IP and really want to make those alerts go away, comment out the "GSSAPIAuthentication yes" in your /etc/ssh/sshd_config file.

Solution 4

You can make your logs easier to read and check by turning off reverse lookp-ups in sshd_config (UseDNS no). This will prevent sshd from logging the "noise" lines containing "POSSIBLE BREAK-IN ATTEMPT" leaving you to concentrate on the slightly more interesting lines containing "Invalid user USER from IPADDRESS".

Solution 5

It's not necessary a successful login, but what it says "posible" and "attempt".

Some bad boy or script kiddie, is sending you crafted traffic with a false origin IP.

You can add origin IP limitations to your SSH keys, and try something like fail2ban.

View more solutions

Comments

[Kulu Limpa]

When you have a function and do not know what it does, look for its javadoc: docs.oracle.com/javase/7/docs/api/java/lang/…

[Mike B]

Thanks. I have iptables set to only allow ssh connectivity from select sources. I also have fail2ban installed and running.

[Mike B]

Thanks Lain. That makes me feel better. I'm really glad I require authorized keys for ssh. =)

[poisonbit]

"reverse mapping checking getaddrinfo for" is more about source IP/hostname crafted. The same crafted traffic is trying bad user names, but bad user names doesn't generate the "POSSIBLE BREAK-IN ATTEMPT" message.

[user9517]

@MikeyB: You may want to look at adding fail2ban to you system. THis can be configured to block the IP addresses of these attackers automatically.

[user9517]

@poisonbit: Your right it means that there is a reverse lookup that then doesn't in turn resolve to an A record but in the round it's all part of the same automated attack.

[Mike B]

@lain Thanks. Good idea. I've been using fail2ban for apache but didn't think it was necessary for SSH since I was only allowing access from a couple source IPs. This is a wake up call. It's best not to be too reliant on specific security measures.

[artfulrobot]

If it's generated by a (valid) connection via an ISP, you can add an entry to your /etc/hosts file to get rid of this reverse mapping error. Obviously you'd only do this if you knew that the error is benign and want to clean up your logs.

[Wilfred Hughes]

Note that 'reverse mapping failed' can simply mean that the user's ISP hasn't configured reverse DNS correctly, which is quite common. See @Gaia 's answer.

[Eddie]

What is the downside to disabling sshd reverse lookups on a server connected to the public Internet? Is there any upside at all to leaving this option enabled?

[SET]

commenting GSSAPIAuthentication does not help in my case (

[user9517]

@WoJ, that's not really a solution but it can reduce the problem.

[WoJ]

@Iain: true, but having experienced that on many servers when such attacks became fashionable years ago I saw a drastic reduction (almost to zero) of this noise in the logs.

[kasperd]

@Eddie I don't think the DNS lookups performed by sshd serves any useful purpose. There are two good reasons to disable the DNS lookups. The DNS lookups can slow down login if the lookups time out. And the "POSSIBLE BREAK-IN ATTEMPT" messages in the log are misleading. All that message really means is that the client has misconfigured DNS.

[gxx]

@kasperd UseDNS is needed, if one needs / wants to use hostnames in the from= directive in authorized_keys files.

[FarO]

"UseDNS no" does not make the messages disappear, it only allows connection disregarding the warning. They are still there.

[TimT]

I disagree @OlafM - "UseDNS no" tells sshd to not perform the reverse mapping check and therefore it will not add any lines containing "POSSIBLE BREAK-IN ATTEMPT" to the system logs. As a side-effect it may also speed up connection attempts from hosts than don't have reverse DNS configured correctly.

[FarO]

@TimT have you tried? I did: superuser.com/questions/1149850/…

[TimT]

Yes @OlafM I did, about 4-5 years ago on Linux. It considerably shortened my logs and stopped logcheck bugging me with worthless email reports.

[FarO]

@TimT maybe my issue (see link) depended on a different branch, including patches for SunSSH compatibility.

[Gert van den Berg]

This is inaccurate, it just means the the reverse DNS does not match the hostname the client sent to identify themselves. It is likely flagged since that might have been a break in attempt for people using .rhosts or .shosts authentication (I've never seen that used). Scans happens, but that is not what this message is about (although any connection can trigger it) (For scans, the failed auth / unknown user messages are better to look for)

[Gert van den Berg]

UseDNS no is probably the better setting to get rid of it (and of slow logins when the server has DNS issues...)

[Gert van den Berg]

The main use of UseDNS is for the (bad idea to use) .rhosts and .shosts authentication (HostbasedAuthentication). (And the From match option in the SSHD config and authorized_keys) (There is a seperate setting HostbasedUsesNameFromPacketOnly though which might be needed to switch of reverse lookups for Hosts based auth as well, worse idea than using Hostsbasedauthentication...)

[x-yuri]

"The message means exactly what it says" is very informative.