Re: Bug#149714: libfam0 Does not depend on fam
On Sat, 2002-08-17 at 19:30, Cedric Ware wrote: > [...] > > change in the description to warn about libfam0 being useless w/o a fam > > daemon somewhere would be a welcome addition :-). > > I would heartfully deinstall libfam0 if KDE did not depend on it. :-) > > Now, I realize that there is a problem between the programs actually > using the fam functionality, which could be broken if no daemon was > running anywhere, and those that don't really need it but can use it > and are therefore linked against the appropriate library. > > It appears not to be a simple packaging problem. Indeed, I'm not even > sure the problem is the packaging system's to solve... But I don't > like running unneeded services on my workstations (and as we just saw, > there are security issues). > > Any suggestions as whether this change should be reverted (possibly > only in stable), or a better way exists to tell dselect to really not > install "Recommends" dependencies? I filed the original bug, because libgnomevfs (and thus nautilus) also depends on libfam0, and in investigating my X session logs filled with FAMOpen errors, I discovered I didn't have fam installed. Obviously, a libfam0 w/o fam is kind of useless for desktop purposes, and not pestering about fam means you can do an "apt-get install gnome" (in unstable or experimental, anyways), and not pull in everything you really need. As for "Recommends" vs. dselect, unstable's dselect pesters you once, and if you don't install it, it just lets it go. Definately a step forward :-). So far as stable goes, I still think that libfam is pointless w/o fam, but I don't use stable, so I have no general opinion about keeping/ditching the dep, just a bare preference. Peace, Jim Cape http://ignore-your.tv/ "No cause, no God, no abstract idea can justify the mass slaughter of innocents." -- Edward Said signature.asc Description: This is a digitally signed message part
Re: cryptoloop confusion [repost]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 holy cow, what was I thinking when I wrote this? I hope the original post was understandable, but here is the corrected version Sorry for the repost folks Cheers Pedro On Wednesday 28 August 2002 00:44, Pedro Diaz Jimenez wrote: > Hi, > > [Probably not related much to your problems, but you might find it > interesting] > > If all you want is file system encryption you can try the loop-AES patch > http://loop-aes.sourceforge.net/ > > I used it for a long time on my laptop and it's been perfectly usable > (stable, fast to some excent, no compilation problems when upgrading kernels, etc..). > It uses the AES cryptosystem, of proven strength . The > compilation/instalation procedure is quite easy, also > > Cheers > Pedro > > On Tuesday 27 August 2002 23:11, Jeff wrote: > > I've decided to learn how to setup an encrypted filesystem using the > > cryptoloop method and I'm having troubles getting my kernal source > > patched correctly. I've read the "Loopback Encrypted Filesystem > > HOWTO", but it's outdated. Here are a number of patches for kernel > > 2.4.18 and I'm confused as to which one(s) to use. > > > > I've patched using patch-int-2.4.18.2.bz2 successfully, but my > > compile fails at the cryptoloop part. > > > > I've tried using the "make patch-kernel ..." to patch with > > cryptoloop-0.0.1-pre1.tar.gz and cryptoapi-0.1.0-rc1.tar.gz, both of > > which failed: > > > > root # cd /usr/src/cryptoloop-0.0.1-pre1 > > root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt > > LOOP=iv > > cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . > > rm -f arch/ > > ln -s /usr/src/linux-2.4.18_crypt/arch . > > rm -f include/ > > ln -s /usr/src/linux-2.4.18_crypt/include . > > make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version > > make[1]: Entering directory `/usr/src/cryptoloop-0.0.1-pre1' > > make[1]: Leaving directory `/usr/src/cryptoloop-0.0.1-pre1' > > cd patches && ./findpatch.pl /usr/src/linux-2.4.18_crypt iv > > patching file linux-2.4.16/drivers/block/loop.c > > patching file linux-2.4.16/include/linux/loop.h > > cp: cannot stat > > `/usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in': No such file > > or directory > > /bin/sh: /usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in: No such > > file or directory > > `cryptoloop.c' -> `/usr/src/linux-2.4.18_crypt/crypto/drivers' > > cp: accessing `/usr/src/linux-2.4.18_crypt/crypto/drivers/Makefile': > > Not a directory > > make: *** [patch-kernel] Error 1 > > > > and... > > > > root # cd /usr/src/cryptoapi-0.1.0-rc1 > > root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt > > LOOP=iv > > cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . > > rm -f arch/ > > ln -s /usr/src/linux-2.4.18_crypt/arch . > > rm -f include/ > > ln -s /usr/src/linux-2.4.18_crypt/include . > > make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version > > make[1]: Entering directory `/usr/src/cryptoapi-0.1.0-rc1' > > make[1]: Leaving directory `/usr/src/cryptoapi-0.1.0-rc1' > > touch check.stamp > > cp -R kernel/crypto /usr/src/linux-2.4.18_crypt > > cp: cannot overwrite non-directory > > `/usr/src/linux-2.4.18_crypt/crypto/drivers' with directory > > `kernel/crypto/drivers' > > make: *** [patch-kernel] Error 1 > > > > I'm googling and looking at all the docs in the patches, but I'm not > > finding clear answers yet. > > > > If someone can shed some light on which patch(es) I need and the order > > I need to apply them, and any other important pieces I'd really > > appreciate it. > > > > thanks, > > jc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9bAp0nu53feEYxlERAhSPAJ9iFr4U3kqb6v0kxXqXkWx32cmJtQCguFy5 gaqnLHehw9wBADz486apFxQ= =Mu5m -END PGP SIGNATURE-
Re: cryptoloop confusion
Hi, [Probably not related much to your problems, but you might find it interesting] If all you want is file system encryption you can try the loop-AES patche http://loop-aes.sourceforge.net/ If used it for a long time on my laptop and it's been perfectly usable (stable, fast to some excent, no problems when upgrading kernels, etc..). It uses de AES cryptosystem, of proven strength . The compilation/instalation procedure is quite easy, also Cheers Pedro On Tuesday 27 August 2002 23:11, Jeff wrote: > I've decided to learn how to setup an encrypted filesystem using the > cryptoloop method and I'm having troubles getting my kernal source > patched correctly. I've read the "Loopback Encrypted Filesystem > HOWTO", but it's outdated. Here are a number of patches for kernel > 2.4.18 and I'm confused as to which one(s) to use. > > I've patched using patch-int-2.4.18.2.bz2 successfully, but my > compile fails at the cryptoloop part. > > I've tried using the "make patch-kernel ..." to patch with > cryptoloop-0.0.1-pre1.tar.gz and cryptoapi-0.1.0-rc1.tar.gz, both of > which failed: > > root # cd /usr/src/cryptoloop-0.0.1-pre1 > root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt > LOOP=iv > cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . > rm -f arch/ > ln -s /usr/src/linux-2.4.18_crypt/arch . > rm -f include/ > ln -s /usr/src/linux-2.4.18_crypt/include . > make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version > make[1]: Entering directory `/usr/src/cryptoloop-0.0.1-pre1' > make[1]: Leaving directory `/usr/src/cryptoloop-0.0.1-pre1' > cd patches && ./findpatch.pl /usr/src/linux-2.4.18_crypt iv > patching file linux-2.4.16/drivers/block/loop.c > patching file linux-2.4.16/include/linux/loop.h > cp: cannot stat > `/usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in': No such file > or directory > /bin/sh: /usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in: No such > file or directory > `cryptoloop.c' -> `/usr/src/linux-2.4.18_crypt/crypto/drivers' > cp: accessing `/usr/src/linux-2.4.18_crypt/crypto/drivers/Makefile': > Not a directory > make: *** [patch-kernel] Error 1 > > and... > > root # cd /usr/src/cryptoapi-0.1.0-rc1 > root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt > LOOP=iv > cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . > rm -f arch/ > ln -s /usr/src/linux-2.4.18_crypt/arch . > rm -f include/ > ln -s /usr/src/linux-2.4.18_crypt/include . > make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version > make[1]: Entering directory `/usr/src/cryptoapi-0.1.0-rc1' > make[1]: Leaving directory `/usr/src/cryptoapi-0.1.0-rc1' > touch check.stamp > cp -R kernel/crypto /usr/src/linux-2.4.18_crypt > cp: cannot overwrite non-directory > `/usr/src/linux-2.4.18_crypt/crypto/drivers' with directory > `kernel/crypto/drivers' > make: *** [patch-kernel] Error 1 > > I'm googling and looking at all the docs in the patches, but I'm not > finding clear answers yet. > > If someone can shed some light on which patch(es) I need and the order > I need to apply them, and any other important pieces I'd really > appreciate it. > > thanks, > jc
cryptoloop confusion
I've decided to learn how to setup an encrypted filesystem using the cryptoloop method and I'm having troubles getting my kernal source patched correctly. I've read the "Loopback Encrypted Filesystem HOWTO", but it's outdated. Here are a number of patches for kernel 2.4.18 and I'm confused as to which one(s) to use. I've patched using patch-int-2.4.18.2.bz2 successfully, but my compile fails at the cryptoloop part. I've tried using the "make patch-kernel ..." to patch with cryptoloop-0.0.1-pre1.tar.gz and cryptoapi-0.1.0-rc1.tar.gz, both of which failed: root # cd /usr/src/cryptoloop-0.0.1-pre1 root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt LOOP=iv cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . rm -f arch/ ln -s /usr/src/linux-2.4.18_crypt/arch . rm -f include/ ln -s /usr/src/linux-2.4.18_crypt/include . make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version make[1]: Entering directory `/usr/src/cryptoloop-0.0.1-pre1' make[1]: Leaving directory `/usr/src/cryptoloop-0.0.1-pre1' cd patches && ./findpatch.pl /usr/src/linux-2.4.18_crypt iv patching file linux-2.4.16/drivers/block/loop.c patching file linux-2.4.16/include/linux/loop.h cp: cannot stat `/usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in': No such file or directory /bin/sh: /usr/src/linux-2.4.18_crypt/crypto/drivers/Config.in: No such file or directory `cryptoloop.c' -> `/usr/src/linux-2.4.18_crypt/crypto/drivers' cp: accessing `/usr/src/linux-2.4.18_crypt/crypto/drivers/Makefile': Not a directory make: *** [patch-kernel] Error 1 and... root # cd /usr/src/cryptoapi-0.1.0-rc1 root # make patch-kernel KDIR=/usr/src/linux-2.4.18_crypt LOOP=iv cp -pf /usr/src/linux-2.4.18_crypt/Rules.make . rm -f arch/ ln -s /usr/src/linux-2.4.18_crypt/arch . rm -f include/ ln -s /usr/src/linux-2.4.18_crypt/include . make -f Makefile.modules KDIR=/usr/src/linux-2.4.18_crypt version make[1]: Entering directory `/usr/src/cryptoapi-0.1.0-rc1' make[1]: Leaving directory `/usr/src/cryptoapi-0.1.0-rc1' touch check.stamp cp -R kernel/crypto /usr/src/linux-2.4.18_crypt cp: cannot overwrite non-directory `/usr/src/linux-2.4.18_crypt/crypto/drivers' with directory `kernel/crypto/drivers' make: *** [patch-kernel] Error 1 I'm googling and looking at all the docs in the patches, but I'm not finding clear answers yet. If someone can shed some light on which patch(es) I need and the order I need to apply them, and any other important pieces I'd really appreciate it. thanks, jc -- Jeff CoppockSystems Engineer Diggin' Debian Admin and User
RE: Mail relay attempts
Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. :) Thing -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 August 2002 4:10 To: [EMAIL PROTECTED] Debian. Org Subject: Re: Mail relay attempts * Quoting Craig Sanders ([EMAIL PROTECTED]): > > PS: actually, the only other thing you could do is set firewall rules > blocking inbound tcp port 25. if your mail server is the primary MX for > your domain then you would also need a secondary MX and open the > firewall for just that machine. spammers will still try - the only real > difference is that you'll get entries in your kernel log rather than in > your mail log. if you do this, i recommend using iptables and DROP the > packet rather than REJECT itthis wastes the spammer's time while the > connection times out. Drop doesn't really prevent scans and spammers will scan for open ports first. If you really want to achive something like that, you should install a 'Teergrube': http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: static sshd
On Tue, Aug 27, 2002 at 06:34:44PM +0200, Cristian Ionescu-Idbohrn wrote: > On Tue, 27 Aug 2002, Dale Amon wrote: > > > I'm building a static sshd and am having a bit of > > hassle figuring out which configure options are needed > > for debian compatibility. > > , > | Since glibc does not support 'int optreset;' functionality > | implemented in most BSDes. We have to include our own. As a result > | a clash occurs on staticly compiling. > | > | To hack around to support -static on most platforms lacking optreset > | is too ugly to implement IMNSHO (and I think others agreed by lack > | of implementing it). > ` > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101486444231547&w=2 > > But things might have changed since 2002-02-28 01:59:52 ;-) And here's me thinking I'd just spend an hour yesterday morning to tick off a "minor" job from my todo list :-( > Dale. If you do manage to do that (dispite my discurraging info), > would you be so kind and share? Certainly.
Re: static sshd
On Tue, 27 Aug 2002, Dale Amon wrote: > I'm building a static sshd and am having a bit of > hassle figuring out which configure options are needed > for debian compatibility. , | Since glibc does not support 'int optreset;' functionality | implemented in most BSDes. We have to include our own. As a result | a clash occurs on staticly compiling. | | To hack around to support -static on most platforms lacking optreset | is too ugly to implement IMNSHO (and I think others agreed by lack | of implementing it). ` http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101486444231547&w=2 But things might have changed since 2002-02-28 01:59:52 ;-) Dale. If you do manage to do that (dispite my discurraging info), would you be so kind and share? Cheers, Cristian
Re: Mail relay attempts
* Quoting Craig Sanders ([EMAIL PROTECTED]): > > PS: actually, the only other thing you could do is set firewall rules > blocking inbound tcp port 25. if your mail server is the primary MX for > your domain then you would also need a secondary MX and open the > firewall for just that machine. spammers will still try - the only real > difference is that you'll get entries in your kernel log rather than in > your mail log. if you do this, i recommend using iptables and DROP the > packet rather than REJECT itthis wastes the spammer's time while the > connection times out. Drop doesn't really prevent scans and spammers will scan for open ports first. If you really want to achive something like that, you should install a 'Teergrube': http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html - Rolf
Re: Mail relay attempts
* Craig Sanders <[EMAIL PROTECTED]> [020827 17:07]: > On Tue, Aug 27, 2002 at 06:12:51AM -0500, Daniel J. Rychlik wrote: > PS: actually, the only other thing you could do is set firewall rules > blocking inbound tcp port 25. if your mail server is the primary MX for > your domain then you would also need a secondary MX and open the > firewall for just that machine. spammers will still try - the only real > difference is that you'll get entries in your kernel log rather than in > your mail log. if you do this, i recommend using iptables and DROP the > packet rather than REJECT itthis wastes the spammer's time while the > connection times out. As long as it is not so much traffic that the returned packets cost money, I think a REJECT is much nicer. I do not think timeout due to DROP will have noticeable impact to the spammer, but will be the hell to anyone trying to investigate why he cannot send you mail. Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin)
Re: Mail relay attempts
On Tue, 27 Aug 2002 at 11:32:53PM +1000, Craig Sanders wrote: > PS: actually, the only other thing you could do is set firewall rules > blocking inbound tcp port 25. if your mail server is the primary MX for > your domain then you would also need a secondary MX and open the > firewall for just that machine. spammers will still try - the only real > difference is that you'll get entries in your kernel log rather than in > your mail log. if you do this, i recommend using iptables and DROP the > packet rather than REJECT itthis wastes the spammer's time while the To briefly add to what you can do you could email the contact responsible for the IP block in the InterNIC Whois DB. SOMETIMES you might get a reply You can also try [EMAIL PROTECTED] -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import XP Source Code: #include #include #include #include #include #include //os_over="Windows 2000" os_ver="Windows XP"
unsubscribe
unsubscribe
Re: static sshd
On Tue, Aug 27, 2002 at 07:27:46AM +0200, Joerg Jaspert wrote: > apt-get source ssh and look into debian/rules to see what the > Maintainer does?! Yes, someone else suggested that. Which was rather easy since those were the base sources I was working with anyway. It at least showed that the option I was fighting with was indeed required... but I still have my base problem which is it still won't build. AFAIK all the needed dev libs are installed. The libpam items seem to be looking for things which should be *in* libpam.a gcc -o sshd sshd.o auth.o auth1.o auth2.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-krb5.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o monitor_mm.o monitor.o -L. -Lopenbsd-compat/ -static -lssh -lopenbsd-compat -lwrap -lpam -ldl -lutil -lz -lnsl -lcrypto /usr/lib/libpam.a(pam_end.o): In function `pam_end': pam_end.o(.text+0x5b): undefined reference to `_pam_drop_env' /usr/lib/libpam.a(pam_start.o): In function `pam_start': pam_start.o(.text+0x231): undefined reference to `_pam_make_env' pam_start.o(.text+0x291): undefined reference to `_pam_drop_env' /usr/lib/libpam.a(pam_env.o): In function `_parse_env_file': pam_env.o(.text+0x492): undefined reference to `pam_putenv' /usr/lib/libpam.a(pam_env.o): In function `_expand_arg': pam_env.o(.text+0xadc): undefined reference to `pam_getenv' /usr/lib/libpam.a(pam_env.o): In function `_define_var': pam_env.o(.text+0xdf7): undefined reference to `pam_putenv' /usr/lib/libpam.a(pam_env.o): In function `_undefine_var': pam_env.o(.text+0xe4f): undefined reference to `pam_putenv' /usr/lib/libpam.a(pam_limits.o): In function `init_limits': pam_limits.o(.text+0x428): undefined reference to `cap_free' pam_limits.o(.text+0x430): undefined reference to `cap_init' /usr/lib/libpam.a(pam_limits.o): In function `process_limit': pam_limits.o(.text+0x932): undefined reference to `cap_from_text' /usr/lib/libpam.a(pam_limits.o): In function `setup_limits': pam_limits.o(.text+0xf91): undefined reference to `cap_set_proc' pam_limits.o(.text+0xfad): undefined reference to `cap_free' /usr/lib/libpam.a(pam_mail.o): In function `_do_mail': pam_mail.o(.text+0xba8): undefined reference to `pam_putenv' pam_mail.o(.text+0xcbb): undefined reference to `pam_putenv' /usr/lib/libpam.a(pam_unix_passwd.o): In function `crypt_md5_wrapper': pam_unix_passwd.o(.text+0x8b): undefined reference to `GoodMD5Init' pam_unix_passwd.o(.text+0xb4): undefined reference to `GoodMD5Update' pam_unix_passwd.o(.text+0xd7): undefined reference to `GoodMD5Update' pam_unix_passwd.o(.text+0xf7): undefined reference to `GoodMD5Update' pam_unix_passwd.o(.text+0x103): undefined reference to `GoodMD5Update' pam_unix_passwd.o(.text+0x113): undefined reference to `GoodMD5Final' pam_unix_passwd.o(.text+0x248): undefined reference to `Goodcrypt_md5' /usr/lib/libpam.a(pam_unix_passwd.o): In function `check_old_password': pam_unix_passwd.o(.text+0x42d): undefined reference to `Goodcrypt_md5' /usr/lib/libpam.a(pam_unix_passwd.o): In function `_do_setpass': pam_unix_passwd.o(.text+0xc92): undefined reference to `xdr_yppasswd' /usr/lib/libpam.a(pam_unix_passwd.o): In function `_pam_unix_approve_pass': pam_unix_passwd.o(.text+0x107e): undefined reference to `obscure_msg' /usr/lib/libpam.a(pam_unix_passwd.o): In function `pam_sm_chauthtok': pam_unix_passwd.o(.text+0x16ce): undefined reference to `bigcrypt' pam_unix_passwd.o(.text+0x173b): undefined reference to `bigcrypt' /usr/lib/libpam.a(support.o): In function `_unix_verify_password': support.o(.text+0xd2e): undefined reference to `Goodcrypt_md5' support.o(.text+0xd5b): undefined reference to `Brokencrypt_md5' support.o(.text+0xd6d): undefined reference to `bigcrypt' collect2: ld returned 1 exit status make: *** [sshd] Error 1 Any suggestions are welcome. Could it be like the "old days" when you sometimes had to include a lib twice because of circular dependencies?
Re: Mail relay attempts
On Tue, Aug 27, 2002 at 06:12:51AM -0500, Daniel J. Rychlik wrote: > This is great, Just great. I run a mail server on dsl service > provided by mabell. I wrote a perl script that mails me some reports > on activities on my server everyday. I wake up this morning and I > have an alarm. > Obviously, non of these were relayed from my server because there are > only 2 private ip addresses that can use my server to relay mail. > But, alas I am bothered by these attempts and I hope that I can snip > this in the bud quick. > > Any suggestions would be of great importance and taken seriously. > Please advise. you have an SMTP server, therefore spammers *will* attempt to relay mail through it. guaranteed. sometimes only a few times per day, sometimes hundreds or thousands of attempts per day. get used to it. fortunately, your server sounds like it is not an open relay - you've done the right thing. there's nothing more you can do. you can't stop them trying. you've already done a good job in preventing them from relaying through you. btw, if your DSL service gives you a dynamic IP address you will end up on various DUL-type RBLs anyway. some mail-server operators do not want to receive mail direct from dynamic IP addresses. it's their server, their choice. craig PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the connection times out. the downside to doing this is that spammers can relay spam to you via your secondary MX, in order to get around any local access rules you have. e.g. if you use a particular RBL service and your secondary MX doesn't, then you may as well not bother using the RBL. IMO, it's not worth having a secondary MX host unless either a) you control your secondary MX or b) your secondary MX has at least as good an anti-spam setup as you do. -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Mail relay attempts
On Tue, Aug 27, 2002 at 04:11:21PM +0300, Mika Bostr?m wrote: > > Karl Breitner wrote: > > >Welcome to the world of SPAMfighting > > Our new server has an official IP since last saturday, and no domain > > name pointing to it yet besides a dyndns-account I abused for testing > > purpose. Within these three days of operation I had several persons > > trying to get access to our (non-public) FTP service as well as some > > probes for the usual IIS-holes that Nimda & Co. like to abuse. How will > > that be if we will be publically online and "known" through our regular > > domains? brrr :) > > Simple. Random IP-address block scans. Having the box live on the 'net > alone guarantees that it will get some random hits. Prepare to see lot more > of them from here-on. > > Script-kiddies, trying to find suitable hosts for their mass exploitation > tools. Worms, eagerly propagating on their own means; And spammers > (spammerbots?) trying to find open relays they could abuse. > > The only thing you can do is to make damn certain your box does not become > part of the problem. I'll add to that: make sure you actually check your logs. I use syslog-ng to bring all essential realtime logging to a hardened server; I also run logcheck for hourly reports; snort for attack detection; tiger for security auditing; fascist iptables firewalling on all externally reachable machines; and of course tripwire for after the fact intrusion detection. It's a jungle out there lad.
Re: Mail relay attempts
> Karl Breitner wrote: > >Welcome to the world of SPAMfighting > Our new server has an official IP since last saturday, and no domain > name pointing to it yet besides a dyndns-account I abused for testing > purpose. Within these three days of operation I had several persons > trying to get access to our (non-public) FTP service as well as some > probes for the usual IIS-holes that Nimda & Co. like to abuse. How will > that be if we will be publically online and "known" through our regular > domains? brrr :) Simple. Random IP-address block scans. Having the box live on the 'net alone guarantees that it will get some random hits. Prepare to see lot more of them from here-on. Script-kiddies, trying to find suitable hosts for their mass exploitation tools. Worms, eagerly propagating on their own means; And spammers (spammerbots?) trying to find open relays they could abuse. The only thing you can do is to make damn certain your box does not become part of the problem. -- Mika Boström +358-40-525-7347 \-/ "The Hell is empty, [EMAIL PROTECTED]www.lut.fi/~bostik Xand all the devils Security freak, and proud of it./-\ are here." -W.S. pgpCM2CJoUgtd.pgp Description: PGP signature
Re: Mail relay attempts
Hi Karl. Karl Breitner wrote: What can I say Daniel, except welcome to the harsh reality of a postmaster. Hmm, as I'm to become a "postmaster" in a few days, too, I would like to learn a bit more about that. Most probably this list is not intended for "chat" like this, so I would be happy to get some hints on where to get more information about that topic (mailing lists, FAQs, and so on). Welcome to the world of SPAMfighting I guess this means a lot of "fun" (well, fun at least if you are pervert ;). Our new server has an official IP since last saturday, and no domain name pointing to it yet besides a dyndns-account I abused for testing purpose. Within these three days of operation I had several persons trying to get access to our (non-public) FTP service as well as some probes for the usual IIS-holes that Nimda & Co. like to abuse. How will that be if we will be publically online and "known" through our regular domains? brrr :) Bye, Mike
Re: Mail relay attempts
Daniel J. Rychlik wrote: This is great, Just great. I run a mail server on dsl service provided by mabell. I wrote a perl script that mails me some reports on activities on my server everyday. I wake up this morning and I have an alarm. Obviously, non of these were relayed from my server because there are only 2 private ip addresses that can use my server to relay mail. But, alas I am bothered by these attempts and I hope that I can snip this in the bud quick. Any suggestions would be of great importance and taken seriously. Please advise. ALERT:MAIL RELAY FAILURES SEEMS TO BE PROBLEMS WITH ABUSERS::: 2002-08-26 19:36:11 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:12 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:14 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] -- SNIP --- Hi, What can I say Daniel, except welcome to the harsh reality of a postmaster. I'm running a small, some 300 users, mail server for our organization. I'm having at least a hundred probes a week checking for open eMail relays, even one korean host trying to relay SPAM. That box is blocked, naturally. There is nothing to do, except complain to the abuse department of the offenders ISP and hope they deal with the user probing or trying to relay SPAM. Complaining to Korean ISP:s is useless, sorry Koreans on the list, no offence but it's true. If your attempt is from mail.sopovico.pt, abuse is according to Spamcop: [EMAIL PROTECTED] A check with http://relays.osirusoft.com/ shows this IP beeing listed as a SPAMMER and a SPAM relay on many lists. Welcome to the world of SPAMfighting Regards /Ksrl Breitner
Mail relay attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is great, Just great. I run a mail server on dsl service provided by mabell. I wrote a perl script that mails me some reports on activities on my server everyday. I wake up this morning and I have an alarm. Obviously, non of these were relayed from my server because there are only 2 private ip addresses that can use my server to relay mail. But, alas I am bothered by these attempts and I hope that I can snip this in the bud quick. Any suggestions would be of great importance and taken seriously. Please advise. ALERT:MAIL RELAY FAILURES SEEMS TO BE PROBLEMS WITH ABUSERS::: 2002-08-26 19:36:11 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:12 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:14 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL PROTECTED]> H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to <[EMAIL PROTECTED]> from <[EMAIL
Re: static sshd (off topic re nuking bin laden)
On Tue, Aug 27, 2002 at 03:00:35AM +0100, Dale Amon wrote: > Nuke bin Laden: Dale Amon, CEO/MD > improve the global Islandone Society > gene pool. www.islandone.org Nuclear explosions generate radioactive fallout (or make the cave they were set off in very radioactive...). Ionizing radiation can damage genes, so setting off nukes is probably detrimental to the gene pool. (you never know when a beneficial mutation will occur...). Besides, doesn't Usama bin Laden have a bunch of kids already? (While we're on the subject: America: putting the USA in Usama bin Laden.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: static sshd
Dale Amon <[EMAIL PROTECTED]> writes: > For one, I've never seen the requirement for /var/empty > pop up before, which makes me think debian has things > built differently than I. apt-get source ssh and look into debian/rules to see what the Maintainer does?! -- begin OjE-ist-scheisse.txt bye, Joerg Encrypted Mail preferred! Registered Linux User #97793 @ http://counter.li.org end
