Thanks SamK. Hopefully you'll find the culprit.

SamK wrote:In my view this topic is a good example of the benefit of having lots of eyes on a problem.

Here is a solution (unfortunately only in German) __{{emoticon}}__

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern"
linktext was:"http://www.thomas-krenn.com/de/wiki/SSH ... _absichern"
====================================

Problem

In the log file

/var/log/auth.log

occur several failed login attempts to the SSH protocol, which do not originate from you.

February 19 09:21:15 servername sshd [22796]: pam_unix (sshd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ssh ruser = rhost 218.207.xx.xx = user = root
February 19 09:21:17 servername sshd [22796]: Failed password for root from 218.207.xx.xx port 22 ssh2

Explanation

The remote user has (accidentally) uses an incorrect server IP and mistakenly tried to log on to your server. The number of login attempts is usually low here.
They are victims of a brute force attack, in which an automatic root login with user and different passwords (for example, from so-called dictionary files) can be tried. The number of login attempts is recognizable high.

Solution

Secure your SSH login with the tool from fail2ban, you prohibit direct root login or sign up only with SSH Key on.
What is Fail2Ban

Fail2Ban is a program written in Python program that can protect various server services against unauthorized access. In the configuration example below, an IP address is blocked for 1 hour, after there have been four of these failed Anmeledeversuche for SSH.
Installation of Fail2Ban

apt-get install fail2ban

Configuration Fail2Ban

Edit the following file:

/etc/fail2ban/jail.conf

Set local IP address of your server, the time how long an IP should be blocked and the number of attempts to be blocked according to which:

ignoreip = 127.0.0.1
bantime = 3600
maxretry = 3

You can adjust the parameters then separately for individual services (such as here in the article, the SSH daemon).

Now define the necessary parameters for the SSH daemon to monitor:

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 4

Then restart fail2ban in order for the changes to take effect.

/etc/init.d/fail2ban restart

Hope you do not mind the help male, Rok. I bypassed the / etc forum bug by using the italics/offset button on the /.
It only works outside of using the code button. In other words. Use code button. The italics/offset button trick does not work. Hope I made sense.

+1 for male's post
I am running fail 2 ban on some of my servers.
It is set up how the article says denying access for a certain amount of time. Then I have an script analyze the fail 2 ban log to permanently lock out a address if the time period is happening 3 times for the same address. There is other precautions as well but those in the article are definitely good steps to do.

Regardless of the lan config being an issue it is obviously one of several issues IMHO.
If we need ssh installed in the iso it should definitely be disabled by default as most people probably do not need to use ssh. Or given another case where there is no lan but the computer is connected straight to the modem (wireless sticks / cellphone tethering as an example)....

@Roky,
excellent!

male wrote:Hope you do not mind the help...

I do not mind at all. Even though I was aware of Fail2Ban your tip is appreciated along with the translation. It is a good fit for server-type-machines that are frequently accessed to provide resources to remote systems.

Dave wrote:If we need ssh installed in the iso it should definitely be disabled by default as most people probably do not need to use ssh.

The following are not arguments in favour of lax security, just some things to think about when considering such a change.

Booting the antiX ISO is predominately for:

• Previewing it to help decide whether it is appealing or not
• Installing it

Within those parameters, it is unlikely that starting an SSH server session will be wanted, so not having a running sshd seems a reasonable choice. Once the distro has been installed (conventionally to a disk) the usage parameters change. It becomes more likely that an SSH server session will be wanted which might be the reason it is a Debian default set up.

Debian is not generally known as being insecure. Notwithstanding that, any system can be made more secure, right up to the point where it is never powered up, although such a state might be deemed slightly inconvenient. The question becomes at what point does a system reach a state which can be reasonably described as adequately secure? Beyond that point additional security measures become increasingly marginal.

The circumstances that prompted the opening post in this topic have been tracked down. Someone here did not revert changes to the LAN firewall, made during an investigation. This left the machine in question vulnerable to attack from outside the firewall. Even so, when rebuilding the system, a weak and easily guessed root password was required before the vulnerability could be exploited. Together, these point towards using better controls and procedures here, but there is the eternal problem of competing demands on time. In short, both conditions had to be present concurrently and neither of them were caused by antiX.

The lack of reports in the antiX forum of systems being compromised via SSH is probably a reasonable indication of how often it happens. In such circumstances, one might ask whether the value of adding a third layer of security to SSH (by disabling it entirely) goes beyond the point of marginal gains mentioned above.

While accepting that antiX is a successful distro in its own right, moving too far from what are expected as Debian defaults might lead to some disappointment. By way of examples, a user wants to allow access to their local system to someone providing remote support, or wants to provide some form of file transfer direct to remote systems. In both cases it is highly likely that a secure and encrypted connection will be wanted. If the SSH server element is present but disabled it might lead to confusion because on-line guides might reasonably assume that it is started during boot-up and therefore be difficult to follow. There probably are other more relevant and obvious examples than those.

Off Topic
This is not related to security but one area where disabling it might be marginally beneficial is in reducing the demand for RAM, however the difference is so small as to be negligible.

If we need ssh installed in the iso it should definitely be disabled by default as most people probably do not need to use ssh.

I heartily agree. Further, if the shipped default configuration permits remote root ssh login (I was stunned to read that's the case)
a bolded, red-bordered, cautionary statement should be displayed in the user docs ~~ along with a quick"howto disable root ssh login" explanation for editing the config file.

IMO,"worrying about inconveniencing users" is a non-issue here.
For me, the issue is that users (me) TRUST that distro maintainers have chose sane defaults.
Wherever a shipped default setting(s) may be problematic ~~ deviates from expected convention, or (as in this case) represents a potential security hazard ~~
distro maintainers have a responsibility to provide adequate documentation in order to achieve informed consent.
Otherwise, they're essentially shipping (naively? intentionally?) a"backdoored" O/S.

=================

When I read Sam's report, I wondered whether any of the pre-installed (from trusted-clean debian sources) applications had been launched.
Too often nowadays, with (misplaced) attention toward"worrying about inconveniencing users", apps are designed
(and/or preconfigured, by the author or package maintainer) to callout/check for updates during first launch (or eternally, during each launch!).
With each of these wget calls, the app is retrieving content from non Debian servers... and many opensource app projects are hosted on shared webservers.
This scenario represents a huge"from Day1" exploitation vector.

Idunno whether any of the apps preinstalled in antiX full are preconfigured to"perform automatic update checks". Some probably are ~~ likely candidates are:
web browser and music player app(s). When I discover (have, repeatedly) that a music player app, for instance, is preconfigured to immediately callout
(without my consent, or even knowledge) to various"app partner" webservers... dammit, that really chaps my hide! Some distros are even shipping (amaroK? player)
preconfigured to churn your drive, indexing your hard-won torrented plunder, then ("for your convenience" cough, cough) callout to CBS -owned last.fm and"retrieve missing cover art".

The Debian default is that ssh is enabled.
The live antiX default comes with ssh disabled (through the cheat codes LMX).
During installation, user is asked to disable some services. Default is to allow ssh (ie to follow the Debian default). User can choose to disable.(Maybe this should be more up front as an option).

antiX is one of the few Debian-based distros with ssh disabled running live and offers the option to enable/disable it on install. (IIRC siduction does the same)

Yep, I guess I am one of the few that disables cups, ssh, and others for default startup during a install.
I have o need for printing or file sharing on my biker shop computers.
I have a Windows Biker tuner laptop that does not go online for printing.

Edit: I recall there was also a cli thingy for disabling startup services also in antixcc.
I opened it a couple of times to just poke around in it.
My new 64gig Kingspec 1.8" zif ssd hard drive just came in the mail.
So i can't elaborate more on this as I am going to play with the spare M&A Companion Netbook.

My old IBM A22M sell off payed for this hard drive as well as for the fix on the Panasonic and a 4 gig tam stick also.

Dolphin explained in his videos some about the services you could disable. I used the docs to learn more, and even made myself a list of what I don't want to use both in antiX and MX-14. I read someplace about setting up a VPN which does great to stop lots of this stuff happening. All I can do is learn. __{{emoticon}}__

anticapitalista wrote:During installation, user is asked to disable some services.

I recall there was also a cli thingy for disabling startup services also in antixcc.

Building on those the following might be helpful to anyone wanting to adjust the antiX services when running in a GUI environment.


During installation the following is automatically displayed

Adjust antiX services during installation

Adjust antiX services during installation

Post installation antiX-menu-->Control Center-->System-->Choose Startup Services, displays

Adjust antiX services post installation

Adjust antiX services post installation

Post installation run a command as root in a terminal to manage SSH

service ssh [start|status|stop]
or
/etc/init.d/ssh [start|status|stop]