Re: Grsecurity patches on Debian
hi, I use Grsecurity with High level for over 2 years now on 2.4.X without any problems running debian woody. These daemons works fine: ssh postfix courier-imap (with and without ssl) courier-pop (with and without ssl) apache apache-ssl mysql snort and a view other ... The best way would be for you to test this configuration offline on a system with the same packages and then install it on the production system. For further question and special question you can contact the grsecurity mailing list. It is a very low traffic list and brad sprengler help you with every question or the pax team. Greetz Konstantin On Tue, 8 Feb 2005 02:32:03 +0100 Xavier Sudre <[EMAIL PROTECTED]> wrote: > On Monday 07 February 2005 at 16:17, Andras Got wrote: > > Hi, > > > > That's it, the chpax. I tried these things almost a year ago with JSP > > thingy. I googled and the like, but chpax didn't help. > > > > I meant that I selected high settings, then selected custom, then did some > > changes. :) > > > > A. > > > > > > Thomas Sjögren írta: > > > > >On Mon, Feb 07, 2005 at 02:10:07PM +0100, Andras Got wrote: > > > > > >>You should start with grsec low and proc restricions set customly. > > >>Hardening your kernel is always a option. > > > > > > > > >Running grsec isn't a problem, I use on both clients and servers. > > >Dont start with grsec low but with the custom option, > > >CONFIG_GRKERNSEC_CUSTOM and read the help sections. > > > > > > > > >>The grsec default high settings, > > > > > > > > >IIRC it defaults to custom. > > > > > > > > >>and PaX break Jetty (java server container) in two, so it simply won't > > >>start, gradm won't help as I know. > > > > > > > > >changing PaX-settings is done by chpax or paxctl. gradm is for the acl. if > > >something breaks > > >chpax -peMRXs usually works, after that its about fine tuning. > > > > > Using grsecurity with level set to High enables Pax features. > This works well on most daemons delivered as packages in Debian Woody > and hopefuly testing. At least this is the case for Apache, Postfix and Cyrus. > > When ever there is a problem with a binary there will be a log trace in > the syslog specifying the binary that was terminated. You can correct > the problem by using chpax. > > Xavier. > > -- > Xavier Sudre > Homepage: http://xavier.sudre.fr/ > Email:[EMAIL PROTECTED] > GPG key: http://xavier.sudre.fr/gpg/xavier.asc > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Building an operation system without source code, is like buying a self assemble space shuttle without instructions. pgp8BqUPZYcjK.pgp Description: PGP signature
Re: Mirrors security
Do I really have to check all .deb files of Packages files if I have
already checked all Packages' files themselves and they do check? AFAIK
apt-get always check if md5 (from Packages files it downloads) does not
match and warns/forbids the user of intalling such a "dirty" package. I
mean, what really matters is to check if all Packages{,.gz} have got a
good signature from Archiver, am I right?
--
Felipe
On Sat, 5 Feb 2005, Brendan O'Dea wrote:
On Fri, Feb 04, 2005 at 08:32:55PM -0200, Felipe Massia Pereira wrote:
I'd like to know more about security procedures for mirrors, mainly how
to check the repository for malicious corruption, and if there is a
channel which could be used to notify users who download from my mirror.
The checksums of the Packages files for a distribution are contained in
the dists/DIST/Release file, with a detached signature Release.gpg .
This provides a chain of trust by which each package may be verified
against a checksum in the Packages file, which itself may be verified
using the signed Release file.
There is a patch to APT to do this automatically, currently only applied
to the experimental version.
As checking an entire mirror, I don't know of anything which currently
does this, but the process should be fairly straightforward:
1. For each distribution D, verify dist/D/Release{,.gpg} against the
archive key.
2. Check the md5sums of the files listed in each Release file.
3. Check the md5sums of the packages listed in each Packages file.
--bod
--
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: Compromised system - still ok? - doorstep
hi ya On Mon, 7 Feb 2005, James Renken wrote: .. > The summary in legal terms: contributory negligence is not a defense to an > intentional (or reckless) tort. The first major case I found with an > offhand search is: > > Schellhouse v. Norfolk & W. Ry. Co., 575 N.E.2d 453, 456 (Ohio 1991) thanx... > Hope this helps. :) The largest problem, I think, would be identifying the > intruder with enough certainty to sue them. it'd be fun to have the cops show up on the cracker's doorstep while they're in the cracked servers along the way at the time and the victim's servers - makes it a whole lot easier c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Paulo Eduardo Pasquini Marcondes/RJ/Petrobras está ausente do escritório.
Estarei ausente do escritório a partir de 02/05/2005 e não retornarei até 02/27/2005. I'll be out of the office from 5 to 27, Feb, and will answer no messages during this period. If this is urgent maater, please forward to Mr. Evaldo Mundim ([EMAIL PROTECTED]). When I got back I'll answer the messages as soon as possible. "O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe ao destinatário cuidar quanto ao tratamento adequado. Sem a devida autorização, a divulgação, a reprodução, a distribuição ou qualquer outra ação em desconformidade com as normas internas do Sistema Petrobras são proibidas e passíveis de sanção disciplinar, cível e criminal." "The sender of this message is responsible for its content and addressing. The receiver shall take proper care of it. Without due authorization, the publication, reproduction, distribution or the performance of any other action not conforming to Petrobras System internal policies and procedures is forbidden and liable to disciplinary, civil or criminal sanctions." " El emisor de este mensaje es responsable por su contenido y direccionamiento. Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorización, su divulgación, reproducción, distribución o cualquier otra acción no conforme a las normas internas del Sistema Petrobras están prohibidas y serán pasibles de sanción disciplinaria, civil y penal."
Re: Grsecurity patches on Debian
On Monday 07 February 2005 at 16:17, Andras Got wrote: > Hi, > > That's it, the chpax. I tried these things almost a year ago with JSP > thingy. I googled and the like, but chpax didn't help. > > I meant that I selected high settings, then selected custom, then did some > changes. :) > > A. > > > Thomas Sjögren írta: > > >On Mon, Feb 07, 2005 at 02:10:07PM +0100, Andras Got wrote: > > > >>You should start with grsec low and proc restricions set customly. > >>Hardening your kernel is always a option. > > > > > >Running grsec isn't a problem, I use on both clients and servers. > >Dont start with grsec low but with the custom option, > >CONFIG_GRKERNSEC_CUSTOM and read the help sections. > > > > > >>The grsec default high settings, > > > > > >IIRC it defaults to custom. > > > > > >>and PaX break Jetty (java server container) in two, so it simply won't > >>start, gradm won't help as I know. > > > > > >changing PaX-settings is done by chpax or paxctl. gradm is for the acl. if > >something breaks > >chpax -peMRXs usually works, after that its about fine tuning. > > Using grsecurity with level set to High enables Pax features. This works well on most daemons delivered as packages in Debian Woody and hopefuly testing. At least this is the case for Apache, Postfix and Cyrus. When ever there is a problem with a binary there will be a log trace in the syslog specifying the binary that was terminated. You can correct the problem by using chpax. Xavier. -- Xavier Sudre Homepage: http://xavier.sudre.fr/ Email:[EMAIL PROTECTED] GPG key: http://xavier.sudre.fr/gpg/xavier.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 07:26:43PM +0100, Milan P. Stanic wrote: > On Mon, Feb 07, 2005 at 06:25:19PM +1100, Matthew Palmer wrote: > > Obviously you've never done this. Good luck finding someone who even knows > > what TCP/IP is, let alone sufficient knowledge to be able to track a cracker > > in real time with no warning. > > How smart they are can be seen at: > http://www.boingboing.net/2005/01/27/jailed_for_using_a_n.html > > In short: A man used lynx to donate to tsunami victims but webmaster > at british telekom called the police and the charitable man is > arrested. > > I don't know should I cry or should I laugh. I'd suggest verifying the story, first. The BBC story which is commonly referenced doesn't actually mention the use of lynx, and attempts by people in the UK to actually find the real source of the story have (to the best of my knowledge) proven fruitless. - Matt signature.asc Description: Digital signature
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 06:25:19PM +1100, Matthew Palmer wrote: > Obviously you've never done this. Good luck finding someone who even knows > what TCP/IP is, let alone sufficient knowledge to be able to track a cracker > in real time with no warning. How smart they are can be seen at: http://www.boingboing.net/2005/01/27/jailed_for_using_a_n.html In short: A man used lynx to donate to tsunami victims but webmaster at british telekom called the police and the charitable man is arrested. I don't know should I cry or should I laugh. signature.asc Description: Digital signature
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 06:32:12PM +0200, Ognyan Kulev wrote: He said that after signed Fedora package is installed (by default, only signed packages are installed), you can boot from some CD and then check signatures of each file of each package. Thus, only having key Red Hat's fingerprint, you can check your all installed packages. What I'm asking is if this is possible with dpkg-sig? If not, I think it's desirable feature. No it's not. The redhat approach misses the boat on what is probably the largest part of your installation--your data & configuration files. Use something like aide or tripwire to validate your installation. Another thing he doesn't like is that check is based on signed MD5 hash of content instead of based on signed content. Is it true that signed MD5 is weaker than signed content? No. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 06:32:12PM +0200, Ognyan Kulev wrote: > Another thing he doesn't like is that check is based on signed MD5 hash of > content instead of based on signed content. Is it true that signed MD5 is > weaker than signed content? assymetric crypto ops are very slow, so you wouldn't want to do them on the whole content (signature would be the same order of size as teh content too..). so you always sign a message digest. you would want to choose a better one than md5 though (sha1 for example), but that's a trivial change cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Compromised system - still ok?
Geoff Crompton wrote: So can you be really sure that there was no root kit that succesfully exploited your system? Have you rebooted off a trusted kernel, and cryptographically checked every single file involved in booting? (Such as the grub/lilo, kernel, all modules, init), and visually or cryptographically checked all the rc.* files and /etc/inittab? Of course, doing all this might mean that you avoid booting the rootkit next time. But it could still be on the disk, waiting for when the attacker tries to return! A friend of mine is fan of Red Hat. He regularly laughs at Debian because package content is not signed so I got interested in these matters. I became aware of secure apt and dpkg-sig. He said that after signed Fedora package is installed (by default, only signed packages are installed), you can boot from some CD and then check signatures of each file of each package. Thus, only having key Red Hat's fingerprint, you can check your all installed packages. What I'm asking is if this is possible with dpkg-sig? If not, I think it's desirable feature. I didn't find the answer in http://dpkg-sig.turmzimmer.net/faq.html -- "dpkg-sig is _very_ interesting for those of us who want to know where a package went, and when." Verifying files of already installed package is not mentioned. Another thing he doesn't like is that check is based on signed MD5 hash of content instead of based on signed content. Is it true that signed MD5 is weaker than signed content? Regards, ogi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Grsecurity patches on Debian
Hi, That's it, the chpax. I tried these things almost a year ago with JSP thingy. I googled and the like, but chpax didn't help. I meant that I selected high settings, then selected custom, then did some changes. :) A. Thomas Sjögren írta: On Mon, Feb 07, 2005 at 02:10:07PM +0100, Andras Got wrote: You should start with grsec low and proc restricions set customly. Hardening your kernel is always a option. Running grsec isn't a problem, I use on both clients and servers. Dont start with grsec low but with the custom option, CONFIG_GRKERNSEC_CUSTOM and read the help sections. The grsec default high settings, IIRC it defaults to custom. and PaX break Jetty (java server container) in two, so it simply won't start, gradm won't help as I know. changing PaX-settings is done by chpax or paxctl. gradm is for the acl. if something breaks chpax -peMRXs usually works, after that its about fine tuning. /Thomas -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Grsecurity patches on Debian
On Mon, Feb 07, 2005 at 02:10:07PM +0100, Andras Got wrote: > You should start with grsec low and proc restricions set customly. > Hardening your kernel is always a option. Running grsec isn't a problem, I use on both clients and servers. Dont start with grsec low but with the custom option, CONFIG_GRKERNSEC_CUSTOM and read the help sections. > The grsec default high settings, IIRC it defaults to custom. > and PaX break Jetty (java server container) in two, so it simply won't > start, gradm won't help as I know. changing PaX-settings is done by chpax or paxctl. gradm is for the acl. if something breaks chpax -peMRXs usually works, after that its about fine tuning. /Thomas -- signature.asc Description: Digital signature
Re: Grsecurity patches on Debian
Greetings,.. Am Montag, 7. Februar 2005 14:10 schrieb Andras Got: > Hi, > > You should start with grsec low and proc restricions set customly. > Hardening your kernel is always a option. The grsec default high settings, > and PaX break Jetty (java server container) in two, so it simply won't > start, gradm won't help as I know. After the grsec default low settings you > should read about the functions grsec has, and consider which one is good > for you or worth using. I have grsec deafult high (+ the new extras set) > kernels on gateways and one prod webserver. It works very well so far. > Grsec+PaX itself won't break any program, that don't do anything wierd or > unusual and suspicous. When you use chroot (postfix uses it by default), > grsec can harden very vell your chroot systems. Well, once I had some trouble using wine on an openwall patched terminal server. I don't know, whetere these issue still apply. Keep smiling yanosz -- Achtung: Die E-Mail-Adresse [EMAIL PROTECTED] wird in Kürze deaktiviert werden. Bitte nutzen Sie die Adresse [EMAIL PROTECTED]
Re: Compromised system - still ok?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 6 Feb 2005, Scott Edwards wrote: > 1. Your box gets compromised > 2. You sue them > 3. And then collect damages > > You'll quickly loose a case if there is any demonstration of > negligence (that tail between your legs about the backup account - > yea, you know, but didn't act. that's enough negligence to blow the > case) (Standard disclaimer: I am a law student, not a lawyer, and I cannot provide legal advice. This is my opinion only, and should not be relied on for any purpose. Seek professional advice.) I'm fairly sure that this wouldn't be a problem if you decided to sue an intruder. You're right that in many cases, the person you're suing can introduce evidence of your own negligence in order to get the case thrown out, but this doesn't apply in cases like this where the defendant's act was intentional. The summary in legal terms: contributory negligence is not a defense to an intentional (or reckless) tort. The first major case I found with an offhand search is: Schellhouse v. Norfolk & W. Ry. Co., 575 N.E.2d 453, 456 (Ohio 1991) This might vary from state to state, but the principle makes enough sense that it's probably standard. I am, of course, assuming U.S. law here. Hope this helps. :) The largest problem, I think, would be identifying the intruder with enough certainty to sue them. - -- James Renken, System Administrator [EMAIL PROTECTED] Sandwich.Net Internet Services http://www.sandwich.net/ 1-877-HUBWICH -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFCB3SKqV3dP0gp4AQRAnMZAJiokNionBGwLBWcOR492kgxtqJIAJ9oVT8A VI4qsuvp5JLU/uzem7MvBA== =GtGZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, 7 Feb 2005, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > >- works great across the usa, even if the cracked > >box they came from was offshore, they can trace it > >back to somebody's bedroom or colo > > is that first hand knowledge or just some usual urband legend? first hand only ... with tons of paperwork and emails and phone .. and supposedly not so happy isp's being "forced" to cooperate and trace the crackers down if i was the isp, i'd be happy to get some script kiddies and more threatening folks off the wire vs letting um roam freely c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Grsecurity patches on Debian
Hi, You should start with grsec low and proc restricions set customly. Hardening your kernel is always a option. The grsec default high settings, and PaX break Jetty (java server container) in two, so it simply won't start, gradm won't help as I know. After the grsec default low settings you should read about the functions grsec has, and consider which one is good for you or worth using. I have grsec deafult high (+ the new extras set) kernels on gateways and one prod webserver. It works very well so far. Grsec+PaX itself won't break any program, that don't do anything wierd or unusual and suspicous. When you use chroot (postfix uses it by default), grsec can harden very vell your chroot systems. Regards, Andrej Marcus Williams írta: Hi - Has anyone any advice on using grsecurity on a server running Debian (testing) - I'm thinking about patching my new kernel with the grsecurity stuff and starting to use it but I'm unsure of what I can expect. Are the defaults going to break (or stop from functioning) anything obvious (namely sshd/apache etc)? This is a remote box so I want to avoid losing network access etc. Initially I'm going to set it up as in the Quick Start docs on the grsecurity site. Has anyone advice where to start after that? Cheers Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
In article <[EMAIL PROTECTED]> you wrote: >- works great across the usa, even if the cracked >box they came from was offshore, they can trace it >back to somebody's bedroom or colo is that first hand knowledge or just some usual urband legend? Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
In article <[EMAIL PROTECTED]> you wrote: > I co-administer a system with ~ 250 users, a significant part of them I > don't know very well personally, and really, I don't rule out some of > them might try to do some cracking, of, more likely, has such a shoddy > password policy or infected windows system that their account will be > used to. > > Should I now reinstall these systems daily? Well, the problem is of course root compromise. However, on such a system, break-ins are very likely and you better do checks regularly. This is to protect your users. > In both my case, and the thread starter's case, a normal user account > might or was definitely in the hands of someone malicious. In both > cases, no evidence whatsoever was there that there was even an attempt > at becoming root. Then a re-install might not be needed. At least if you can explain how the user account could have been compromised. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Grsecurity patches on Debian
Hi - Has anyone any advice on using grsecurity on a server running Debian (testing) - I'm thinking about patching my new kernel with the grsecurity stuff and starting to use it but I'm unsure of what I can expect. Are the defaults going to break (or stop from functioning) anything obvious (namely sshd/apache etc)? This is a remote box so I want to avoid losing network access etc. Initially I'm going to set it up as in the Quick Start docs on the grsecurity site. Has anyone advice where to start after that? Cheers Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 12:35:45AM +0100, martin f krafft wrote: > Once an attacker is on the system, you cannot be sure anymore that > you can track his/her actions down. Sophisticated root kits exist to > cover all (!) traces. I co-administer a system with ~ 250 users, a significant part of them I don't know very well personally, and really, I don't rule out some of them might try to do some cracking, of, more likely, has such a shoddy password policy or infected windows system that their account will be used to. Should I now reinstall these systems daily? I see not much difference, except that in this case, there really was someone with evil intentions on an account, but as said already in this thread, what you see is only part of what happens. Especially on a busy multiuser system, suspected activity might go unnoticed. In both my case, and the thread starter's case, a normal user account might or was definitely in the hands of someone malicious. In both cases, no evidence whatsoever was there that there was even an attempt at becoming root. My point was and is, user account != root. Any such hole is would be dangerous, but if you cannot somewhat reasonably assume this, you are only paranoidedly going to reinstall systems over and over again. My final remark in this thread about this specific case: If it was merely a backup MX, indeed, just reinstall, as the only valuable thing was probably the mail queue (harmless) and the mail config (probably trivial or at least trivally checkeable). If you reboot from CD-ROM and fdisk & mkfs the harddisk from start, all this hidden files in filesystems etc is just FUD. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Compromised system - still ok?
> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes: Matthew> I have reported intruders to the relevant authorities in Matthew> the past, and have encountered an apathy field the size Matthew> of a small continent. The only way they will even Well, I think it may depend on which country you're in. We had an incedent a while ago that was reported to the police (Norway). They were interested, took the machine in, copied the disk, etc. Whether this is due to the fact we are a government organisation or the Norwegian authorities are more interested than other countries' I'm uncertain. I would suggest at least contacting your local authorities before assuming they are apathetic. Sincerely, Adrian Phillips -- Who really wrote the works of William Shakespeare ? http://www.pbs.org/wgbh/pages/frontline/shakespeare/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, Feb 06, 2005 at 11:53:50PM -0800, Alvin Oga wrote: don't accuse others ( me ) of what you haven't done yourself, or dont want to do, as it only makes you look like the script kiddie If anyone in this thread sounds like a kiddie it's you. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: [USN-74-1] Postfix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Already read this link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267837 Jan Wagner wrote: | -- Forwarded Message -- | | Subject: [USN-74-1] Postfix vulnerability | Date: Sunday 06 February 2005 23:55 | From: Wietse Venema <[EMAIL PROTECTED]> | To: Postfix announce <[EMAIL PROTECTED]> | Cc: Postfix users <[EMAIL PROTECTED]> | | In a recent announcement on the Full-Disclosure mailing list, Martin | | Pitt <[EMAIL PROTECTED]> wrote: | |>Jean-Samuel Reynaud noticed a programming error in the IPv6 handling |>code of Postfix when /proc/net/if_inet6 is not available (which is the |>case in Ubuntu since Postfix runs in a chroot). If "permit_mx_backup" |>was enabled in the "smtpd_recipient_restrictions", Postfix turned into |>an open relay, i. e. erroneously permitted the delivery of arbitrary |>mail to any MX host which has an IPv6 address. | | | This is a bug in a third-party IPv6 patch that is not part of | Postfix. The bug affects Linux systems only. | | Neither the official Postfix release, nor the work-in-progress | version (which has IPv6 support built-in) are affected by this. | | Please do not ask me how to resolve the vulnerability. Contact info | for the third-party IPv6 patch is at http://www.ipnet6.org/postfix/ipv6.html. | | Please do not ask me what Linux distributions are affected. Contact | your Linux distributor instead. | | It would be nice if Linux distributors could indicate whether a | Postfix problem is part of the software base itself, or due to a | third-party add-on that they included with the base software. | | Wietse | | --- | | Hi list! | | my short question about the topic are: | | Is the recent postfix version of sarge (2.1.5-5) affected and if, when can be | a fixed version expected? | | With kind regards, Jan. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB02X2n1ROIkXqbARAoElAKCVO3GXkBmzKXA1EhMpIuJe5xPwSACdGIur SfCSk7hih3jhl2ux3IcoodQ= =eTtP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: [USN-74-1] Postfix vulnerability
-- Forwarded Message -- Subject: [USN-74-1] Postfix vulnerability Date: Sunday 06 February 2005 23:55 From: Wietse Venema <[EMAIL PROTECTED]> To: Postfix announce <[EMAIL PROTECTED]> Cc: Postfix users <[EMAIL PROTECTED]> In a recent announcement on the Full-Disclosure mailing list, Martin Pitt <[EMAIL PROTECTED]> wrote: > Jean-Samuel Reynaud noticed a programming error in the IPv6 handling > code of Postfix when /proc/net/if_inet6 is not available (which is the > case in Ubuntu since Postfix runs in a chroot). If "permit_mx_backup" > was enabled in the "smtpd_recipient_restrictions", Postfix turned into > an open relay, i. e. erroneously permitted the delivery of arbitrary > mail to any MX host which has an IPv6 address. This is a bug in a third-party IPv6 patch that is not part of Postfix. The bug affects Linux systems only. Neither the official Postfix release, nor the work-in-progress version (which has IPv6 support built-in) are affected by this. Please do not ask me how to resolve the vulnerability. Contact info for the third-party IPv6 patch is at http://www.ipnet6.org/postfix/ipv6.html. Please do not ask me what Linux distributions are affected. Contact your Linux distributor instead. It would be nice if Linux distributors could indicate whether a Postfix problem is part of the software base itself, or due to a third-party add-on that they included with the base software. Wietse --- Hi list! my short question about the topic are: Is the recent postfix version of sarge (2.1.5-5) affected and if, when can be a fixed version expected? With kind regards, Jan. -- ,,_ If wishes were wings, o" )~ would fly. -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a-- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M-- V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgpt3HiYzWVqB.pgp Description: PGP signature
Conclusion: Compromised system - still ok?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wow you guys, thank you very much for all your input. I'll sit down with the manager and we'll discuss which route to take. My first instinct was to warm up those drives and get the tapes .. but I may want to find out more as you guys have suggested! (Thanks to Jeroen, Alvin and Roger) The system is/was an absolutely unimportant backup-mx so I don't think we'll qualify for three-letter help :) In any case .. it has been a very interesting sunday indeed. I'll try to learn from my mistakes. - - Thank you very much, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iEYEARECAAYFAkIHL84ACgkQ7qdt1xpQls/J7ACgm2ul7gugzoYVoUdAwZ0D+DrT xEAAn3iVE30yOjNdGBt3BQ5TDXQWWQzq =Z6dZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok? - let it go
hi ya matt On Mon, 7 Feb 2005, Matthew Palmer wrote: > Three step program for you, bub. > > 1) Place your feet on your shoulders; > 2) Push hard; > 3) Take your first breath of arse-free air in a long time. sounds like you should do the same ... or more like too late for you > I have reported intruders to the relevant authorities in the past, and that'd depnd on you and them to do something > can't imagine they'd be even vaguely interested in some two-bit penetration. yup.. until something happens that is a problem for them ... in which case they jump and do something fast .. like i said, don't accuse others of having the same failures as you did or didn't even try yourself - not everybody fails .. and these script kiddies and cracker coders beat ya since you don't know what to do with um == isn't it enough of this ... there's better things to do - you have your ways to deal with it - others have theirs, and "your experiences" is not the same for others c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Sun, Feb 06, 2005 at 11:53:50PM -0800, Alvin Oga wrote: > > On Mon, 7 Feb 2005, Matthew Palmer wrote: > > > On Sun, Feb 06, 2005 at 10:52:50PM -0800, Alvin Oga wrote: > > > it's best when you can call the fbi (on the phone) and say, they're > > > back, trace um "NOW" > > > > Obviously you've never done this. > > and obviously you seem too lazy to catch the cracker ?? > > don't accuse others ( me ) of what you haven't done yourself, > or dont want to do, as it only makes you look like the script kiddie Three step program for you, bub. 1) Place your feet on your shoulders; 2) Push hard; 3) Take your first breath of arse-free air in a long time. I have reported intruders to the relevant authorities in the past, and have encountered an apathy field the size of a small continent. The only way they will even vaguely give a damn is there is easily demonstrated loss of a significant amount. They've got bigger fish to fry. Considering that there are 100,000 node botnets running around capable of bringing more or less any website in existence to it's knees, and the Feds seem in no hurry to bring those down, nor to do an awful lot to stop the infection at it's source, I can't imagine they'd be even vaguely interested in some two-bit penetration. - Matt signature.asc Description: Digital signature
Re: Compromised system - still ok?
On Mon, 7 Feb 2005, Matthew Palmer wrote: > On Sun, Feb 06, 2005 at 10:52:50PM -0800, Alvin Oga wrote: > > it's best when you can call the fbi (on the phone) and say, they're > > back, trace um "NOW" > > Obviously you've never done this. and obviously you seem too lazy to catch the cracker ?? don't accuse others ( me ) of what you haven't done yourself, or dont want to do, as it only makes you look like the script kiddie - let me know what you want me to catch your crackers .. part of the fun .. everybody has different priorities of what to do before, during and after.. c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
