Re: removing banners from cyrus
This will take care of both the IMAP and POP3 banners? Nothing needs to be done to say .. imapd.c Thanks again At 11:01 AM 4/2/2002 +0100, Steve Wright wrote: The +OK %s Cyrus POP3 v2.0.15 server ready banner can be changed by editing line 323 in /src/cyrus-imapd-2.0.15/imap/pop3d.c On Tuesday 02 April 2002 10:06, you wrote: What is the procedure for removing the banners from Cyrus? I am sure this involves edition a source file and recompiling I hust haven't seen this documented anywhere. If someone could advise. Thanks Banners Cyrus ??? Cyrus doesnt have banners ? Does it ? Are you sure it is not your MTA which is probably where banners should be removed anyway ?
Re: removing banners from cyrus
I am confused as to what or why there are things specific to Netscape. Perhaps I have left out the context of my question. I am trying to prevent people doing recognizance banner grabbing for security reasons At 04:15 PM 4/2/2002 +0100, Steve Wright wrote: Changing pop3d.c will only change the +OK %s Cyrus POP3 v2.0.15 server ready banner. If you want to change the imap banner, to the best of my knowledge you have to change (in imapd.c) the OK %s Cyrus IMAP4 %s server ready\r\n line (same as pop3d.c), the section containing the imap id (as per RFC2971) prot_printf(imapd_out, * ID ( \name\ \Cyrus\ \version\ \%s\ \vendor\ \Project Cyrus\ \support-url\ \http://asg.web.cmu.edu/cyrus\;, CYRUS_VERSION); there are a few entries specific to netscape. Steve. On Tuesday 02 April 2002 15:39, you wrote: This will take care of both the IMAP and POP3 banners? Nothing needs to be done to say .. imapd.c Thanks again At 11:01 AM 4/2/2002 +0100, Steve Wright wrote: The +OK %s Cyrus POP3 v2.0.15 server ready banner can be changed by editing line 323 in /src/cyrus-imapd-2.0.15/imap/pop3d.c
Re: removing banners from cyrus
Ken I am just interested in suppresing platform/version information when someone telnet to port 143. Just one more layer of security. If I understand you correctly I just need to add: imapidresponse: no to /etc/imapd.conf? This correct. If you think that having the vendor/version information in the banner is a security problem, then you should tell us what you think the security issues are, so they can be fixed. If its a config problem, then fix your config ;-) In any case, there are multiple places in the services where the vendor/version string is used: - In the banners for imapd, pop3d, lmtpd -- disable by editing the source -- look for prot_printf(, ... ready\r\n, ,CYRUS_VERSION) - imapd: ID command response -- disable with imapidresponse: no in imapd.conf - imapd: NETSCAPE command response -- not compiled by default (--enable-netscapehack configure option) - pop3d: IMPLEMENTATION capability -- disable by editing the source in cmd_capa() Ken
Re: removing banners from cyrus
OK using your logic I will deduce that since anything on a network can be hacked into I should not attempt to take any security precautions. Security is applied in layers and the more layers the better. My question was not intended to start a thread regarding security practices as that is not the design of this list. We should drop it. I asked a question and got an answer. At 01:59 PM 4/2/2002 -0600, Jim Levie wrote: On Tue, 2002-04-02 at 13:26, Ken Murchison wrote: Clifford Thurber wrote: Ken I am just interested in suppresing platform/version information when someone telnet to port 143. Just one more layer of security. But by doing this, you're implying that there is a security hole in the Cyrus server which can be exploited if the hacker discovers the vendor/version info. Is there some known security hole in Cyrus that isn't in other servers. Even if there is, I don't think that the lack of info in the banner is going to stop a hacker from trying the exploit anyway. Furthermore, a good hacker intent on finding Cyrus servers could also detect them by look for known response strings from commands, etc. Ah yes, the old security through obscurity game. From what I've seen eliminating the server type and version has no affect on whether a cracker can exploit any weakness that an application has. And that's because the vast majority of attacks aren't done in what one would consider an intelligent manner. The attacker doesn't examine services to figure out if they are vulnerable or not. He/she simply runs a script that attempts to exploit all known vulnerabilities. So hiding the fact that you are running a certain version of Sendmail, or Cyrus, or whatever doesn't generally help. The attack scripts that I've recovered from cracked boxes (that were then used to try to crack other boxes) just had a big list of things to try. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Jim Levie email: [EMAIL PROTECTED] Dynetics Inc, Huntsville, Al Ph.256.964.4337 The opinions expressed above are just that...
removing banners from cyrus
What is the procedure for removing the banners from Cyrus? I am sure this involves edition a source file and recompiling I hust haven't seen this documented anywhere. If someone could advise. Thanks
Re: cyrus 2.0.16 on AIX anyone?
I think there is one other one actually in France somewhere. At 11:29 AM 3/27/2002 -0500, Gautam Das wrote: Hello, is anybody listening? I have not received a single response to my distress call. Are we the only AIX cyrus site in the world or what? On Tue, 26 Mar 2002, Gautam Das wrote: Hi, Is anyone running Cyrus on AIX? We had upgraded from 1.5 to 2.0.16 last weekend, and had to rollback after half a day of operation. The cyrus master process would silently stop doing anything useful after anywhere from 15 minutes to a maximum 2 hours of operation. Unfortunately once it got to that state it would not log anything either. Is 2.0.16 running without problems on Solaris and Linux? I am trying to understand if the problems we are seeing are specific to AIX? The rollback required reconstructing all of the 85000+ mailboxes, which took over 2 days on a 4 CPU SP2 node running AIX 4.3.3. If anyone is running or has attempted to run cyrus version 2 on AIX, irrespective of the size of their user population, I am very eager to hear from them. Thank you and looking forward to find at least someone out there running Cyrus on AIX. -- Gautam Das [EMAIL PROTECTED] Senior Systems Programmer Tel: (352) 392-2061 Northeast Regional Data Center Fax: (352) 392-9440 University of Florida
Re: bug in imapd-2.1.3 / Berkeley DB
You are most likely compiling this on a linux system. This happens because of /usr/include/db.h. This is the header fileshipped witht the distro. Cyrus will compile using your CFLAGS below but the linker will use the db.h file under /usr/include. I think if anything this is a linux bug. It drove me nuts for a few days. I ended up using the db libs that Red Hat ships with. At 09:26 AM 3/26/2002 +0100, Olaf Zaplinski wrote: Hi *, following bug occured: 1. CPPFLAGS=-I/usr/local/BerkeleyDB.3.3/include \ LDFLAGS=-L/usr/local/BerkeleyDB.3.3/lib \ ./configure 2. make 3. make install 4. start of cyrus = 'incorrect version of Berkeley db: compiled against 3.1.17, linked against 3.3.11' So I re-started 3. and voila: gcc -c -I/usr/include/db3 -I/usr/local/BerkeleyDB.3.3/include [...] Although I told configure where to look for db3, it searches on its own and finds the system's db-3.1.17 instead of by self built db-3.3.11. Workaround: vi `find . -name Makefile` :-( (This did not really help because sasl-2.1.1 does not like db-3.3, saslpasswd2 crashes.) Regards Olaf
RE: Connecting to imap using Outlook
But as long as you enable TLS/SSL I don't see why this would matter? Am I missing something here? Thanks At 02:35 PM 3/26/2002 +, T Churchward wrote: correctly the only way I could get Outlook to successfully connect was using plain text passwords . Yeah, I agree, not an ideal solution!
Re: bug in imapd-2.1.3 / Berkeley DB
I set every one of these environmental variables and also added the db5.0 lib to /etc/ld.so.conf and ran ldconfig. None of that matters. It doens't matter as the linker will always look in /usr/include first and grab what is there. The only way is to replace that db.h file. At 04:14 PM 3/26/2002 +0100, Prune wrote: Clifford Thurber wrote: You are most likely compiling this on a linux system. This happens because of /usr/include/db.h. This is the header fileshipped witht the distro. Cyrus will compile using your CFLAGS below but the linker will use the db.h file under /usr/include. I think if anything this is a linux bug. It drove me nuts for a few days. I ended up using the db libs that Red Hat ships with. linux : 1 you : 0 try to set LDFLAGS, CPPFLAGS, CFLAGS, LD_RUN_PATH and LD_LIBRARY_PATH. Il this fail, rm the Linux db.h !! if all fail, install FreeBSD or Solaris. Cheers, prune At 09:26 AM 3/26/2002 +0100, Olaf Zaplinski wrote: Hi *, following bug occured: 1. CPPFLAGS=-I/usr/local/BerkeleyDB.3.3/include \ LDFLAGS=-L/usr/local/BerkeleyDB.3.3/lib \ ./configure 2. make 3. make install 4. start of cyrus = 'incorrect version of Berkeley db: compiled against 3.1.17, linked against 3.3.11' So I re-started 3. and voila: gcc -c -I/usr/include/db3 -I/usr/local/BerkeleyDB.3.3/include [...] Although I told configure where to look for db3, it searches on its own and finds the system's db-3.1.17 instead of by self built db-3.3.11. Workaround: vi `find . -name Makefile` :-( (This did not really help because sasl-2.1.1 does not like db-3.3, saslpasswd2 crashes.) Regards Olaf
RE: bug in imapd-2.1.3 / Berkeley DB
Perhaps all this could be made into a nice Linux how to as the current one seems rather dated and doesn't address any of these problems. At 11:37 AM 3/26/2002 -0500, OCNS Consulting wrote: Clifford: You are correct! The only way I could get Cyrus IMAP 2.1.3 to use the desired BDB 4.x header was to replace the BDB 3.x /usr/include/db.h header with (in my case) a sym link from /usr/localBerkeleyDB.4.0/include/db.h to - /usr/include/db.h. By the way: a similar situation also occurs when configuring Cyrus SASL V2 libraries. The difference is that SASL looks for directory /usr/include/db3. The configure script will always check for this directory and use the header file(s) located there - No Matter What is Specified with Option --with-bdb-incdir; For Instance: --with-bdb-incdir=/usr/local/BerkeleyDB.4.0/include To ensure that the proper BDB 4.x headers are used when configuring SASL V2, I suggest renaming/mv directory /usr/include/db3 to /usr/include/db3.SAV and create a sym link from /usr/local/BerkeleyDB.4.0/include to /usr/include/db3: ln -fs /usr/local/BerkeleyDB.4.0/include /usr/include/db3 This resolves a Segmentation Fault - Death by 11 headache. By the way: you'll need to maintain a version of the BDB 3.x so library i.e. - /lib/libdb-3.3.so or the following messages will be logged in the messages file when master starts the child protocol and services servers: imapd[2866]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open shared object file: No such file or directory imapd[2867]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open shared object file: No such file or directory pop3d[2869]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open shared object file: No such file or directory pop3d[2868]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open shared object file: No such file or directory lmtpd[2870]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open shared object file: No such file or directory I don't know what impact this may or may not have but given the reference to libsasl there appears to be some authentication ramification's). Does anyone know? RB -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Clifford Thurber Sent: Tuesday, March 26, 2002 10:32 AM To: Prune Cc: Olaf Zaplinski; [EMAIL PROTECTED] Subject: Re: bug in imapd-2.1.3 / Berkeley DB I set every one of these environmental variables and also added the db5.0 lib to /etc/ld.so.conf and ran ldconfig. None of that matters. It doens't matter as the linker will always look in /usr/include first and grab what is there. The only way is to replace that db.h file. At 04:14 PM 3/26/2002 +0100, Prune wrote: Clifford Thurber wrote: You are most likely compiling this on a linux system. This happens because of /usr/include/db.h. This is the header fileshipped witht the distro. Cyrus will compile using your CFLAGS below but the linker will use the db.h file under /usr/include. I think if anything this is a linux bug. It drove me nuts for a few days. I ended up using the db libs that Red Hat ships with. linux : 1 you : 0 try to set LDFLAGS, CPPFLAGS, CFLAGS, LD_RUN_PATH and LD_LIBRARY_PATH. Il this fail, rm the Linux db.h !! if all fail, install FreeBSD or Solaris. Cheers, prune At 09:26 AM 3/26/2002 +0100, Olaf Zaplinski wrote: Hi *, following bug occured: 1. CPPFLAGS=-I/usr/local/BerkeleyDB.3.3/include \ LDFLAGS=-L/usr/local/BerkeleyDB.3.3/lib \ ./configure 2. make 3. make install 4. start of cyrus = 'incorrect version of Berkeley db: compiled against 3.1.17, linked against 3.3.11' So I re-started 3. and voila: gcc -c -I/usr/include/db3 -I/usr/local/BerkeleyDB.3.3/include [...] Although I told configure where to look for db3, it searches on its own and finds the system's db-3.1.17 instead of by self built db-3.3.11. Workaround: vi `find . -name Makefile` :-( (This did not really help because sasl-2.1.1 does not like db-3.3, saslpasswd2 crashes.) Regards Olaf
linker wierdness
Hello I having some strange linking problems. I am trying to build Cyrus 2.1.2 IIMAP server using BerkeleyDB 4.0 and SASL 2.1.2 on a RedHat 7.1 box. I installed BerkeleyDB and SASL without problem by doing the following. Set up links: ln -s /usr/local/BerkeleyDB.4.0/libdb4.a /usr/lib/lib/libdb4.a ln -s /usr/local/BerkeleyDB.4.0/libdb4.la /usr/lib/lib/libdb4.la ln -s /usr/local/BerkeleyDB.4.0/libdb4.so /usr/lib/lib/libdb4.so added /usr/local/BerkeleyDB4.0/lib to /etc/ld.so.conf rand ldconfig set the LD_RUN_PATH=/usr/local/BerkeleyDB.4.0 ran the following: CPPFLAGS=-I/usr/local/BerkeleyDB.4.0/include LDFLAGS=-L/usr/local/BerkeleyDB.4.0/lib ./configure --disable-krb4 --disable- sieve --libdir=/usr/local/BerkeleyDB.4.0 --with-dbdir=/usr/local/BerkeleyDB.4.0/ During the final phase of make I see the linker do the following: gcc -L/usr/local/BerkeleyDB.4.0//lib -Wl,-rpath,/usr/local/BerkeleyDB.4.0//lib - L/usr/local/BerkeleyDB.4.0//lib -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/us r/local/BerkeleyDB.4.0/lib -Wall -g -O2 -o imapd \ ../master/service.o pushstats.o imapd.o index.o tls.o version.o libimap.a ../ac ap/libacap.a ../lib/libcyrus.a -L/usr/lib/sasl/lib -Wl,-rpath,/usr/lib/sasl/li b -lsasl2 -lrt -ldl -lssl -lcrypto -ldb-3.1 -lresolv ../et/libcom_err.a -lw rap -lnsl Now when I fired up /usr/cyrus/bin/master and tail the imapd.log file I see: Mar 20 23:23:23 birdbrain master[25255]: process 25257 exited, status 75 Mar 20 23:23:23 birdbrain tls_prune[25259]: incorrect version of Berkeley db: co mpiled against 4.0.14, linked against 3.1.14 Of course when I run ldd on /usr/cyrus/bin/master I get the following: [root@birdbrain cyrus-imapd-2.1.2]# ldd /usr/cyrus/bin/master libdl.so.2 = /lib/libdl.so.2 (0x4001e000) libssl.so.0 = /usr/lib/libssl.so.0 (0x40021000) libcrypto.so.0 = /usr/lib/libcrypto.so.0 (0x4004f000) libdb-3.1.so = /lib/libdb-3.1.so (0x40107000) libresolv.so.2 = /lib/libresolv.so.2 (0x40183000) libc.so.6 = /lib/libc.so.6 (0x40195000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Can someone help me to figure out why despite all the measure I am taking to make cyrus link against the the version 4 BerkeleyDB libraries it only gets linked against the version 3 libraries? I appreciate any help I could get with this. Thank you.
--with-auth=unix question
I have done a new installation. However I am not able to authenticate as user cyrus using cyradm although I have given the user cyrus a passwd in /etc/passwd as well as a passwd using saslpasswd. When I run: cyradm -u cyrus localhost imap I get the message no authentication Do I need to run configure and specify --with-auth=unix? I am not interested in having users have accounts on the machine but rather having users have passwords using sasldb? I must have missed something here but I followed the Linux How To exactly so perhaps someone could help me out on this? I would appreciate any feedback. Thanks
Berkeley db compiled against 4.0.14 linked against 3.1.14
Hello, I am trying to install Cyrus 2.1.2 using BerkeleyDB 4.0 and SASL 2.1.2. The compile and the make go fine but when I start up cyrus(/usr/cyrus/bin/master) and I tail the log file I see the following error: Mar 19 23:23:23 birdbrain master[25255]: process 25257 exited, status 75 Mar 19 23:23:23 birdbrain tls_prune[25259]: incorrect version of Berkeley db: co mpiled against 4.0.14, linked against 3.1.14 Here is how I am compiling cyrus. CPPFLAGS=-I/usr/local/BerkeleyDB.4.0/include LDFLAGS=-L /usr/local/BerkeleyDB.4.0/lib -R/usr/local/BerkeleyDB.4.0/lib ./configure --di sable-krb4 --disable-sieve I know that RedHat ships with a version of BerkeleyDB 3, I believe this lives under the /lib as libdb.so. However I don't think this should be a problem given the way I am setting these environmental varialbes - but obviously I am wrong. I noticed to that the cyrus process does run according to ps output and netstat output though. I noticed if I try imtest I see the following. root@birdbrain cyrus-imapd-2.1.2]# imtest -m login -p imap localhost C: C01 CAPABILITY However this will hang and not respond to any input. If anyone could give me some feedback or constructive input regarding this I would greatly appreciate it. Thanks
