search for: compromising

Hello! I'd just like to run this by some people who are more familiar with the RSA and DSA algorithms and their use within (Open)SSH. I've been using OpenSSH happily with the assumption that using key-based authentication (RSA or DSA public keys pushed to .ssh/authorized_keys on remote hosts) provides a number of benefits, including an important security-related one -- Logging in to a

There is a cluster of machines which I have an account on which was recently compromised. the machines have thousands of users and the only access is via ssh. via some mechanism (probably a weak password) the attacker was able to compromise a single account and use a local-root exploit to hijack lots of ssh-agents and any unpassword protected keys. they next tried to repeat the process for every

I have not, I'll look into that one, thanks! On 11/14/2019 9:48 AM, SternData wrote: > Do you run rkhunter? > > On 11/14/19 9:40 AM, Christopher Wensink wrote: >> How do you know when a Linux system has been compromised?? >> >> Every day I watch our systems with all the typical tools, ps, top, who, >> I watch firewall / IPS logs, I have logwatch setup and

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote: > > Otherwise, feel free to ask me anything. > > Was it ever considered that the feature itself could be problematic, > security-wise? Of course we considered this. > I see at least two candidates: > - It's IMO generally a bad idea to distribute

Hello @ all The libvirt-daemon compromises the packet-filtering-rules at daemon-startup, before any VM is started. To prevent this, I first have create a hook-script which deletes existing rules, but apparently these rules are set after the hook. Removing the defined networks was no solution either. Worst of all is, a service restart of the daemon may even completely neutralize the firewall.

My wife's office server was compromised today. It appears they ssh'ed in through account pcguest which was set up for Samba. (I don't remember setting up that account, but maybe I did.) At any rate, I found a bazillion "ftp_scanner" processes running. A killall finished them off quickly, I nuked the pcguest account, and switched ssh to a different port (which I normally do

Hi list, I do not known, if this is really an issue but i noticed that when connecting to a remote ssh host with the standard linux openssh client using a private key, that there is no line of text indicating when the local key-passwd process was completed and the connection session was established. On a compromised host, the login shell could write the line 'Enter passphrase for key

On Thu, Feb 5, 2015 at 4:39 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > >> >> Yes, /etc/shadow would have always been readable only by root by >> default. The interesting question here is whether an intruder did >> it, clumsily leaving evidence behind, or whether it is just a local >> change from following some bad advice about things that

On 12/13/2015 12:45 PM, Valeri Galtsev wrote: > On Sun, December 13, 2015 11:36 am, Alice Wonder wrote: >> >> >> On 12/13/2015 08:39 AM, Timothy Murphy wrote: >>> Alice Wonder wrote: >>>> One of the benefits of systemd is the dependency based parallel > startup. >>>> The same speed can often be achieved with system V init by fine tuning >

On 2019-11-14 10:01, Christopher Wensink wrote: > I have not, I'll look into that one, thanks! > > On 11/14/2019 9:48 AM, SternData wrote: >> Do you run rkhunter? >> >> On 11/14/19 9:40 AM, Christopher Wensink wrote: >>> How do you know when a Linux system has been compromised? I'm sure you have followed the procedure how to install system and

PIZZACODE SECURITY ALERT program: rssh risk: low[*] problem: string format vulnerability in log.c details: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that. Additioanlly, running rsync, rdist, and cvs are

We had an incident recently where an openssh client and server were replaced with trojanned versions (it has SKYNET ASCII-art in the binary, if anyone's seen it. Anyone seen the source code ?). The trojan ssh & sshd both logged host/user/password, and probably had a login backdoor. Someone asked me what was their exposure if they used public/private keys instead of passwords. My

No, we haven't been hacked. ;) We have a prospective client who is asking us what our policy is in the event of unauthorized access. Obviously you fix the system(s) that have been compromised, but what steps do you take to mitigate the effects of a breach? What is industry best practice? So far, searches haven't produced anything that looks consistent, except maybe identity monitoring

Yeah but if you are uncertain about your own box my VERY STRONG advise is that you reinstall. IF your host is indeed owned, then you are a lot further away then just reinstalling, god knows what issues can arrise when a cracker exploits the system to do bogus tasks.. Then i say: Too bad for your time, sorry but it's like that -- Kind regards, Remko Lodder Elvandar.org/DSINet.org

Sorry for the cross post, but this is an important one potentially affecting all recipients. This just crossed the Full Disclosure mailman moderated mailing list. It bears a careful read, and thought about whether a response is needed. The implication is that if there is any use of a mailman password in common with a password you 'care' about, you need to take appropriate action at

that only works when you are presuming that the host was not hacked already because i would clear those logs when i hacked a system :) but indeed it's a try, If you remain unsure, it is best to reinstall the system to be sure that a fresh and newly updated (yeah update it when installed :)) system is not compromised at that time.. loads of work, but it gives you some relief to know that

On Thu, Feb 5, 2015 at 4:19 PM, Keith Keller <kkeller at wombat.san-francisco.ca.us> wrote: >> On C5 the default appears to be:- >> >> -rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow > > It is much more likely that someone has screwed up your system. I think > even CentOS 4 had shadow as 400. And what on earth would the point be > in having a

I am not sure if I had a compromise but I am not sure I wanted some other input. I noticed in this in my daily security run output: pc1 setuid diffs: 19c19 < 365635 -rwsr-xr-x 1 root wheel 204232 Sep 27 21:23:19 2003 /usr/X11R6/bin/xscreensaver --- > 365781 -rwsr-xr-x 1 root wheel 205320 Dec 4 07:55:59 2003 /usr/X11R6/bin/xscreensaver It was the only file listed and I didn't

I have a server that has been compromised. I'm running version 4.6.2 when I do >last this line comes up in the list. shutdown ~ Thu Aug 28 05:22 That was the time the server went down. There seemed to be some configuration changes. Some of the files seemed to revert back to default versions (httpd.conf, resolv.conf) Does anyone have a clue what type of

1] not using secure http for log-ins seems a bit 20th century. 2] to join this mailing list, I needed to send my new credentials over unsecured http - see 1] above. 3] to change password from the compromised reset password, I need to use unsecured http - see 1] above. My point here is that if you are saddened, upset or concerned about the compromise, might the 3 above points also be on the list