Hi,
I am suffering from bruteforce attack (ssh). I set the fail_delay to 30, but I would need an other defence: WAIT_DELAY: programmable (maybe increasing) delayed time between the question and answer. The limited connections in one time are also important.
It is important because I got lots of indifferent log records about failed attempts.
Thanks in advance
Hi
Change the port from the default on the external interface and use port forwarding on the router, or just change both ports.
I have no router… just a WAN server on serverhosting.
On Sun 29 Nov 2015 07:28:02 PM CST, venember wrote:
I have no router… just a WAN server on serverhosting.
Hi
Ask them to change the port then, or can’t you just change it yourself
with sshd_config, assuming they don’t block any ports…?
There is also fail2ban?
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 | GNOME 3.10.1 | 3.12.48-52.27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Bump - again
Hi
So did you try fail2ban?
It is an official port, everybody uses it. It is my machine. I do not want advices, I need a solution. Do you need any which makes increasing delay during the password evaluating in case of it had failed attempts before?
The firewall and fail2ban works but the logging is not working properly apparently.
And as I said before, multiple bruteforce attacks generate lots of useless log record during the log attempts. It would be the active defense besides the sophisticated fail2ban rules.
If they refuse to change the port, then they should provide an alternate solution. Such security issues are normally to be handled or at least assisted by the hosting provider.
Maybe you could try a firewall rule and whitelist only the known hosts you use?
You can also probably remove logging?
Another trick I have heard of (but never used myself): port knocking.
Not sure how this will work for SSH but CloudlFlare does a great job at security and filtering malicious hosts + is free.
On Mon, 30 Nov 2015 22:16:02 +0000, venember wrote:
> And as I said before, multiple bruteforce attacks generate lots of
> useless log record during the log attempts. It would be the active
> defense besides the sophisticated fail2ban rules.
The “active defense” is to use a non-standard port. Disabling logging
hides the problem.
Using fail2ban or something similar to that also provides you with a
solution. Another option is to use public key authentication only (that
doesn’t stop the brute force attacks, but it does mean that attempts with
a password are guaranteed to fail).
Ultimately, though, the defense is to block the attackers, and fail2ban
is a very effective way of doing that.
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I only ask something. If you can not want to do/help, say simply no. I am not the only user who uses the port.
If somebody makes the thorough port scanning, he will find the ssh (ssh2!) port. The bruteforce is not a playground.
I was using fail2ban with sophisticated homemade-tuned defense system. It was more than enough… till now, when the 13.2->Tumbleweed upgrade forced the journalling and syslog-ng and rsyslog are not worked. I could not check anything. But the error was resolved today morning and the firewall and working (but not logging) fail2ban was enough during this period.
Besides I would say that I do not want to use polkit and any other commercial widespread defense, also auditing. Unfortunately erasing the polkit wipes out almost the whole desktop system.
I would like to hamper and punish the “bruteforcer”, my question was simply this. Waiting is killing.
On Wed, 02 Dec 2015 09:06:01 +0000, venember wrote:
> 1. I only ask something. If you can not want to do/help, say simply no.
I am trying to help, and thank you, but the staff will police threads
around here - there’s no need for you to do that.
You don’t seem to understand that people are trying to help you, but
you want a cut-and-dried solution provided to you, and we don’t have
enough information to give you one.
That means those trying to help you need to ask questions, and are going
to provide solutions based on our current understanding of your need and
your environment.
> I am not the only user who uses the port.
That was not clear before.
> If somebody makes the thorough port scanning, he will find the ssh
> (ssh2!) port. The bruteforce is not a playground.
Generally, brute force attacks are not preceded by a port scan. Yes, if
you change the port, it can still be found, but for the bulk of brute
force attacks against SSH, in my experience, changing the port is one
effective tool to use.
Now, I’ve only been working with Linux since the late 90’s and with
computer networks since the 80’s, so it might be that I don’t know what
I’m talking about. I’m pretty sure I do know, though, and my experience
has borne that out.
> 2. I was using fail2ban with sophisticated homemade-tuned defense
> system. It was more than enough… till now, when the 13.2->Tumbleweed
> upgrade forced the journalling and syslog-ng and rsyslog are not worked.
> I could not check anything. But the error was resolved today morning and
> the firewall and working (but not logging) fail2ban was enough during
> this period.
So it sounds like your problem is resolved, then, and the solution that’s
been recommended solves your problem.
> 3. Besides I would say that I do not want to use polkit and any other
> commercial widespread defense, also auditing. Unfortunately erasing the
> polkit wipes out almost the whole desktop system.
This is puzzling to me - “I have a need, but I’m going to exclude
potential tools to solve the problem” isn’t a good approach to solving
problems. You wouldn’t want to fix a car engine without wrenches or a
socket set, would you? If you only tried to fix a car engine using a
hammer, you’re not going to do a good job of fixing the engine.
> I would like to hamper and punish the “bruteforcer”, my question was
> simply this. Waiting is killing.
The way that most effectively does this is to configure whatever’s
between the user and the service (the firewall, the router - which you
don’t have, so it doesn’t apply here) to not report the port as closed,
but simply to not respond to probe requests.
If the port doesn’t respond to the SYN request, then the application
that’s asking will wait until it times out, which can slow down probes.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Thank you for your answer. The problem solved, after starting the combined journal-rsyslog logging I repaired and improved the fail2ban defense and built a higher firewall/hostsdeny…
It is enough. There are only 3 unique attemps/hour now.
On Fri, 04 Dec 2015 12:16:02 +0000, venember wrote:
> Thank you for your answer. The problem solved, after starting the
> combined journal-rsyslog logging I repaired and improved the fail2ban
> defense and built a higher firewall/hostsdeny…
> It is enough. There are only 3 unique attemps/hour now.
>
> 3. Policyíkit and remote server logging does not need for a private,
> standalone desktop server. Mainly tied with the whole desktop system,
> including ModemManager and Networkmanager feature and laptop conform
> features (screen and power control)… I think, a laptop distribution
> would be useful.
Glad you were able to resolve the issue. 
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Some small, late comment…
Are you fully and regularly patching?
Are you exposing more services than just SSH? Some “Come get me” services that attract are database ports, open relays, banners (responses) that specify the service, “Share” resource ports like SMB which shouldn’t be exposed to the Internet.
Are you advertising attractive content? Like User information, healthcare or financial web content
Pen test yourself. There are free and even web-based tests that do simple probes. If you suspect a more sophisticated adversary, use a serious pen test suite.
Just saying…
Start by taking yourself off someone’s radar and stop making yourself an obvious target.
But to do so, you first need to discover <why> you’ve come to someone’s attention.
Be aware also that just because you’ve taken steps to defend against attacks, once you’re on someone’s target list that person will likely come back and probe you again after some time.
You can also do a reverse scan or at least a trace route to determine the location of the attacking machine(s). Be aware again that in some jurisdictions simply doing this might be considered illegal but YMMV. At least get to know where the attacks are coming from… They might identify the actual attacker (More than a decade ago I hilariously identified the hacker brute forcing me by his handle/username) or it might only lead to his botnet, but it’s something.
If you really want to upgrade your security you should consider installing or building a separate proxy firewall. A proxy firewall is different than firewalls like iproute by terminating network connections at the proxy and remaking a separate connection to the resource instead of allowing the Internet client to connect directly to a resource. This allows you to specify a tiny attack surface (minimally limited functionality) running on the proxy which makes it very difficult to compromise while filtering and creating a new connection to the actual resource.
TSU
Hmmm… firstly: If you see that somebody is in trouble in the sea, do not offer swimming lessons to him… save him instead.
Attacker punish is an active defense for me: I want to hamper the attack and slow down periodically.
I can not do full patching because I do not need polkit and other commercial stuffs; I do not want to pass a pilot exam on the standalone freelancer server. Unfortunately the polkit pulls out half of the system… I need a proper defense… not more. I am using several servers and ssh and passworded vnc remote login.
I do not want to contra-attack the attacker, only effectively defend myself. I do not want to make serious test on a remote server, the SuSE is totally enough… 
I am not familiar with the proxy firewall. I will try it if I have enough time. But… never touch the running system! I want a fully working base system firstly. And the nvidia driver does not work, till now… and somebody should have to cut the rope to te polkit… I have no elegant desktop system also.
Using fail2ban IS a good solution, probably the best solution available. I am not sure why you are ignoring solutions, most of which are good. It is not like anyone can make the attackers just stop.
Port knocking works but if this is a shared host, it might be difficult.
See if you can get the firewall to only accept connections on 22 from set IP addresses. It is a little annoying if you connect from various IP’s.
I would forget about moving sshd to a different port, that does nothing. It is security through obscurity and is trivially easy to find where it was moved to.
polkit is not commercial it is an integral part of the policy setting in openSUSE.
reference
http://www.freedesktop.org/wiki/Software/polkit/
Removing polkit may have significant security repercussions 
I think, an user manageable polkit completely unnecessary for a simple private desktop environment or standalone server.
And it results weak security issues if it is tied with any indifferent applications (desktopmanager, modemmanager, networkmanager): it is a big mass.
My first experience that it was resulting weird behavior, overwritten root privileges and non performed system managing commands, including the reboot.
You should not force a fundamental security solution with 0.113 version number…
Any modification (and removal!) of a policy management should be very carefully evaluated.
Policy is fundamentally the collection of settings which enable easy management, and settings are fundamentally related to security. Simply removing <might> not alter your machine at first, because policy typically needs to be <applied> to be effective. If you simply remove policy, the underlying settings may not necessarily change, but there are two consequences…
Often, policy managers might offer a User multiple options to apply different “profiles” or collection of settings. Investigate that before you remove a policy manager. As I described, it’s not the policy manager that might cause issues, it’s the policy being applied and you need to understand why a policy might be misbehaving.
TSU
Why needs a policykit FOR ME? I am a freelancer user. I do not need “profiles” and other setups, I only want to use and defend the machine. If a software has incorrect settings or behavior, check it by the system and send an error message (from the hidden policykit, if you want). I (or the developers/system builders) will investigate the problem.
Simply: I had a working desktop without policykit and I have NO desktop environment with policykit NOW… which is the better? I do not want to search errors till weeks without any help in my own…
And: for my desktop environment do not need networkmanager, modemmanager and other lots of laptop related stuffs… why have to install for me any unnecessary, possibly non totally error free software only for using an unnecessary policykit, tied for each other?
You should have to decide: if it is a system level tool, do not offer it to the users… and if it is the users task, do not estimate that users will pass a pilot exam to manage it…
No one of the op. system launchers want from users to manage an inner system support security-cooperate system. You should build up a usable default with useful understanding error messages and thats all. The LINUX policy (root/users, system/common user, users/groups, services/private tasks and the file system permissions) is totally enough. More policies are not necessary. If you need, make default profiles to the existing ones. And if it is not enough, we manage it separate, especially, during working.
The complex, indivisible systems have non-resolvable errors.