Re: finding a process that bind a spcific port
netstat -tulpn | grep :10001 grep 10001 /etc/services or: fuser 10001/udp This will output PID Then find out process name associated with PID ls -l /proc/PID/exe ---Permission to forward and reprint is given.--- *Don't confuse my personality with my attitude. My personality is who I am. My attitude depends on who you are.* On Wed, Jan 22, 2014 at 12:37 PM, Nico Angenon n...@creaweb.fr wrote: the same...no output Nico -Message d'origine- From: Andika Triwidada Sent: Wednesday, January 22, 2014 1:33 PM To: Nico Angenon Cc: debian security Subject: Re: finding a process that bind a spcific port On Wed, Jan 22, 2014 at 7:20 PM, Nico Angenon n...@creaweb.fr wrote: Hello, i think i’ve been hacked on one of my boxes... I try to find with process bind a specific port : # netstat -anpe |grep udp gives me udp0 0 0.0.0.0:10001 0.0.0.0:* 0 5950269 - but # lsof |grep 10001 doesn’t show me anything lsof -i -n | grep 10001 -- 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/B0AA26B538DD4C15884CB658AD15788D@NicoPC
Re: [SECURITY] [DSA 2720-1] icedove security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Moritz Muehlenhoff wrote: - Debian Security Advisory DSA-2720-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff July 06, 2013 http://www.debian.org/security/faq - Package: icedove An updated and compatible version of enigmail is included with this update. How does this enigmail version affect iceape? Is it system-wide or icedove specific (seeing as how the enigmail package is being removed, I'm guessing the latter)? We recommend that you upgrade your icedove packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org - -- Andy Ruddock - andy.rudd...@rainydayz.org (OpenPGP Key ID 0xB0324245) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJR2zHkAAoJECqtbbewMkJFKxoP/3hn3+BtkxbaQOqbCzw6ud8h Icklk1vbK/DHgvrgC09YVWcAVRNMv6fRNIalLv2DD8h0IQ4XHjCA2N5BFat3EeE0 4cnD3qJ5+GPjgC8Rmvl4tm1VKXHyk7Oz7di3FO9nX7V9qo1aH1NKRZfHaN0R5+a8 hMhB0QMTGOseEcLWg0+HZfhZAEucDNKwkA7tQEpJl1rGJEyU7fTXiYrRaGKBKvEu g7IKewNwuZ+jlkLFqz2ZUPrHT5g5WWK6pMch39RhJmiOpJdrXWr52pMEARZNCrr6 abTmvcjqpUrFJMyqezWD+5/rbUNMuEATDICtAtCoTkpZggiaA+4cpZIb85/f7znc udzp9xnFPso1aom3vRNzqxlmuMI7Zj04jvmcyRDCZYu/mX/28Yzm0XWPBMQoVlZ+ p7ATCK9o5XgFxo24BOjMkdnFhVoYOgENbOiqAmfHW0u4ocKp/CFkK9HTQzRekk5w ypJYI6f4XEy07C9zN2GoeyfVQ0d6OwwzQ26tBnBl2gJHRZvKX44erRzWdhAXTDn+ R4S0JJcxGWkQUrU4m3aNL6KbURZ53QxyudyPQGhYeVZzJY4Yqm8kokHmeY1YmLdb +wK2onbfl/TE+1EBRsyf7Ey5ldb19+K3J064Fajo5spV9/qMSNGZzfqpGBiTfM3G 5wdP6KIOMWDp39gTsup+ =EZrs -END PGP SIGNATURE- -- 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/51db31e4.6030...@rainydayz.org
Re: [SECURITY] [DSA 2360-1] Two month advance notification for upcoming end-of-life for Debian oldstable
ooops its actually Lenny! On 7 December 2011 06:09, Moritz Muehlenhoff j...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2360-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff December 6, 2011 http://www.debian.org/security/faq - - This is an advance notice that security support for Debian GNU/Linux 5.0 (code name lenny) will be terminated in two months. The Debian project released Debian GNU/Linux 6.0 alias squeeze on the 6th of February 2011. Users and distributors have been given a one-year timeframe to upgrade their old installations to the current stable release. Hence, the security support for the old release of 5.0 is going to end on the 6th of February 2012 as previously announced. Previously announced security updates for the old release will continue to be available on security.debian.org. Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7edjgACgkQXm3vHE4uylqzdgCg5LIpBXVlN13c9QbZ/oX0Trrw lOkAoIAhSp72pvAD0dQ1IoTqIq3dW2X/ =jC8t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111206200953.GA9595@pisco.westfalen.local
security advice wanted for home server
I have an embedded device with attached usb hard disk (a Linksys NSLU2) which I have installed debian on, with the aim of using it as a home server over ADSL. (The idea being that it's quiet and consumes very little power, so I'm happy leaving it switched on all the time, which I wouldn't be with a desktop type machine.) I'm thinking of setting it up as a web server at some point, but could do with some basic advice about the security side of things if anyone can help with that. One question is how likely this is to be a problem (and would the fact that it's on an arm chip not intel reduce the likelihood of a successful attack?); also what kind of precautions I should take against being cracked? My network is an ADSL modem/router with built in firewall and port forwarding, behind which I have 2 laptops, one running linux and one running windows xp, plus the NSLU2. What I'm thinking of doing to secure the NSLU2 is: - Check that the only open incoming ports are ones that I need. - run a firewall (shorewall?). (Though is this actually going to make a difference on such a small network where there are only the localnet and internet zones to think about and the router already has a built in firewall? I'm assuming that it's something I should do, but not sure what kind of attacks a firewall on the NSLU2 would really stop, given that only one incoming port (http) is going to be open on my router, and I can make sure that the server doesn't have any incoming ports open except http and ssh) - use aide to check the system files regularly. The way I'm thinking of doing this is to put a bootable debian image (with aide installed) on a flash disk, then every week or so boot my laptop from this with the slug's usb hard drive plugged into the laptop as well, and check the system using aide that way. Then install any updates, then calculate the checksums again and store them on the flash disk (which I would never use for any other purpose). This is putting me off somewhat, as I was doing something similar with another server I had a while back, and it was a fair bit of hassle to keep it up every week. So it would be good to know if this is overkill, or a sensible thing to do? - work through the securing debian manual to see if there's anything else I've missed. andy. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: security advice wanted for home server
Sébastien NOBILI wrote: Le vendredi 27 février 09 à 10:43, andy baxter a écrit : I can make sure that the server doesn't have any incoming ports open except http and ssh) I would use another port than 22 for the SSH. If your machine's ports are being scanned and it appears port 22 is open, then you'll probably have a lot of brute-force attacks to SSH. Is there any reason to do this given that I'm not planning to log in by ssh from outside my local network? The only ports I'm thinking of opening on the router's firewall are http and the port used by bittorrent (I want to run torrentflux on the NSLU2, which is a web based bittorrent client). Personally, I redirected on my router a high port number (1234, for example) to port number 22 of my home server. No more brute-force attacks. Just in case you didn't think about it, restrict SSH access to certain users, in /etc/ssh/sshd_config : PermitRootLogin no AllowUsers your_login I've done PermitRootLogin; thanks for mentioning the other one. I was also trying: ListenAddress 10.0.0.3 But this seemed to prevent even 10.0.0.3 from logging in, after a '/etc/init.d/ssh restart' Would ListenAddress 10.*.*.* (or 10.*) work? Incidentally, at the moment, with only a base system installed, these are the TCP/IP ports that are open: dolphin:/etc/ssh# netstat -atu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 *:ssh *:* LISTEN tcp0 0 dolphin.localnet:ssh10.0.0.3:58300 ESTABLISHED tcp0 0 dolphin.localnet:ssh10.0.0.3:37295 ESTABLISHED dolphin:/etc/ssh# andy -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: security advice wanted for home server
Sorry, forgot to send this to the list. Martin Bartenberger wrote: andy baxter schrieb: Thanks to those who replied about ssh config. Would be good to know more about whether it's worth setting up aide for a small home server like this, and if the way I'm thinking of doing it is OK. My main worry isn't someone reading my files, which aren't desperately secret, it's that I don't want to hassle of having to reinstall after being cracked, and I don't want to become part of someone else's botnet. It depends on you. I'd think that it's enough if you watch the processes running on your server from time to time, check it with rkhunter or something similar and keep an eye on your logs (via logcheck for example). You also can chroot your webserver. For me, using something like aide would be a bit too much for a small personal server. Thanks - I think I'll give aide a miss. Another question - I'm thinking of putting together a cd with some files on it useful for checking the system. Then every so often I can mount the CD on the NSLU2 and check the system knowing that the programs I'm using are reasonably clean (barring kernel/system library modifications etc.). The programs I'm thinking of putting on the disc are: - everything in /bin - rkhunter plus config files. - chkrootkit ditto - top - netstat - less - mc So the question is - does this seem like a worthwhile thing to do, and are there any other programs worth including? andy -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1715-1] New moin packages fix insufficient input sanitising
Thank you Devin, the problem was solved yesterday by other member helps. 2009. 01. 29, csütörtök keltezéssel 07.14-kor Devin Carraway ezt írta: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1715secur...@debian.org http://www.debian.org/security/ Steffen Joeris January 29, 2009 http://www.debian.org/security/faq - Package: moin Vulnerability : insufficient input sanitising Problem type : remote Debian-specific: no CVE ID : CVE-2009-0260 CVE-2009-0312 Debian Bug : 513158 It was discovered that the AttachFile action in moin, a python clone of WikiWiki, is prone to cross-site scripting attacks (CVE-2009-0260). Another cross-site scripting vulnerability was discovered in the antispam feature (CVE-2009-0312). For the stable distribution (etch) these problems have been fixed in version 1.5.3-1.2etch2. For the testing (lenny) distribution these problems have been fixed in version 1.7.1-3+lenny1. For the unstable (sid) distribution these problems have been fixed in version 1.8.1-1.1. We recommend that you upgrade your moin packages. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Debian (stable) - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/m/moin/moin_1.5.3-1.2etch2.diff.gz Size/MD5 checksum:40914 139bcec334ed7fbf1ca2bef3c89a8377 http://security.debian.org/pool/updates/main/m/moin/moin_1.5.3.orig.tar.gz Size/MD5 checksum: 4187091 e95ec46ee8de9527a39793108de22f7d http://security.debian.org/pool/updates/main/m/moin/moin_1.5.3-1.2etch2.dsc Size/MD5 checksum: 671 7b24d6f694511840a0a9da0c9f33f5ad Architecture independent packages: http://security.debian.org/pool/updates/main/m/moin/python-moinmoin_1.5.3-1.2etch2_all.deb Size/MD5 checksum: 914904 ab6158ae7010c3701859ceb26bd61bd2 http://security.debian.org/pool/updates/main/m/moin/moinmoin-common_1.5.3-1.2etch2_all.deb Size/MD5 checksum: 1595112 a46561072eb0ee26ee1a71275c0e64b3 These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-annou...@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJgT3oU5XKDemr/NIRApQ9AJ4tYeY7WMIAUYHjmeryHoEo6HkecgCgmIU9 b7VcvgOvyalRLrZrejSKFQI= =miAO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1710-1] New ganglia-monitor-core packages fix remote code execution
Thank you for information! -- Andy Smith kovacs.end...@upcmail.hu 2009. 01. 25, vasárnap keltezéssel 21.26-kor Steffen Joeris ezt írta: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1710-1 secur...@debian.org http://www.debian.org/security/ Steffen Joeris January 25, 2009 http://www.debian.org/security/faq - Package: ganglia-monitor-core Vulnerability : buffer overflow Problem type : remote Debian-specific: no CVE Id : CVE-2009-0241 Spike Spiegel discovered a stack-based buffer overflow in gmetad, the meta-daemon for the ganglia cluster monitoring toolkit, which could be triggered via a request with long path names and might enable arbitrary code execution. For the stable distribution (etch), this problem has been fixed in version 2.5.7-3.1etch1. For the unstable distribution (sid) this problem has been fixed in version 2.5.7-5. For the testing distribution (lenny), this problem will be fixed soon. We recommend that you upgrade your ganglia-monitor-core packages. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Source archives: http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor-core_2.5.7.orig.tar.gz Size/MD5 checksum: 508535 7b312d76d3f2d0cfe0bafee876337040 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor-core_2.5.7-3.1etch1.diff.gz Size/MD5 checksum: 316476 052c6ae45b1d114616ae8a4d04530cfe http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor-core_2.5.7-3.1etch1.dsc Size/MD5 checksum: 759 cf4c7357786fd423ee1c04a936dfc389 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1-dev_2.5.7-3.1etch1_alpha.deb Size/MD5 checksum: 150882 e0450d50127c267dbb97d3f27b41603a http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/gmetad_2.5.7-3.1etch1_alpha.deb Size/MD5 checksum: 111420 5050aa958bd47ca0202f782989a3f662 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1_2.5.7-3.1etch1_alpha.deb Size/MD5 checksum: 106024 204e913ca281f7698d94c28e0b53fa7d http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor_2.5.7-3.1etch1_alpha.deb Size/MD5 checksum: 168450 5476515111a428a8e13c27437ef9f18c amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/gmetad_2.5.7-3.1etch1_amd64.deb Size/MD5 checksum: 102418 e4f43cb6911e3b8ebcd38dd400698c70 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1-dev_2.5.7-3.1etch1_amd64.deb Size/MD5 checksum: 132094 ea40ef93a55598d06bbebd6ca297371b http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1_2.5.7-3.1etch1_amd64.deb Size/MD5 checksum:98228 c7694aad20a0c47144fcf9ed3a8c7005 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor_2.5.7-3.1etch1_amd64.deb Size/MD5 checksum: 153468 c3b2b87c5ccc506aa5294ca7fe4c5c65 arm architecture (ARM) http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/gmetad_2.5.7-3.1etch1_arm.deb Size/MD5 checksum:92476 58bbe3b2bab165d03c0b4042152b558c http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1_2.5.7-3.1etch1_arm.deb Size/MD5 checksum:88620 7eeb57376971a530a8630a31d428f63f http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1-dev_2.5.7-3.1etch1_arm.deb Size/MD5 checksum: 119844 8b79fdc26c8d936ae851e3eae7782644 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/ganglia-monitor_2.5.7-3.1etch1_arm.deb Size/MD5 checksum: 138300 60bd39e5a8c5591d2c81e450a6b410ad i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/libganglia1_2.5.7-3.1etch1_i386.deb Size/MD5 checksum:93078 93bcce44d781f9b6338e563f335487a5 http://security.debian.org/pool/updates/main/g/ganglia-monitor-core/gmetad_2.5.7-3.1etch1_i386.deb Size/MD5 checksum:95864 364689bae05cead30438b1f58ed39254
security idea - bootable CD to check your system
hello, I am writing to ask what you think of the following idea? Something that I would like to see is a bootable CDROM which can check all the packages on a debian system. My idea is that it would work roughly as follows: - You halt the machine and put in a bootable CD, then reboot. - The machine boots from the CD, which is read-only and known to be good. - It boots into a minimal linux system which will do nothing but the following: - ask you whether you are booting for the first or second time. - Read a floppy or other removable media to find configuration information for the machine being checked. - Read the host machine's hard drive to find a list of all installed packages. - Connect once to the network to retrieve a list of files and their checksums for each of these packages from a debian server. This list could be saved either to a designated partition on the hard drive, or to removable media. - Disconnect from the network. - Reboot itself. - The second time round, don't connect to the network. - instead, check all the binaries (and optionally config files) against the checksums. - generate some kind of easy to read report on screen, or else save it to removable media. Do you think this would work (i.e. be a good check on whether your system has been compromised), and is it worth doing? I'm not sure if I have the skills to take on something like this all by myself, but I would be willing to put some time in to help where I can if anyone else wants to have a go at it. Alternatively, if people don't think it's worth your while developing something like this, where should I start looking to try to put it together myself, and is there anyone at debian who might be able to help me? yours, andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
The difference is that: a) These all run on the live system they are trying to protect, so in principle they can be neutralised at the same time as the system is attacked, the same as any other binary. E.g. like the way attackers modify system programs like 'find' to hide files they have installed. b) Their databases need to be updated every time you update your system, whereas this approach would update itself automatically whenever you downloaded a new package or update. andy. Felix Windt wrote: Tripwire, integrit and aide all perform something similar to what you described. -Original Message- From: andy baxter [mailto:[EMAIL PROTECTED] Sent: Sunday, June 24, 2007 7:23 AM To: debian-security@lists.debian.org Subject: security idea - bootable CD to check your system hello, I am writing to ask what you think of the following idea? Something that I would like to see is a bootable CDROM which can check all the packages on a debian system. My idea is that it would work roughly as follows: - You halt the machine and put in a bootable CD, then reboot. - The machine boots from the CD, which is read-only and known to be good. - It boots into a minimal linux system which will do nothing but the following: - ask you whether you are booting for the first or second time. - Read a floppy or other removable media to find configuration information for the machine being checked. - Read the host machine's hard drive to find a list of all installed packages. - Connect once to the network to retrieve a list of files and their checksums for each of these packages from a debian server. This list could be saved either to a designated partition on the hard drive, or to removable media. - Disconnect from the network. - Reboot itself. - The second time round, don't connect to the network. - instead, check all the binaries (and optionally config files) against the checksums. - generate some kind of easy to read report on screen, or else save it to removable media. Do you think this would work (i.e. be a good check on whether your system has been compromised), and is it worth doing? I'm not sure if I have the skills to take on something like this all by myself, but I would be willing to put some time in to help where I can if anyone else wants to have a go at it. Alternatively, if people don't think it's worth your while developing something like this, where should I start looking to try to put it together myself, and is there anyone at debian who might be able to help me? yours, andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
I've tried using debsums - however it's not really a good check on your system because the program and the data it's using both come from the system you are trying to check, so could be compromised. Also, it seems to miss out many important packages - e.g. here's the standard error output from a recent run of debsums on my server: whale:~# cat debsums.err debsums: no md5sums for at debsums: no md5sums for base-files debsums: no md5sums for bsdutils debsums: no md5sums for console-data debsums: no md5sums for debian-archive-keyring debsums: no md5sums for ed debsums: no md5sums for gnupg debsums: no md5sums for gpgv debsums: no md5sums for hotplug debsums: no md5sums for initscripts debsums: no md5sums for kernel-image-2.4.27-2-586tsc debsums: no md5sums for klogd debsums: no md5sums for libbz2-1.0 debsums: no md5sums for libdb4.2 debsums: no md5sums for libdb4.3 debsums: no md5sums for libdb4.4 debsums: no md5sums for libgdbm3 debsums: no md5sums for liblockfile1 debsums: no md5sums for libncurses5 debsums: no md5sums for libncursesw5 debsums: no md5sums for lynx debsums: no md5sums for mawk debsums: no md5sums for mime-support debsums: no md5sums for modutils debsums: no md5sums for mount debsums: no md5sums for ncurses-base debsums: no md5sums for ncurses-bin debsums: no md5sums for netbase debsums: no md5sums for openbsd-inetd debsums: no md5sums for ssh debsums: no md5sums for sysklogd debsums: no md5sums for sysv-rc debsums: no md5sums for sysvinit debsums: no md5sums for sysvinit-utils debsums: no md5sums for update-inetd debsums: no md5sums for util-linux What do you mean by 'fingerprint updates?' andy. Daniel van Eeden wrote: Andy, Sounds like you're looking for debsums[1]? A CD/DVD is possible but doesn't allow fingerprint updates. I know that certain Sony MemoryStick are equipped with an rw/ro switch. So a cardreader or usb thumbdrive makes it posible to only use 1 medium instead of two and it still has the read-only security. [1] http://packages.debian.org/stable/admin/debsums Cheers, Daniel van Eeden On Sun, 2007-06-24 at 15:23 +0100, andy baxter wrote: hello, I am writing to ask what you think of the following idea? Something that I would like to see is a bootable CDROM which can check all the packages on a debian system. My idea is that it would work roughly as follows: - You halt the machine and put in a bootable CD, then reboot. - The machine boots from the CD, which is read-only and known to be good. - It boots into a minimal linux system which will do nothing but the following: - ask you whether you are booting for the first or second time. - Read a floppy or other removable media to find configuration information for the machine being checked. - Read the host machine's hard drive to find a list of all installed packages. - Connect once to the network to retrieve a list of files and their checksums for each of these packages from a debian server. This list could be saved either to a designated partition on the hard drive, or to removable media. - Disconnect from the network. - Reboot itself. - The second time round, don't connect to the network. - instead, check all the binaries (and optionally config files) against the checksums. - generate some kind of easy to read report on screen, or else save it to removable media. Do you think this would work (i.e. be a good check on whether your system has been compromised), and is it worth doing? I'm not sure if I have the skills to take on something like this all by myself, but I would be willing to put some time in to help where I can if anyone else wants to have a go at it. Alternatively, if people don't think it's worth your while developing something like this, where should I start looking to try to put it together myself, and is there anyone at debian who might be able to help me? yours, andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
Thanks for the encouragement. I've been looking into it a bit more, and I'm not sure that it would be possible for me to build this by myself, as it would need changes to the debian ftp archive to work. I.e. you would need there to be a retrievable list of filenames and checksums for every package in the debian 'pool' archive, which doesn't exist at present. E.g. for every '.deb' file, there would be a '.deb.sums' file in the same directory. So unless someone at debian thinks it's a good enough idea to justify adding this information to the archive, I don't think it's going to happen as I originally thought. Another way to do it is to keep all of the package files that have been used to build the system on the machine's hard disk, check them first using the checksums in 'Packages.gz', and then retrieve the md5sums for the individual files from the locally archived packages. You could avoid the problem of people adding files by also generating a list of all the files in certain directories (/bin, /lib, /usr) which don't match an installed package. This list should hopefully be small and manageable enough that someone could scan through it quickly to see if anything odd has changed. As I said in my first email, I'm not sure if I'm up for trying to do this all by myself, but I'll let you know if I do make a start on it. cheers, andy Bernhard R. Link wrote: * andy baxter [EMAIL PROTECTED] [070624 18:19]: I've tried using debsums - however it's not really a good check on your system because the program and the data it's using both come from the system you are trying to check, so could be compromised. Also, it seems to miss out many important packages - e.g. here's the standard error output from a recent run of debsums on my server: I had someone in the past considered this, too. First of all debsums's main advantage is looking for unintended changes (and its indeed a shame so many of the important packages come without, that makes bad RAM or unreliable controlers a much larger hassle than they needed to be). To make anything security relevant out of them, the CD would need to have checksums of the contents of those files (for the different versions of the packages) and the missing md5sum files on it. But even that would only make sure none of the official files are changed, while it is more easy to cause harm by simply adding stuff. (Even changing can happen by just uninstalling and puting the stuff manually in there). So the whole thing would have to be combined with something like a security focused checker (perhaps similar to cruft). That together with some code to automatically detect the system and use the right partitions at the right place would surely be a nice tool, but if would for sure be an enourmous amount of work before anything halfly usefull comes out of it. So good luck and let me know when it is finished. (Because I doubt anyone else will find the time to do it). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
Jim Popovitch wrote: On Sun, 2007-06-24 at 16:50 +0100, andy baxter wrote: The difference is that: a) These all run on the live system they are trying to protect, Unless you configure them to only write to an offline mount point that is normally ro and only rw through external effort which is in Tripwire's best practices. -Jim P. OK, this would work. The problem for me is that it would involve turning the media r/w and updating the database every time I run apt-get to install security updates, which I do once a week. If I was running a large server farm and I was looking after it full time, this would be OK, but my situation is that I have two machines, both for personal use, and I don't want to have to devote my entire life to looking after the security on them. The machines are a laptop for general use, and a server which I use for testing and demonstrating small web-based projects I do for people on a voluntary basis. They are connected to the internet by ADSL, with only the server set to accept incoming connections. The other night, I had my laptop switched on and a sound file I had never heard before played through the speaker (it said 'hello' in someone else's voice). I'm assuming I've been cracked and it was someone's idea of a joke. I've halted the server in case that was their way in, and I'm planning to reinstall both my machines this week, but also looking for a more long term solution which I could put some time into now and save myself and anyone else who wants to use it a lot of trouble in the future. What I'm looking for is a solution where I can do security updates every week, as my first line of defence, but then have a fallback way of detecting intrusions which I could run maybe every month, which doesn't need too much work to keep on top of it once it's been set up. I can probably find ways of improving my security using existing tools, but it occurred to me that the system I described would be a pretty watertight check on whether a system has been cracked, which is what I'm looking for. andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
Stephan Wehner wrote: I'm wondering why you are looking only at debian packages. Should the integrity check not be designed to tell you about all software on your system? To be honest, I forgot about this. I'm only running unmodified debian packages, but I can see that other people might have systems which use custom compiled software. Then: * Other Linux distributions would also benefit. * You get more feedback / input / contributions. * Your system is checked more thoroughly. I have the impression there are projects already, that would do to the job with some tweaking (tripwire, ..) Maybe, although I can't see how you get round the problem that you need to update the checksum database every time you install new or updated software. andy Plus, you might as well bundle the check with a backup-system, since you are already looking at your system at rest, and no services are running to worry about. Stephan On 6/24/07, andy baxter [EMAIL PROTECTED] wrote: Jim Popovitch wrote: On Sun, 2007-06-24 at 16:50 +0100, andy baxter wrote: The difference is that: a) These all run on the live system they are trying to protect, Unless you configure them to only write to an offline mount point that is normally ro and only rw through external effort which is in Tripwire's best practices. -Jim P. OK, this would work. The problem for me is that it would involve turning the media r/w and updating the database every time I run apt-get to install security updates, which I do once a week. If I was running a large server farm and I was looking after it full time, this would be OK, but my situation is that I have two machines, both for personal use, and I don't want to have to devote my entire life to looking after the security on them. The machines are a laptop for general use, and a server which I use for testing and demonstrating small web-based projects I do for people on a voluntary basis. They are connected to the internet by ADSL, with only the server set to accept incoming connections. The other night, I had my laptop switched on and a sound file I had never heard before played through the speaker (it said 'hello' in someone else's voice). I'm assuming I've been cracked and it was someone's idea of a joke. I've halted the server in case that was their way in, and I'm planning to reinstall both my machines this week, but also looking for a more long term solution which I could put some time into now and save myself and anyone else who wants to use it a lot of trouble in the future. What I'm looking for is a solution where I can do security updates every week, as my first line of defence, but then have a fallback way of detecting intrusions which I could run maybe every month, which doesn't need too much work to keep on top of it once it's been set up. I can probably find ways of improving my security using existing tools, but it occurred to me that the system I described would be a pretty watertight check on whether a system has been cracked, which is what I'm looking for. andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security idea - bootable CD to check your system
Stephan Wehner wrote: I have the impression there are projects already, that would do to the job with some tweaking (tripwire, ..) Maybe, although I can't see how you get round the problem that you need to update the checksum database every time you install new or updated software. Ok, I see your problem: you want some other source, not your system, to hold the values (checksums) that ensure integrity. But you do not mind that it is online (not available when your system is not connected to the Internet) So when you run a security-check, and new software has been added, you might as well define a route to a place to hold the newly-to-be-calculated checksums (CD-ROM/USB stick, outside server where you can post/read, gmail-filesystem, etc). The idea of doing it this way was that you can run a check at any time without having to keep updating the checksum database yourself, because it's automatically updated online whenever a new package comes out. A worthwhile ambition, where I still feel it'll be as hard to make it debian-only as not. Another point is that configuration files play a big part in the security of your system and a debian-only package checksum will not be able to capture the state of locally changed configurations. For example if your fstab says mount this partitiion read-only then you would like to be notified by your check if that has been changed (maliciously). From what you and other people have said, I'm realising that running a secure system isn't as simple as I had thought at first. What I'm thinking of doing is putting this idea to the back of my mind for a while, and meanwhile concentrating on learning how to secure my network better with the existing tools. Hopefully, once I've got some experience with this, then I'll be able to see a bit better how far the process can be automated. Thanks to everyone who has replied for your time. andy baxter. andy Plus, you might as well bundle the check with a backup-system, since you are already looking at your system at rest, and no services are running to worry about. Stephan On 6/24/07, andy baxter [EMAIL PROTECTED] wrote: Jim Popovitch wrote: On Sun, 2007-06-24 at 16:50 +0100, andy baxter wrote: The difference is that: a) These all run on the live system they are trying to protect, Unless you configure them to only write to an offline mount point that is normally ro and only rw through external effort which is in Tripwire's best practices. -Jim P. OK, this would work. The problem for me is that it would involve turning the media r/w and updating the database every time I run apt-get to install security updates, which I do once a week. If I was running a large server farm and I was looking after it full time, this would be OK, but my situation is that I have two machines, both for personal use, and I don't want to have to devote my entire life to looking after the security on them. The machines are a laptop for general use, and a server which I use for testing and demonstrating small web-based projects I do for people on a voluntary basis. They are connected to the internet by ADSL, with only the server set to accept incoming connections. The other night, I had my laptop switched on and a sound file I had never heard before played through the speaker (it said 'hello' in someone else's voice). I'm assuming I've been cracked and it was someone's idea of a joke. I've halted the server in case that was their way in, and I'm planning to reinstall both my machines this week, but also looking for a more long term solution which I could put some time into now and save myself and anyone else who wants to use it a lot of trouble in the future. What I'm looking for is a solution where I can do security updates every week, as my first line of defence, but then have a fallback way of detecting intrusions which I could run maybe every month, which doesn't need too much work to keep on top of it once it's been set up. I can probably find ways of improving my security using existing tools, but it occurred to me that the system I described would be a pretty watertight check on whether a system has been cracked, which is what I'm looking for. andy baxter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hey, dude, it's me ^_^ :P (SpamEnder: BLOCKED C2EB-SE60215-debian-security@lists.debian.org)
In an effort to eliminate unsolicited e-mail, I have installed SpamEnder. Please REPLY to this e-mail, without modifying the subject line, so that I can receive your original message. Upon my approval, future e-mails you send to me will be released automatically. If you do not REPLY to this e-mail, SpamEnder will block all future e-mails from this address and will not give you another opportunity to reply. Copyright 2003, Evolvian, Inc. (http://www.evolvian.com/) -- Excerpt from original message: I don't bite, weah! pass: 74636 attachment: winmail.dat
Re: Hey, dude, it's me ^_^ :P (SpamEnder: BLOCKED C2EB-SE60215-debian-security@lists.debian.org)
In an effort to eliminate unsolicited e-mail, I have installed SpamEnder. Please REPLY to this e-mail, without modifying the subject line, so that I can receive your original message. Upon my approval, future e-mails you send to me will be released automatically. If you do not REPLY to this e-mail, SpamEnder will block all future e-mails from this address and will not give you another opportunity to reply. Copyright 2003, Evolvian, Inc. (http://www.evolvian.com/) -- Excerpt from original message: I don't bite, weah! pass: 74636 attachment: winmail.dat
Re: Debian + Verisign's .com/.net hijack
Dale Amon ([EMAIL PROTECTED]) wrote: What precisely have they done? I'd not heard about their latest idiocy... [I note that I just got html mail from them about a domain renewal... I just delete html mail without reading.] They've put a wildcard DNS entry for .com and .net to resolve to their product called SiteFinder which offers a IE/MSN like Did you mean to type services. So any domain that doesn't exist, or in the PENDING/DELETE states, or has no nameservers associated with it, now resolves. Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian + Verisign's .com/.net hijack
Dale Amon ([EMAIL PROTECTED]) wrote: On Wed, Sep 17, 2003 at 11:57:16AM +0100, Andy Coates wrote: They've put a wildcard DNS entry for .com and .net to resolve to their product called SiteFinder which offers a IE/MSN like Did you mean to type services. So any domain that doesn't exist, or in the PENDING/DELETE states, or has no nameservers associated with it, now resolves. Ah, so what would happen if many thousands of people ran pings and other things against nonexistant names? Pings are being blocked AFAIK, but there are many ports open (mail for example). Best bet is to search the NANOG lists (www.nanog.org), whole lotta information and discussion about it there. Andy.
RE: XP box inside the firewall
If adding a DMZ isn't suitable you should cirtainly block cirtain outgoing ports I recomend blocking every outgoing port except thouse that you need (i.e. http, ssh etc) would also recomend blocking outgoing email from everything except the firewall, that way if the windoze box (or any other) picks up a nasty it will not be able to email by itself to the rest of the world... Andy -Original Message- From: Jeff [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 22:44 To: [EMAIL PROTECTED] Subject: Re: XP box inside the firewall Kristof Goossens, 2003-Jul-30 14:09 +0200: On Wed, Jul 30, 2003 at 02:01:06PM +0200, Kjetil Kjernsmo wrote: Hi all! [snip] The question is really if I could do something in the firewall that would help isolate the XP box somewhat. Closing outgoing ports (input ports are all closed), drop certain types of packages, or something like that? You can set the notebook on a different network. Put the firewall/router on that network with another nic. It's the principle of a dmz... By putting the notebook on another network, and prohibitting access from that network to the internal network, you can keep your internal systems safer... This is a good option. In addition, or even instead of this, educate your parents about your security concerns. Assuming that you trust your parents, education could be the simplest solution. jc -- Jeff CoppockSystems Engineer Diggin' Debian Admin and User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: XP box inside the firewall
If adding a DMZ isn't suitable you should cirtainly block cirtain outgoing ports I recomend blocking every outgoing port except thouse that you need (i.e. http, ssh etc) would also recomend blocking outgoing email from everything except the firewall, that way if the windoze box (or any other) picks up a nasty it will not be able to email by itself to the rest of the world... Andy -Original Message- From: Jeff [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 22:44 To: debian-security@lists.debian.org Subject: Re: XP box inside the firewall Kristof Goossens, 2003-Jul-30 14:09 +0200: On Wed, Jul 30, 2003 at 02:01:06PM +0200, Kjetil Kjernsmo wrote: Hi all! [snip] The question is really if I could do something in the firewall that would help isolate the XP box somewhat. Closing outgoing ports (input ports are all closed), drop certain types of packages, or something like that? You can set the notebook on a different network. Put the firewall/router on that network with another nic. It's the principle of a dmz... By putting the notebook on another network, and prohibitting access from that network to the internal network, you can keep your internal systems safer... This is a good option. In addition, or even instead of this, educate your parents about your security concerns. Assuming that you trust your parents, education could be the simplest solution. jc -- Jeff CoppockSystems Engineer Diggin' Debian Admin and User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-311-1 New kernel packages - Bug is not fixed!
Once you've run that exploit once it sets itself as setuid=root check for that will you? :) if that's the case, recompile reexecute thanks, andy On Monday 09 June 2003 20:25, Helmar wrote: - From the security advisory 311-1: Package: kernel Vulnerability : several Problem-Type : local, remote Debian-specific: no CVE Ids: CVE-2002-0429 CAN-2003-0001 CAN-2003-0127 CAN-2003-0244 CAN-2003-0246 CAN-2003-0247 CAN-2003-0248 CAN-2003-0364 A number of vulnerabilities have been discovered in the Linux kernel. [...] - - CAN-2003-0127: The kernel module loader allows local users to gain root privileges by using ptrace to attach to a child process that is spawned by the kernel [...] - End of excerpt. I just upgraded my kernel image from 2.4.18-k6 to 2.4.18-1-k6 and i cannot confirm that the above bug has been fixed. The simple exploit (i think it has been from bugtraq) is still working fine, giving every local user easily root privileges. Could it be that this has only been fixed in more recent kernel versions or has there been some kind of error? I hope this has been the right list to post on... Helmar++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-311-1 New kernel packages - Bug is not fixed!
Once you've run that exploit once it sets itself as setuid=root check for that will you? :) if that's the case, recompile reexecute thanks, andy On Monday 09 June 2003 20:25, Helmar wrote: - From the security advisory 311-1: Package: kernel Vulnerability : several Problem-Type : local, remote Debian-specific: no CVE Ids: CVE-2002-0429 CAN-2003-0001 CAN-2003-0127 CAN-2003-0244 CAN-2003-0246 CAN-2003-0247 CAN-2003-0248 CAN-2003-0364 A number of vulnerabilities have been discovered in the Linux kernel. [...] - - CAN-2003-0127: The kernel module loader allows local users to gain root privileges by using ptrace to attach to a child process that is spawned by the kernel [...] - End of excerpt. I just upgraded my kernel image from 2.4.18-k6 to 2.4.18-1-k6 and i cannot confirm that the above bug has been fixed. The simple exploit (i think it has been from bugtraq) is still working fine, giving every local user easily root privileges. Could it be that this has only been fixed in more recent kernel versions or has there been some kind of error? I hope this has been the right list to post on... Helmar++
RE: port 113
Hi All, Logs in my firewall shows me incoming connections to port 113 of the firewall!! What it means? Some service you or your computer is connecting to is checking your ident. Disable the identd daemon or comment out the entry in inetd.conf if you do it that way. Usually happens when you IRC, or some FTP sites check. Don't recall a vulnerability for it. Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: port 113
Netbios related probes I think (windows machines). If you don't have any win machines, ignore it. Easiest place for these sort of queries is google - plenty of people ask the same type of questions. Andy. Ok, but if the port is 137 is that a problem? jjj3 Andy Coates writes: Hi All, Logs in my firewall shows me incoming connections to port 113 of the firewall!! What it means? Some service you or your computer is connecting to is checking your ident. Disable the identd daemon or comment out the entry in inetd.conf if you do it that way. Usually happens when you IRC, or some FTP sites check. Don't recall a vulnerability for it. Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: port 113
Hi All, Logs in my firewall shows me incoming connections to port 113 of the firewall!! What it means? Some service you or your computer is connecting to is checking your ident. Disable the identd daemon or comment out the entry in inetd.conf if you do it that way. Usually happens when you IRC, or some FTP sites check. Don't recall a vulnerability for it. Andy.
RE: port 113
Netbios related probes I think (windows machines). If you don't have any win machines, ignore it. Easiest place for these sort of queries is google - plenty of people ask the same type of questions. Andy. Ok, but if the port is 137 is that a problem? jjj3 Andy Coates writes: Hi All, Logs in my firewall shows me incoming connections to port 113 of the firewall!! What it means? Some service you or your computer is connecting to is checking your ident. Disable the identd daemon or comment out the entry in inetd.conf if you do it that way. Usually happens when you IRC, or some FTP sites check. Don't recall a vulnerability for it. Andy.
RE: synchronized pings
El 10 de oct de 2002, a las 09:31 +, P. Ook escribio: Hi all, I've found 'synchronized pings' in my logs from several hosts all around the world. Today they where 11 hosts more or less doing ping to my Debian box at the same time (11 pings in the same second). Sure this is not a DOS attack, almost for my server, but i can't understand why they are pinging me all at the same time, three o more times a day. Any ideas? Searching in the logs I found pings from same of theese hosts a month ago, but in that days they were only 3-5 hosts pinging me at the same time... Thank you very much in advance. -- Fin de mensaje original -- Hi!! These could be what people said smurf attack. Take a look at: If it was a smurf attack, you'd see pings from hosts on the same subnet (since the idea is one echo results in more than one reply). Since they're all different in his logs, this basically rules smurf out. If you check the IPs, they all belong to one company (SPEEDERA) who specialise in content delivery. I'm guessing someone in your network (or even yourself) is viewing some sort of media they distribute, and one of the techniques for finding the closest distribution point to you could be a simple ping test. Akamai do it if I recall, and these people seem very similar. They usually welcome requests to stop testing, since some people do get annoyed. HTH, Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: synchronized pings
El 10 de oct de 2002, a las 09:31 +, P. Ook escribio: Hi all, I've found 'synchronized pings' in my logs from several hosts all around the world. Today they where 11 hosts more or less doing ping to my Debian box at the same time (11 pings in the same second). Sure this is not a DOS attack, almost for my server, but i can't understand why they are pinging me all at the same time, three o more times a day. Any ideas? Searching in the logs I found pings from same of theese hosts a month ago, but in that days they were only 3-5 hosts pinging me at the same time... Thank you very much in advance. -- Fin de mensaje original -- Hi!! These could be what people said smurf attack. Take a look at: If it was a smurf attack, you'd see pings from hosts on the same subnet (since the idea is one echo results in more than one reply). Since they're all different in his logs, this basically rules smurf out. If you check the IPs, they all belong to one company (SPEEDERA) who specialise in content delivery. I'm guessing someone in your network (or even yourself) is viewing some sort of media they distribute, and one of the techniques for finding the closest distribution point to you could be a simple ping test. Akamai do it if I recall, and these people seem very similar. They usually welcome requests to stop testing, since some people do get annoyed. HTH, Andy.
RE: Setting up a mail server
Hello all, [snip] Now I find myself in the position of changing the setup, so that it is a real internet-facing mail server. It will act as the MX for my domain, using exim, and will distribute the mail to people, either still with qpopper or with an IMAP server (haven't decided yet). There are several questions I have at this point: I would like to add user accounts, so that exim and qpopper (or IMAP) accept and deliver mail for them, but not allow these users shell access. Is changing their shell to /bin/false enough, or is there a smarter way (or one that is not quite so manual?) You'd want to go one step further and forget even adding them an account. Qpopper supports PAM modules for other authentication than /etc/passwd, as well as third-party patches for alternate mechanisms. This usually means that all mail on the system is handled by one user, since there is no individual unix accounts actually in use. I don't use qpopper myself (since IIRC it doesn't support IMAP, just POP3). If you're open to alternatives, have a look at Courier MTA (http://www.courier-mta.org/) which supports both POP3 and IMAP via many authentication systems, and it'll also do your SSL. Main reason I use this is for integration with qmailadmin/vpopmail, but even with exim since it uses Maildir format so your mail deliveries won't need any special tweaking. Many of these user accounts will no doubt be sending and receiving email from dial-up accounts, which limits the ability to deny service on a per-IP basis. Suggestions for security, with pointers, please? I already plan on SSL, I'm asking I guess more about open relay issues in this sort of setup. Also, these user accounts will not be dialing into an ISP that I control, but I may wish to allow them to use me as a smarthost - does this seem foolish? I am undecided. Use SMTP AUTH with exim too (no special patches needed). You can configure it to query wherever you decide to authenticate POP3/IMAP from, so you have one password for both reading and sending mail. Anything you think I'm leaving out? I've done a lot of googling and RTFM'ing recently, but I haven't found a really good guide to practical security considerations for a mail host - if someone has a good link it would be appreciated. I'd look at the whole picture - you'll be giving users access to mail, and the ability to relay mail. Both require authentication, so you'd save yourself a lot of hassle if both authenticated against the same passwords/database. There's probably hundreds of combinations to achieve that, but since Courier is probably the most configurable with regards to authentication, and exim is just sexy anyway, I'd say those two are your best bet. Both can be configured to authenticate against a MySQL database (or LDAP), which are relatively easy to setup and plenty of examples on the web on how to do so. You seem to be aiming for a very secure system, so what I've said might not be the *ultimate* secure system, but it is very simple and easily managed - as well as being as safe as you'll probably ever need. HTH, Andy.
Re: red worm amusement
In the depths of that dark day Sat Jul 21, the words of Wichert Akkerman were the beacon: For amusement I checked the web logs for a few debian machines to see if they had some red worm attempts. Seems we've been probed a fair bit: 16 times on www.spi-inc.org, 22 on non-us.debian.org and 18 on www.debian.org. Almost all attempts were made on July 19. Aren't we glad we all run Linux? :) I've got nothing in my web logs, but I've gotten a whole lot of these over the past couple of days: Jul 19 12:00:47 router kernel: IN=eth1 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=64.152.168.173 DST=123.456.789.012 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=47979 DF PROTO=TCP SPT=1707 DPT=80 WINDOW=8760 RES=0x00 SYN URGP=0 Along with the normal crop of connection attempts to ports 111 and 27374. That's life on Roadrunner.
Re: Followup: Syslog
Of all the days, it was on Sat, Apr 14, 2001 at 02:32:20PM -0400 that Jacob Kuntz quoth: from the secret journal of Andy Bastien ([EMAIL PROTECTED]): Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. I have to admit I've never done this myself, but I know people who do. If you have a hub that won't sent packets to the link because the transmit leads don't make a circuit, the leads can be looped back or some hubs will let you disable link detection. Here's a page that discusses how to make a receive-only cable (scroll down to 3.6): http://www.robertgraham.com/pubs/sniffing-faq.html This from a mailing list discussion about some problems that people have had with cutting the transmit wires. Be aware that the guy who starts the thread clipped the wrong wires: http://www.securityportal.com/list-archive/firewall-wizards/1998/Aug/0167.html Of course, you can use a standard cable with a dedicated logging network segment and disable all network services on the logging server except for syslog. Different networks are find that different solutions work the best for them. I also don't want to claim that there is anything wrong with logging to a printer, and some people might want to log to a printer and a remote server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
Of all the days, it was on Sat, Apr 14, 2001 at 02:32:20PM -0400 that Jacob Kuntz quoth: from the secret journal of Andy Bastien ([EMAIL PROTECTED]): Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. I have to admit I've never done this myself, but I know people who do. If you have a hub that won't sent packets to the link because the transmit leads don't make a circuit, the leads can be looped back or some hubs will let you disable link detection. Here's a page that discusses how to make a receive-only cable (scroll down to 3.6): http://www.robertgraham.com/pubs/sniffing-faq.html This from a mailing list discussion about some problems that people have had with cutting the transmit wires. Be aware that the guy who starts the thread clipped the wrong wires: http://www.securityportal.com/list-archive/firewall-wizards/1998/Aug/0167.html Of course, you can use a standard cable with a dedicated logging network segment and disable all network services on the logging server except for syslog. Different networks are find that different solutions work the best for them. I also don't want to claim that there is anything wrong with logging to a printer, and some people might want to log to a printer and a remote server.
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson [EMAIL PROTECTED] hath wrote: | One additional tweak which falls into line with the security setups, that | I think is a good idea is to made the log files in /var/log to be chattr | +a (append only) so logfiles cannot be modified or removed altogether to | cover up tracks. This isn't the the biggest security trick because all it | does is make it if you don't know about chattr then you can't install a | trojan. If you've got root then removing the immutability flags is | trivial, but only if you know how to, or even know they exist. But it has | kept the lower-level admins at a site I work at from modifying the | logfiles, which is against policy. | if you want a real way to do this (more than just obscuring what you've done) go get one of those old dot-matrix printers with fanfold paperfeed and dump your logs to it in addition to the one on drive. Keep it in a secured room. Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location.
[joey@finlandia.infodrom.north.de: [SECURITY] [DSA 027-1] New OpenSSH packages released]
a note to sparc users (and others): the versions of ssh and ssh-askpass-gnome referenced below and to be found at http://security.debian.org/dists/stable/updates/main/binary-sparc/ssh_1.2.3-9.2_sparc.deb http://security.debian.org/dists/stable/updates/main/binary-sparc/ssh-askpass-gnome_1.2.3-9.2_sparc.deb have earlier version numbers than the packages uploaded on Jan 28 (e.g, ssh_1.2.3-9.3_sparc.deb), which fixed the lack of pam support (http://www.debian.org/security/2001/dsa-025 - was there a reason why only some users noticed that problem?). the version numbering seems to have gotten a touch off... looks like the pam support remains present. andy - Forwarded message from Martin Schulze [EMAIL PROTECTED] - Date: Fri, 9 Feb 2001 00:08:58 +0100 From: Martin Schulze [EMAIL PROTECTED] To: Debian Security Announcements debian-security-announce@lists.debian.org Subject: [SECURITY] [DSA 027-1] New OpenSSH packages released Reply-To: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-027-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 8, 2001 - Package: openssh Vulnerability : remote memory overwrite, key exchange problem Type : remote exploit Debian-specific: no This upload fixes: 1. Prior versions of OpenSSH are vulnerable to a remote arbitrary memory overwrite attack which may eventually lead into a root exploit. No exploit program is known yet but expected to come up soon. 2. CORE-SDI has described a problem with regards to RSA key exchange and a Bleichenbacher attack to gather the session key from an ssh session. We recommend you upgrade your openssh package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/openssh_1.2.3-9.2.diff.gz MD5 checksum: b823b3a94de32533cb35c23a9b956c5c http://security.debian.org/dists/stable/updates/main/source/openssh_1.2.3-9.2.dsc MD5 checksum: bae514efd776c6007944677e767c60a0 http://security.debian.org/dists/stable/updates/main/source/openssh_1.2.3.orig.tar.gz MD5 checksum: 6aad0cc9ceca55f138ed1ba4cf660349 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/ssh-askpass-gnome_1.2.3-9.2_i386.deb MD5 checksum: 0283cfa29a7ac7e7857a6e86202d http://security.debian.org/dists/stable/updates/main/binary-i386/ssh_1.2.3-9.2_i386.deb MD5 checksum: e093ef0bc4201860c66edc859f064e71 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/ssh-askpass-gnome_1.2.3-9.2_m68k.deb MD5 checksum: a7f52d223f5755dacc09c20bbaf10d3e http://security.debian.org/dists/stable/updates/main/binary-m68k/ssh_1.2.3-9.2_m68k.deb MD5 checksum: 50cbe82d6f733357350cbedebc6b58a6 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/ssh_1.2.3-9.2_sparc.deb MD5 checksum: c2b2aefe74ba8852f0ac0bb2a3145892 http://security.debian.org/dists/stable/updates/main/binary-sparc/ssh-askpass-gnome_1.2.3-9.2_sparc.deb MD5 checksum: d0de50b38fd8b517aa2b62fd15d5fcd4 Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/ssh-askpass-gnome_1.2.3-9.2_alpha.deb MD5 checksum: 5be857c6395f02bb9b454bfb13621b06 http://security.debian.org/dists/stable/updates/main/binary-alpha/ssh_1.2.3-9.2_alpha.deb MD5 checksum: e55ef711299a60f5ee5df935a5db4931 PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/ssh-askpass-gnome_1.2.3-9.2_powerpc.deb MD5 checksum: 343c30fec20cf21f7075d86eed9f66f5 http://security.debian.org/dists/stable/updates/main/binary-powerpc/ssh_1.2.3-9.2_powerpc.deb MD5 checksum: 12d7876a78d4eb9485b1aec8da28d3f9 ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/ssh-askpass-gnome_1.2.3-9.2_arm.deb MD5 checksum: fc55f1ec0dfba1175f7060235a6d6d09 http://security.debian.org/dists/stable/updates/main/binary-arm/ssh_1.2.3-9.2_arm.deb MD5 checksum: 3e01291dedf24d01e5645734ec2c4cfb Architecture independent: http://security.debian.org/dists/stable/updates/main/binary
Re: Ext2 - ?????????? ??????????
Of all the days, it was on Mon, Jan 29, 2001 at 08:35:57PM + that Tom Breza quoth: Can u write in English pls? or don't write at all Oh, the irony. thanks e2fsck . ... . Although something in a Roman alphabet would at least have a chance with the fish. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ext2 - ?????????? ??????????
Of all the days, it was on Mon, Jan 29, 2001 at 08:35:57PM + that Tom Breza quoth: Can u write in English pls? or don't write at all Oh, the irony. thanks e2fsck Ð¿Ð¾Ð¼Ð¾Ð³Ð°ÐµÑ ÑолÑко на неÑколÑко минÑÑ. ÐонеÑно Ñ Ñакими ÑкÑднÑми даннÑми ÑÑÑдно полÑÑиÑÑ Ð¾ÑÐ²ÐµÑ ... но вÑеÑаки надеÑÑÑ Ñ ÐºÐ¾Ð³Ð¾ Ñо бÑло неÑÑо подобное. Although something in a Roman alphabet would at least have a chance with the fish.
Re: Clear screan question
Of all the days, it was on Sun, Jan 28, 2001 at 09:00:07AM -0600 that wes schreiner quoth: "Sander Smeenk (CistroN Medewerker)" wrote: Quoting wes schreiner ([EMAIL PROTECTED]): Not that I can see, though I'd love to know of a clean way to clear the scroll-back buffer. I agree it's a bit hackish. Can anyone come up with something better? Ehm.. I did this: knopje# echo -e "\033[2J\033[1;1H" issue.new knopje# cat /etc/issue issue.new knopje# mv issue.new /etc/issue And now when i log out from consoles the screen clears and the scrollback buffer is empty.. The \0332J is ANSI for Clear Screen and \033[1;1H is ANSI for place cursor on x1 y1... Works for me... Tried it, but this only clears the immediately visible screen for me, not the scroll-back buffer. I'm using mgetty, are you using mingetty or some other *getty? Maybe that's the difference. If so, then Ethan's vt switching method is better because it doesn't depend on the getty. These ANSI codes do only clear the screen when the user logs out, which was the original question. At some point somebody interpreted it to be about clearing the scrollback buffer, and things have been going off on that tangent ever since. FWIW, I posted these ANSI codes about two days ago and also noted that they don't work at all if you don't have an ANSI terminal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clear screan question
Of all the days, it was on Sun, Jan 28, 2001 at 09:00:07AM -0600 that wes schreiner quoth: Sander Smeenk (CistroN Medewerker) wrote: Quoting wes schreiner ([EMAIL PROTECTED]): Not that I can see, though I'd love to know of a clean way to clear the scroll-back buffer. I agree it's a bit hackish. Can anyone come up with something better? Ehm.. I did this: knopje# echo -e \033[2J\033[1;1H issue.new knopje# cat /etc/issue issue.new knopje# mv issue.new /etc/issue And now when i log out from consoles the screen clears and the scrollback buffer is empty.. The \0332J is ANSI for Clear Screen and \033[1;1H is ANSI for place cursor on x1 y1... Works for me... Tried it, but this only clears the immediately visible screen for me, not the scroll-back buffer. I'm using mgetty, are you using mingetty or some other *getty? Maybe that's the difference. If so, then Ethan's vt switching method is better because it doesn't depend on the getty. These ANSI codes do only clear the screen when the user logs out, which was the original question. At some point somebody interpreted it to be about clearing the scrollback buffer, and things have been going off on that tangent ever since. FWIW, I posted these ANSI codes about two days ago and also noted that they don't work at all if you don't have an ANSI terminal.
Re: Clear screan question
Of all the days, it was on Sun, Jan 28, 2001 at 01:38:10PM -0600 that wes schreiner quoth: Andy Bastien wrote: These ANSI codes do only clear the screen when the user logs out, which was the original question. At some point somebody interpreted it to be about clearing the scrollback buffer, and things have been going off on that tangent ever since. Sorry Andy, but you are the one off on a tangent. Here's the original message from Tom Breza [EMAIL PROTECTED]: I just use fetch and I been editing filie fetchmail, after I finish editing file I log off from by presing CTRL-D but above log prompt I can read what was been done before, is any chance to clear screan complitly when I log off? That when I press SHIFT-PgUp nobody can see anything? See that SHIFT-PgUp? We have always been talking about clearing the console scroll-back buffer. Just clearing the screen is easy, that's You're right, I missed that. why this thread has shown several ways to do that. Clearing the scroll-back buffer is trickier. Either one uses a logout script to fill it with blank space (my suggestion) or the script switches to an unused vt and back (Ethan's suggestion). Got an ANSI code to do that? Well, no. I always disable the scrollback buffer on the console, because the last thing I want people to do is come by and see other users have been up to. In xterms, the scrollback buffer goes away when the terminal window is closed, so it's not a problem.
Re: Clear screan question
Of all the days, it was on Sat, Jan 27, 2001 at 01:53:31AM +0100 that Tim van Erven quoth: On Fri, Jan 26, 2001 at 05:03:49PM -0600, wes schreiner [EMAIL PROTECTED] wrote: Tom Breza wrote: Hi I just use fetch and I been editing filie fetchmail, after I finish editing file I log off from by presing CTRL-D but above log prompt I can read what was been done before, is any chance to clear screan complitly when I log off? That when I press SHIFT-PgUp nobody can see anything? Most shells have a file they will run at logout. For bash this is ~/.bash_logout. In my ~/.bash_logout I have: echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L clear The idea is to have enough Control-L's to clear out the scroll-back buffer and the clear is there so that the next login happens at the top of the screen. Works like a charm. Doesn't seem to work for me. It just prints out the '^L's. I replaced it with: echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" clear which works just fine. Notice that this is also one echo shorter which is sufficient on my potato install and saves a little time. It's still got a hackish feel about it however. Anyone know if there's a cleaner way to do this? If you have an ANSI terminal, you can put an ESC[2J ESC[0;0H in /etc/issue. The color codes also work, BTW. VTxxx terminals probably have a similar screen-clearing code, but I don't know what it is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
file ownership in liblockfile1 1.01 (sparc)
just ran tiger on a fresh debian (2.2) install, and received the following warnings: # Performing check of PATH components... # Only checking user 'root' --WARN-- [path002w] /usr/bin/dotlockfile in root's PATH from default is not owned by root (owned by dovienya). --WARN-- [x] The following files have undefined groups ownership: /usr/doc/liblockfile1/changelog.gz /usr/doc/liblockfile1/copyright /usr/lib/liblockfile.so.1 /usr/lib/liblockfile.so.1.0 /usr/man/man1/dotlockfile.1 /var/lib/dpkg/info/liblockfile1.postinst /var/lib/dpkg/info/liblockfile1.shlibs and sure enough... -rwxr-sr-x1 dovienya mail /usr/bin/dotlockfile -rw-r--r--1 root 500 /usr/doc/liblockfile1/changelog.gz -rw-r--r--1 root 500 /usr/doc/liblockfile1/copyright lrwxrwxrwx1 root root /usr/lib/liblockfile.so.1 - liblockfile.so.1.0 -rw-r--r--1 root 500 /usr/lib/liblockfile.so.1.0 -rw-r--r--1 root 500 /usr/man/man1/dotlockfile.1 -rwxr-xr-x1 root 500 /var/lib/dpkg/info/liblockfile1.postinst -rwxr-xr-x1 root 500 /var/lib/dpkg/info/liblockfile1.shlibs i verified that the same holds true on two other installs, and didn't find any information on this on the net at large... so i thought i'd send an email out debian-security way to get some feedback... thanks! andy
