Re: Long Exim break-in analysis
Anno domini 2010 Izak Burger scripsit: Hi! Nice reports :) > But there is one bit that gets me. It does this: > mkdir -p /usr/include/mysql > echo dropbear >> /usr/include/mysql/mysql.hh1 > It never does anything with that file, and that file does not exist on > a real system, so its almost like its leaving behind its business > card? Might that be a "all your passwords belong to us" file? I've had one cracked ssh(d) once, which wrote all passwords from clent and server connections to /usr/include/ssh.h IIRC. Maybe this on is something similar? Ciao Max -- Gib Dein Bestes. Dann übertriff Dich selbst! -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101222124549.ga25...@outback.rfc2324.org
Re: [SECURITY] [DSA 1714-1] New rt2570 packages fix arbitrary code execution
Anno domini 2009 Chris Lamb scripsit: > Moritz Muehlenhoff wrote: > > > - > > Debian Security Advisory DSA-1714-1 secur...@debian.org > > http://www.debian.org/security/ Moritz Muehlenhoff > > January 28, 2009 http://www.debian.org/security/faq > > - > > > > Package: rt2570 > > Vulnerability : integer overflow > > Problem type : remote > > Debian-specific: no > > CVE Id(s) : CVE-2009-0282 > > > > It was discovered that an integer overflow in the "Probe Request" packet > > parser of the Ralinktech wireless drivers might lead to remote denial of > > service or the execution of arbitrary code. > Not for us. Maybe it would be helpful to drop debian-security from the list of recipients, as there are some of "us" who might be affected by this DSA... Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Root login
Anno domini 2008 François Cerbelle scripsit: > Le Jeu 4 septembre 2008 14:25, PaweÅ Krzywicki a écrit : > > On czwartek, 4 wrzeÅnia 2008, [EMAIL PROTECTED] wrote: > >> i too noticed a similar thing when i installed on my new laptop etch. > >> the solution was as Cerbelle said. Login as a normal user and do sudo ( > >> or you can activate root login from the login menu; but i personally > >> consider it really dangerous!) > > I am wondering why this is dangerous? > > If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like > > this for example why this is dangerous? > Just because you log in "anonymously". In fact, if several people need a > root access, there are two possibilities : > - everybody knows and use the same root account/password, but you will bot > be able to know who made what. You can only see from which IP the "root" > connection was made. > - "root" account is locked, without password. nobody can directly connect > to it. everybody first need to connect with their personal account and > password before executing something as root. Nobody knows another one's > password, there is no common account or password and you can always know > who ran this damn "rm /etc/passwd". sudo sh rm /etc/passwd kill -9 $$ > Furthermore, root is also ALWAYS the first account to be attacked by > script kiddies. If it is locked, you are sure they will not be able to > connect to this account. # grep Root /etc/ssh/sshd_config PermitRootLogin without-password Your point being? (This is *not* ment personaly, you have the luck to wrote the last and most complete mail :)) Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass-updating cached hosts keys afrer ssh security upgrade?
Anno domini 2008 JW scripsit: Hi! > In the past several weeks I have applied the openssh/openssl updates to my > systems - the updates the fix the random-number-generator weakness. > This has turned into an unexpected nightmare: my users have, between them > all, > dozens of cached host keys, and they are nearly unable to work because every > time they turn around they're getting bad-old-cached-key warnings (REMOTE > HOST IDENTIFICATION HAS CHANGED). > I've been trying to go through all the known_hosts files manually and update > them to give my users a break, but it's a tedious nightmare. Adding to the > complexity is that many of the known_hosts files are armored (the hostname/ip > address is not in plain text). > Has anyone come up with a way to read all the cached hosts - all the > ~/.ssh/known_hosts entries on a system (or at least per user) and fix them? > Essentially I need some semi-automated way to fix this since I have many > users's connections to fix still (hundreds if not thousands by the time I do > machines X users X outgoing connections). Others have already pointed to things how to do this. When you have finished the cleaning up, you might be interested in http://rfc2324.org/projects/ssh-keysync Comments welcome. Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not have firewall rules by default?
Am Wednesday, den 23 January hub Florian Weimer folgendes in die Tasten: > * Ondrej Zajicek: > >> You could also have an 'ENABLED' variable like some files in > >> /etc/default have (so that ports wouldn't be opened by default; the > >> user would have to manually enable them for the port to be opened). > > Better way is just not start that daemon. > The daemon might have been installed by a package dependency, more or > less by accident. Debian should have a policy that all daemons bind to > the loopback interface by default, but as long as this is not the case, > I can understand why people put paket filters on hosts as a safety net. This might be a good idea, but on the other hand if you install packages you should have a look what is installed and deactivate it or cut it of the net if you don't want it. IMO this is the task of the user/admin, not the distro. > On the other hand, at this stage, it's very difficult for Debian as a > distribution to choose what firewall scripting framework should be used. > (But I don't think this is worth the effort.) ACK I think this kind of preseeded firewall would be the first thing experienced users would kick away as it most probably would be annoying for them. Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nmap Xmas scans and unrecognized outcoming connections
Am Friday, den 7 December hub Martín Peluso folgendes in die Tasten: Hi! > Two days ago one of my machines started to receive several nmap Xmas > scans from 73.23.32.79. Later, in another machine which is running under > Debian etch, Firestarter showed me four outcoming connections to the > same ip address with destination ports 80, 44285, 41182 and 43275. Those > connections are not used by any client application and they are not > recognized by netstat. In addition, the target ip address (a comcast > range address) don't seem to be giving http access, and it have all of > its ports filtered. > I don't know how to proceed in order to determine what application is > using those connections or what are they used for. They are still active > since two days ago. > Any suggestion? You should check the md5sum of netstat if it's still the one you would expect it to be. The same might be interesting for things like ls, lsof and such. If you have a machine with two NICs you could setup a bridge and place it between the machine in question and its switchport and fireup wireshark to have a look whats going on. Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/var/lib/dpkg/info/$package.md5sums
Hi! While tracking down an incident in our network, I used 'debsums' to check what files have been modified on our still Sarge boxes and on our Etch boxes, too. I noticed that for some essential packages there are no md5sums information in /var/lib/dpkg/info/: debsums: no md5sums for bzip2 debsums: no md5sums for console-data debsums: no md5sums for debian-archive-keyring debsums: no md5sums for gnupg debsums: no md5sums for gpgv debsums: no md5sums for initscripts debsums: no md5sums for iproute debsums: no md5sums for klogd debsums: no md5sums for libbz2-1.0 debsums: no md5sums for module-init-tools debsums: no md5sums for modutils debsums: no md5sums for mount debsums: no md5sums for netbase debsums: no md5sums for openbsd-inetd debsums: no md5sums for sysv-rc debsums: no md5sums for sysvinit debsums: no md5sums for sysvinit-utils debsums: no md5sums for udev debsums: no md5sums for util-linux Simple question: Why are there no md5sums available? Shouldn't they exist in any package? If not, why not? Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
