#ssh

utzer@social.yl.ms

Reply to an #abuse message I received of a #Tor exit that was used for #SSH bruteforce. Looks good, right?

Hello,
Thanks for your notifications! If needed and wanted I can restrict the access to .... networks, please let me know if .... wants this and which network resources I should block exit to!

Please also understand that this is an Tor Exit server and that SSH bruteforce is a common problem with other anonymizing services as well, but SSH bruteforce has to be mitigated at the destination host in such a way that SSH service is secured or login requests are blocked after a certain number of attempts.

Please find our general information below.

These machines are Tor exit nodes. Tor is an anonymization network and exit nodes proxy traffic for other hosts on the Internet. By design, it is impossible for us to identify those other hosts or communicate with their operators.

The traffic you see comes from within the Tor network and is not an indicator for an infection or software running on the Tor node itself.

We have the ability to disable proxying to specific IP address ranges (not AS numbers) and specific TCP ports, but this should be considered a last resort tactic. It does not prevent anyone from using Tor to send spam to a certain server or access a certain server or whatsoever; the traffic would just divert to another exit node. Access as described by you can not be prevented by such measures and there is no infection we could clean up.

We are happy to work with you to minimize the impact on your service or on your network or to install a filter that blocks access for all Tor Exit Nodes (e.g. using
https://www.torproject.org/projects/tordnsel.html.en).

I hope you will consider allowing our relay/node to remain in (unfiltered) operation, as it is extremely valuable for people who need to conceal their identities online, especially in countries where access to the Internet is restricted. For more information please see https://www.torproject.org/about/overview.html#overview

We do not run an email server on this machine, nor could emails be relayed via out server.

Also feel free to contact us directly via abuse (at) artikel5ev dot de.

Kind regards,

utzer
on behalf of Artikel5 e.V.

anonymiss@despora.de

How to set up the #RaspberryPi Zero for #travel

source: https://opensource.com/article/20/3/raspberry-pi-zero

So, here's what you can get with a #Pi Zero portable computer:

  • It's small enough to fit in hand baggage or your #pocket.
  • It's cheap enough at $8 to buy another if yours gets lost/stolen/damaged.
  • The entire OS and data are held on a "disk" that is as small as a fingernail, is cheap, and is easily bought in a wide variety of retail outlets. If need be, you can create a new one from a borrowed card from a phone.
  • A full development environment with the ability to work offline or online. It can also act as an #SSH server so that more than one person can use it at once.
  • Safe storage: If you are paranoid or traveling on certain airlines, you can remove the "disk" and store it in your wallet or on your person. If your computer is stolen in transit, go and buy another one off the shelf: you're already set up with the #OS.
  • Network-tolerant: Around the world, there are country-specific #WiFi frequencies, and a simple text-file change enables you to be compliant within minutes.
  • Keyboard independent: You can use a compliant #Bluetooth keyboard, but when you need to do something more demanding, you can just plug any USB #keyboard into the spare #USB connector using an On-The-Go cable.
  • Power supply tolerant: My 3300mAh power bank can run the Pi Zero for about eight hours, but if all else fails, you can use a TV's USB connector to power it. Generally speaking, if a TV has #HDMI, it will also have a USB socket, and the Zero only draws about 120mA. Or use someone's phone charger!
  • Finally, if you're unfortunate enough to lose/damage your "disk," you can easily create another by downloading your 2GB #image from a secure location in the cloud and burning it to a new card. Try doing that with a normal #laptop.

#technology #software #hardware #knowhow #knowledge #linux #news #openSource

canoodle@nerdpol.ch

GNU Linux - debugging problems ssh - Connection closed by authenticating user

if the user get's this error message: (recommended to run this one-liner on server AND client while debugging ssh connection problems) lsb_release -d; # tested on (server and client) Description: Debian GNU/Linux 11 (bullseye) less /var/log/auth.log May 23 14:37:03 SshServer sshd[2233]: Connection[...]

#linux #gnu #gnulinux #opensource #administration #sysops #gnu-linux #ssh #sshd

Originally posted at: https://dwaves.de/2022/01/12/gnu-linux-debugging-problems-ssh-connection-closed-by-authenticating-user/

utzer@social.yl.ms

#Webtropia hat vor 2 Tage einen #Server der #Piratenpartei #NRW abgeschaltet wegen angeblicher nicht beantworteter #Abuse Tickets. Der Server ist der #Tor #Exit, der seit Jahren immer mal wieder kurzzeitig gesperrt wurde, aber jetzt hat so ein #Schlangenöl Anbieter für #Blacklists (#UCE oder so) wohl das ganze /24 Subnet in dem der Server ist gesperrt, weil em ja irgendwer #SSH #Bruteforce und #Wordpress Logins durchprobiert.

#Blacklists in der Art sind eine Seuche und nutzlos, wenn ihr nen Server schützen wollt, dann müsst ihr als Betreiber den sicher machen und solche Attacken erkennen und dann die Angreifer aussperren. Schlangenöl hilft da nicht, wenn die Attacke ist ja schon vorbei wenn eine IP in der Liste gelandet ist.

#Webtropia gehört zu #myloc und die gehören wiederum seit 2020 zu #WIIT oder so. Sie reagieren jetzt einfach nicht mehr auf #Tickets wie es scheint.

Was nun? Geld nehmen sie, aber Server ist abgeschaltet. #Webtropia #Webtropia

danie10@squeet.me

Use a SSH Config File to Manage SSH Connections to Various Remote Servers (or Pi’s) instead of remembering IP addresses, ports, etc

Bild/FotoBild/Foto
Using SSH profiles can help you in cases where you regularly connect to various servers (especially if you’ve added custom SSH ports to the mix too). No need to remember the IP address and other such details for SSH connection.

So once you’ve configured this config file in ~/.ssh all you need to login is something like ‘ssh webserver’ or ‘ssh omv-server’. It won’t remember passwords, but if you have set up public key access, you won’t need any password to login.

This is on my todo list now as I have two servers and two Raspberry Pi’s that I log into quite regularly, and every time it is a check for the IP address, correct user name, password, etc.

See https://linuxhandbook.com/ssh-config-file/

#technology #security #Linux #SSH #tips
Bild/Foto
#Blog, #linux, #security, #ssh, #technology, #tips

danie10@squeet.me

Trap hackers in your server using Endlessh as a SSH Honeypot and wastes their time

Endlessh is an SSH tarpit that very slowly sends an endless, random SSH banner. It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let the script kiddies get stuck in this tarpit instead of bothering a real server.
See
Bild/Foto

SSH Honeypot in 4 Minutes – Trap Hackers in Your Server
by Wolfgang’s Channel on YouTube

#technology #hacking #security #SSH #Endlessh

Bild/Foto
#Blog, #rss


https://gadgeteer.co.za/trap-hackers-in-your-server-using-endlessh-as-a-ssh-honeypot-and-wastes-their-time/

legeneralmidi@diaspora.psyco.fr

Des chercheurs en sécurité ont découvert CronRAT, un nouveau cheval de Troie d'accès à distance (RAT) furtif conçu pour attaquer les systèmes Linux
Se cachant sous la forme d'une tâche planifiée

Des chercheurs en sécurité ont découvert un nouveau #chevaldeTroie d'accès à distance (RAT) furtif, conçu pour attaquer les systèmes Linux. Baptisé CronRAT, ce malware cible actuellement les boutiques en ligne et permet aux attaquants de voler des données de cartes de crédit en déployant des #skimmers de paiement en ligne sur les serveurs Linux.

Les chercheurs de Sansec avertissent que CronRAT "permet le vol de données Magecart côté serveur en contournant les solutions de sécurité basées sur le navigateur". C'est un phénomène particulièrement préoccupant.

CronRAT est décrit comme "une menace sophistiquée, dotée de techniques furtives inédites", et Sansec affirme que son mode de fonctionnement signifie qu'elle ne sera pas reconnue par les autres sociétés de sécurité avant un certain temps.

L'entreprise explique : "Sansec a découvert que CronRAT était présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays. En raison de son exécution inédite, nous avons dû réécrire une partie de notre algorithme eComscan afin de le détecter. CronRAT n'est actuellement pas détecté par les autres fournisseurs de sécurité".

La société de #sécurité poursuit :

"La principale prouesse de CronRAT est de se cacher dans le sous-système calendrier des serveurs Linux ("cron") un jour inexistant. De cette façon, il n'attire pas l'attention des administrateurs de #serveurs. Et de nombreux produits de sécurité n'analysent pas le système cron de Linux.
CronRAT facilite le contrôle persistant d'un serveur de #commerceélectronique. Sansec a étudié plusieurs cas où la présence de CronRAT a conduit à l'injection de skimmers de paiement (alias Magecart) dans le code côté serveur."

Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février. Au lieu de cela, le véritable code du malware est caché dans les noms des tâches et est construit en utilisant plusieurs couches de compression et de décodage base64.

La véritable charge utile de CronRAT est un "programme #Bash sophistiqué qui se caractérise par l'autodestruction, la modulation du temps et un protocole binaire personnalisé pour communiquer avec un serveur de contrôle étranger".

De plus, la connexion se fait sur #TCP via le port 443 en utilisant une fausse bannière pour le service SSH #Dropbear, ce qui permet également au malware de rester sous le radar.

Après avoir contacté le #serveur C2, le déguisement tombe, envoie et reçoit plusieurs commandes, et obtient une bibliothèque dynamique malveillante. À la fin de ces échanges, les attaquants derrière CronRAT peuvent exécuter n'importe quelle #commande sur le #système compromis.

#CronRAT a été trouvé sur plusieurs magasins à travers le monde, où il a été utilisé pour injecter sur le serveur des scripts qui volent les données des #cartesdePaiement - les attaques dites #Magecart.

#Sansec décrit le nouveau #malware comme "une menace sérieuse pour les serveurs de commerce électronique #Linux", en raison de ses capacités :

  • Exécution sans fichier
  • Modulation du temps
  • Sommes de contrôle anti-tampering
  • Contrôle via un protocole binaire et obscurci
  • Lancement d'un #RAT en tandem dans un sous-système Linux distinct.
  • Serveur de contrôle déguisé en service "Dropbear #SSH". -Charge utile cachée dans les noms de tâches programmées #CRON légitimes.

Toutes ces caractéristiques rendent CronRAT pratiquement indétectable. Sur le service d'analyse #VirusTotal, 12 moteurs #antivirus ont été incapables de traiter le fichier malveillant et 58 d'entre eux ne l'ont pas détecté comme une menace.

Source : Sansec

#virus #troyen #cybersécurité #piratage #hacking

utzer@social.yl.ms

I have a #question about #fail2ban, #YunoHost and #SSH, of course running on a #Linux host.

I get this diagnosis mail daily (or more frequent) with failed login attempts via SSH (see message below), I think it is not unusual to have many failed login attempts, I checked fail2ban is running. On other servers I get one failed login per second, I don't run fail2ban on these (as I don't give a fuck, hackers can just switch through #tor circuits to get not banned).

So I also run some #Tor exit and the SSH login attempt with wrong user/password is the most common abuse complaints I get there. (Note: Please do not send out abuse complaints for this or filter out Tor Exits, there is blacklists that contain all Exits. It is just your ticket system talking to my ticket system offering to block access to your servers IP, which would not help to solve your problem anyway)

So what do I do about the failed logins, why is Yunohosts threshold so low that it complains about that?

Should I switch to a not standard port? Login by SSH is only allowed key based, so guessing the password would not work.

What do I do?

Message:

[WARNING] There's been a suspiciously high number of authentication failures recently. You may want to make sure that fail2ban is running and is correctly configured, or use a custom port for SSH as explained in https://yunohost.org/security.

utzer@social.yl.ms

Every now and then I find myself in the position that I need to transfer some files from some servers root account to some other computer (might be mine or another server).

What is the fastest and easiest way to do this?

Assuming I connected from my account "ben" to the remote account "unprivilegeduser" did then "sudo su" or "su root" or whatever and want to transfer the remote file "/root/dump.tar" to my local user "ben" to the folder "/home/ben"?

#Linux #Rsync #ssh #filetransfer #admin

isaackuo@pluspora.com

Help needed - Microsoft Azure Ubuntu VMs have changed ECDSA keys ... Man-in-middle attack or what?

Here's what I get when I try to SSH into either of my two Azure Ubuntu VMs:

kuo@cinderella:~$ ssh isaackuo.cloudapp.net
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:aHrdY1FpW+TlPLIoiDWBzfw9uPm6+p3ci4roNA1EO8A.
Please contact your system administrator.
Add correct host key in /home/kuo/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/kuo/.ssh/known_hosts:85
remove with:
ssh-keygen -f "/home/kuo/.ssh/known_hosts" -R "isaackuo.cloudapp.net"
ECDSA host key for isaackuo.cloudapp.net has changed and you have requested strict checking.
Host key verification failed.

This started happening a few days ago, on both of my Ubuntu VMs (I don't have any other VMs, Ubuntu or otherwise).

Obviously, I'm concerned about a possible man-in-the-middle attack, but I don't know how to assess this possibility or what to do about it.

I am familiar with how to remove entries from known_hosts with ssh-keygen -f, and I have occasionally done so when I have retired and reused a local hostname in my LAN. But this has only been in the very controlled environment of my LAN where I know precisely why the SSH server's key has changed.

In this case, I have taken no actions which would explicitly change the ECDSA host key. Only regular apt-get update+dist-upgrade. Looking it up, I see some people have experienced unexpected change of host key due to a Microsoft Azure update, but I have no idea how to figure out if this has occurred in my case. Whatever happened, it happened to both of my Microsoft Azure Ubuntu VMs at roughly the same time. (I do execute apt-get update+dist-upgrade on both at roughly the same time.)

The functionality of my static web sites on both of them appear unchanged, but I would expect that from a man-in-the-middle attack. However, this does rule out the possibility of some DNS and/or IP address assignment issue simply pointing my domain names to different machines out there.

Any ideas?

Thanks!

#MicrosoftAzure #Azure #Ubuntu #Linux #ssh #security