RE: suspicious problem on firewall
> I have a Debian Potato machine running as a firewall/masq gateway > on my home > network and I am an AT&T @Home cablemodem subscriber. I've got a fair > amount of Linux administration experience. I've turned off all > the services > that I don't use. I have a nice ipchains ruleset and a script that runs > through the packet log each night. A typical daily report > indicates several > attempted connections on various ports (111 and 27374 are the most common) > and the occasional FTP attempt. It's not a perfect setup, but I > think it's > fairly secure -- a nice middle-of-the-road security stance, I guess. > > I went to send an email tonight (I use Pine 3.96 compiled from the Potato > source package) and pine caught a signal and aborted every time I > moved the > cursor off of the "From" field in the header. I've been using Pine for > quite some time on this machine so I started looking around with a > suspicious eye. The copy of pine was compiled on another machine > and copied > into place, so I did an md5sum on the two -- they are different. A binary > compare revealed that the file sizes are identical but four bytes > have been > modified. I copied the original pine over to the machine and it > works fine. > > I would appreciate thoughts on this situation from people who are more > familiar with system security than I am. Specifically, does this > look like > someone has hacked into my machine or is it more likely that something has > become corrupted (filesystem, hard drive..?) What is the best way to > convince myself that the system either has or has not been broken into? > What other steps would people recommend that I take? It would not be > terribly difficult to wipe the drive and reinstall, but I would prefer to > avoid it of course. > > TIA 27374 connections is sub7 attempts, so those are nothing to worry about (altho you might want to report it anyway). as for whether or not you've been hacked into, that's a completely different matter, and one i can't comment on right now. you probably aren't, but it can't hurt to make sure. i'd reinstall anyway (i've done that after my linux box stopped responding to console logins, just to make 100% sure). secondly, after you've reinstalled debian, i'd suggest you install tripwire, make a snapshot of your setup, move a copy of triwpire's database offsite, and make tripwire check the HD like once every day. also, occasionally, md5sum the database against the offsite copy once in a while. if anything changes, and you don't remember making any changes ... red alert. this won't detect the more skilled hackers, but this will catch a fuckload of them. (damn mailer sent this privately initially, so i'm re-sending it to debian-security in case it might be useful to someone else. sorry for the extra traffic) -m When you are having a bad day, and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle.
Re: suspicious problem on firewall
from the secret journal of Tom Marshall ([EMAIL PROTECTED]): > I would appreciate thoughts on this situation from people who are more > familiar with system security than I am. Specifically, does this look like > someone has hacked into my machine or is it more likely that something has > become corrupted (filesystem, hard drive..?) What is the best way to > convince myself that the system either has or has not been broken into? > What other steps would people recommend that I take? It would not be > terribly difficult to wipe the drive and reinstall, but I would prefer to > avoid it of course. > have you considered compiling pine on the machine in question? -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED]
suspicious problem on firewall
I have a Debian Potato machine running as a firewall/masq gateway on my home network and I am an AT&T @Home cablemodem subscriber. I've got a fair amount of Linux administration experience. I've turned off all the services that I don't use. I have a nice ipchains ruleset and a script that runs through the packet log each night. A typical daily report indicates several attempted connections on various ports (111 and 27374 are the most common) and the occasional FTP attempt. It's not a perfect setup, but I think it's fairly secure -- a nice middle-of-the-road security stance, I guess. I went to send an email tonight (I use Pine 3.96 compiled from the Potato source package) and pine caught a signal and aborted every time I moved the cursor off of the "From" field in the header. I've been using Pine for quite some time on this machine so I started looking around with a suspicious eye. The copy of pine was compiled on another machine and copied into place, so I did an md5sum on the two -- they are different. A binary compare revealed that the file sizes are identical but four bytes have been modified. I copied the original pine over to the machine and it works fine. I would appreciate thoughts on this situation from people who are more familiar with system security than I am. Specifically, does this look like someone has hacked into my machine or is it more likely that something has become corrupted (filesystem, hard drive..?) What is the best way to convince myself that the system either has or has not been broken into? What other steps would people recommend that I take? It would not be terribly difficult to wipe the drive and reinstall, but I would prefer to avoid it of course. TIA --- Funny, there's a brightness dial on the monitor, but the users don't get any smarter. --- Unknown
RE: suspicious problem on firewall
> I have a Debian Potato machine running as a firewall/masq gateway > on my home > network and I am an AT&T @Home cablemodem subscriber. I've got a fair > amount of Linux administration experience. I've turned off all > the services > that I don't use. I have a nice ipchains ruleset and a script that runs > through the packet log each night. A typical daily report > indicates several > attempted connections on various ports (111 and 27374 are the most common) > and the occasional FTP attempt. It's not a perfect setup, but I > think it's > fairly secure -- a nice middle-of-the-road security stance, I guess. > > I went to send an email tonight (I use Pine 3.96 compiled from the Potato > source package) and pine caught a signal and aborted every time I > moved the > cursor off of the "From" field in the header. I've been using Pine for > quite some time on this machine so I started looking around with a > suspicious eye. The copy of pine was compiled on another machine > and copied > into place, so I did an md5sum on the two -- they are different. A binary > compare revealed that the file sizes are identical but four bytes > have been > modified. I copied the original pine over to the machine and it > works fine. > > I would appreciate thoughts on this situation from people who are more > familiar with system security than I am. Specifically, does this > look like > someone has hacked into my machine or is it more likely that something has > become corrupted (filesystem, hard drive..?) What is the best way to > convince myself that the system either has or has not been broken into? > What other steps would people recommend that I take? It would not be > terribly difficult to wipe the drive and reinstall, but I would prefer to > avoid it of course. > > TIA 27374 connections is sub7 attempts, so those are nothing to worry about (altho you might want to report it anyway). as for whether or not you've been hacked into, that's a completely different matter, and one i can't comment on right now. you probably aren't, but it can't hurt to make sure. i'd reinstall anyway (i've done that after my linux box stopped responding to console logins, just to make 100% sure). secondly, after you've reinstalled debian, i'd suggest you install tripwire, make a snapshot of your setup, move a copy of triwpire's database offsite, and make tripwire check the HD like once every day. also, occasionally, md5sum the database against the offsite copy once in a while. if anything changes, and you don't remember making any changes ... red alert. this won't detect the more skilled hackers, but this will catch a fuckload of them. (damn mailer sent this privately initially, so i'm re-sending it to debian-security in case it might be useful to someone else. sorry for the extra traffic) -m When you are having a bad day, and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: suspicious problem on firewall
from the secret journal of Tom Marshall ([EMAIL PROTECTED]): > I would appreciate thoughts on this situation from people who are more > familiar with system security than I am. Specifically, does this look like > someone has hacked into my machine or is it more likely that something has > become corrupted (filesystem, hard drive..?) What is the best way to > convince myself that the system either has or has not been broken into? > What other steps would people recommend that I take? It would not be > terribly difficult to wipe the drive and reinstall, but I would prefer to > avoid it of course. > have you considered compiling pine on the machine in question? -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
suspicious problem on firewall
I have a Debian Potato machine running as a firewall/masq gateway on my home network and I am an AT&T @Home cablemodem subscriber. I've got a fair amount of Linux administration experience. I've turned off all the services that I don't use. I have a nice ipchains ruleset and a script that runs through the packet log each night. A typical daily report indicates several attempted connections on various ports (111 and 27374 are the most common) and the occasional FTP attempt. It's not a perfect setup, but I think it's fairly secure -- a nice middle-of-the-road security stance, I guess. I went to send an email tonight (I use Pine 3.96 compiled from the Potato source package) and pine caught a signal and aborted every time I moved the cursor off of the "From" field in the header. I've been using Pine for quite some time on this machine so I started looking around with a suspicious eye. The copy of pine was compiled on another machine and copied into place, so I did an md5sum on the two -- they are different. A binary compare revealed that the file sizes are identical but four bytes have been modified. I copied the original pine over to the machine and it works fine. I would appreciate thoughts on this situation from people who are more familiar with system security than I am. Specifically, does this look like someone has hacked into my machine or is it more likely that something has become corrupted (filesystem, hard drive..?) What is the best way to convince myself that the system either has or has not been broken into? What other steps would people recommend that I take? It would not be terribly difficult to wipe the drive and reinstall, but I would prefer to avoid it of course. TIA --- Funny, there's a brightness dial on the monitor, but the users don't get any smarter. --- Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: > Christian Kurz escribió: > > > > > > > I have checked it out and would really like to see it included in > > > the DDP and think that debian security guru's should help in > > > > Well, which package should include this documentation? May I also say, > > that some debian security interested guys helped in creating this > > document? > As for the first one I do not know, maybe we should create a > debian-security package to provide this kind of information like the > java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. > well as being a suited metapackage. How about having a package > providing this document and some useful scripts (for example > cron.daily updates from security.debian.org) and dependancies on > security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. > > > ideas? Also, since the package would depend on other packages we > > > need to have this in the chrooted environment too, is there an > > > *easy* way to do this? (without needing to have two package > > > databases) > > > > No, that's why I think chroots should always be set up by the admin and > > not by any tool. And a good idea knows how to create chroots even for > > programs using dynamic linking. > > > I'm not quite the same thinking here. You could use the powerful > package > management tools in order to automatically do this like: > (user) - ok I want bind installed but chrooted in /home/bind > (apt/dpkg) - downloading bind > (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. > (apt/dpkg) - checking dependancies of bind > (apt/dpkg) - moving related libraries (to allow dynamic linking) into > /home/bind > (apt/dpkg) - changing default init.d script to run bind but chrooted > into > /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. > > () > (user) - dpkg --status bind > (dpkg) Package: bind... > Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. > Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpCR0X9pcyRf.pgp Description: PGP signature
Re: What should a Debian-security metapackage should provide?
On 00-12-04 Javier Fernandez-Sanguino Peña wrote: > (I'm taking this out of the previous thread) > I've been giving some thought on a Debian metapackage related to > security.. and I think that it might be useful to have a package > that : Do we really need to discuss this again? There has just been one discussion about this and you can read about it in the archives. Ciao Christian P.S.: Turn that v-card off. -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp35uuc7EJc0.pgp Description: PGP signature
Re: What should a Debian-security metapackage should provide?
On Mon, Dec 04, 2000, Javier Fernandez-Sanguino Peña wrote: > For example, I would add dependancies on snort, nessus, nmap, queso, > cracklib2, ethereal, firestarter (when available as a Debian package), > john, netdiag, sniffit, otp, makepasswd, logcheck, secpolicy, libpam, > lasg... (might have left others outs). Kind of a swiss-army security > knife :) I would remove sniffit from the list, since the sniffit development seems to have stopped, since sniffit is not as secure as it should be (numerous buffer overflows were found some times ago), and since snort is far more efficient and secure. I would also add ippl (IP Protocols Logger). Well, many other things could be added, other removed, maybe other reconfigured (?) in order to harden the Debian system. Should this be discussed now/here? Best regards, -- MaXX
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: > Christian Kurz escribió: > > > > > > > I have checked it out and would really like to see it included in > > > the DDP and think that debian security guru's should help in > > > > Well, which package should include this documentation? May I also say, > > that some debian security interested guys helped in creating this > > document? > As for the first one I do not know, maybe we should create a > debian-security package to provide this kind of information like the > java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. > well as being a suited metapackage. How about having a package > providing this document and some useful scripts (for example > cron.daily updates from security.debian.org) and dependancies on > security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. > > > ideas? Also, since the package would depend on other packages we > > > need to have this in the chrooted environment too, is there an > > > *easy* way to do this? (without needing to have two package > > > databases) > > > > No, that's why I think chroots should always be set up by the admin and > > not by any tool. And a good idea knows how to create chroots even for > > programs using dynamic linking. > > > I'm not quite the same thinking here. You could use the powerful package > management tools in order to automatically do this like: > (user) - ok I want bind installed but chrooted in /home/bind > (apt/dpkg) - downloading bind > (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. > (apt/dpkg) - checking dependancies of bind > (apt/dpkg) - moving related libraries (to allow dynamic linking) into > /home/bind > (apt/dpkg) - changing default init.d script to run bind but chrooted into > /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. > > () > (user) - dpkg --status bind > (dpkg) Package: bind... > Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. > Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: What should a Debian-security metapackage should provide?
On 00-12-04 Javier Fernandez-Sanguino Peña wrote: > (I'm taking this out of the previous thread) > I've been giving some thought on a Debian metapackage related to > security.. and I think that it might be useful to have a package > that : Do we really need to discuss this again? There has just been one discussion about this and you can read about it in the archives. Ciao Christian P.S.: Turn that v-card off. -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: What should a Debian-security metapackage should provide?
from the secret journal of Javier Fernandez-Sanguino Pe?a ([EMAIL PROTECTED]): > For example, I would add dependancies on snort, nessus, nmap, queso, > cracklib2, > ethereal, firestarter (when available as a Debian package), john, netdiag, > sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have > left > others outs). Kind of a swiss-army security knife :) for the same reason as including security documentation, i would include pwgen rather than (or in addition to) makepasswd. pwgen makes pronouncable random passwords that are easier for users to remember, and thus less likely to be on a postit note on the monitor. > > It could also Conflict with known no-security packages.. > > Any ideas? Is it really interesting or just a pointless idea? i think it's a good idea, but i haven't read the rest of this thread yet :) > > Javi -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Snort Log?
Hello, people, this my first time in this list. I've a question for all you guys. I'm running a woody with snort installed and configured to listen on the ppp0, I'received this snort daily report: 3) IDS246 - MISC - Large ICMP Packet: xxx.xx.xx.xx -> home_net After seeking the /var/log/auth.log, I found that I recieve this type of packet every time I connect to the Web server running on this IP. What kind of game is it?. It's a AIX features (the OS that the host claims to run)? There is good (even to check if the client IP isn't spoofed) reason to make this? Another question: sometime I receive alert like this, coming from the same IP (but, I think, this is a hosted website on his IP) IDS244 - CVE-1999-0771 - Compaq-insight-dot-dot: xxx.xx.xx.xx:80 -> my_home_net I think's this a probe to see, if I'm running a Compaq Management Agents to exploit a .. attack? Right? TIA for the answers. -- Raffaele Spangaro [EMAIL PROTECTED]
Re: What should a Debian-security metapackage should provide?
On Mon, Dec 04, 2000, Javier Fernandez-Sanguino Peña wrote: > For example, I would add dependancies on snort, nessus, nmap, queso, > cracklib2, ethereal, firestarter (when available as a Debian package), > john, netdiag, sniffit, otp, makepasswd, logcheck, secpolicy, libpam, > lasg... (might have left others outs). Kind of a swiss-army security > knife :) I would remove sniffit from the list, since the sniffit development seems to have stopped, since sniffit is not as secure as it should be (numerous buffer overflows were found some times ago), and since snort is far more efficient and secure. I would also add ippl (IP Protocols Logger). Well, many other things could be added, other removed, maybe other reconfigured (?) in order to harden the Debian system. Should this be discussed now/here? Best regards, -- MaXX -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should a Debian-security metapackage should provide?
On 4 Dec 2000, Tollef Fog Heen wrote: > etheral? That's an X program - I would _never_ install X on a > server. :) you don't need to be running X to run X applications; just use ssh forwarding. just make sure you're not running anything setuid -- assuming this, i don't see where the risk is. -tl , , ,, ., ,. . . .. .. . . ,. who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: What should a Debian-security metapackage should provide?
* J C Lawrence | Which does not mean that you can't install the X libraries and run | ethereal from a remote X server. Yes, X clients on servers are | bad. X client libraries are not so bad. Having depenency on Xlibs in a 'task-secure' package might not be a very good idea, anyhow? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: What should a Debian-security metapackage should provide?
On 04 Dec 2000 18:37:36 +0100 Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > etheral? That's an X program - I would _never_ install X on a > server. :) Which does not mean that you can't install the X libraries and run ethereal from a remote X server. Yes, X clients on servers are bad. X client libraries are not so bad. -- J C Lawrence [EMAIL PROTECTED] -(*): http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--
Re: What should a Debian-security metapackage should provide?
from the secret journal of Javier Fernandez-Sanguino Pe?a ([EMAIL PROTECTED]): > For example, I would add dependancies on snort, nessus, nmap, queso, cracklib2, > ethereal, firestarter (when available as a Debian package), john, netdiag, > sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have left > others outs). Kind of a swiss-army security knife :) for the same reason as including security documentation, i would include pwgen rather than (or in addition to) makepasswd. pwgen makes pronouncable random passwords that are easier for users to remember, and thus less likely to be on a postit note on the monitor. > > It could also Conflict with known no-security packages.. > > Any ideas? Is it really interesting or just a pointless idea? i think it's a good idea, but i haven't read the rest of this thread yet :) > > Javi -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Snort Log?
Hello, people, this my first time in this list. I've a question for all you guys. I'm running a woody with snort installed and configured to listen on the ppp0, I'received this snort daily report: 3) IDS246 - MISC - Large ICMP Packet: xxx.xx.xx.xx -> home_net After seeking the /var/log/auth.log, I found that I recieve this type of packet every time I connect to the Web server running on this IP. What kind of game is it?. It's a AIX features (the OS that the host claims to run)? There is good (even to check if the client IP isn't spoofed) reason to make this? Another question: sometime I receive alert like this, coming from the same IP (but, I think, this is a hosted website on his IP) IDS244 - CVE-1999-0771 - Compaq-insight-dot-dot: xxx.xx.xx.xx:80 -> my_home_net I think's this a probe to see, if I'm running a Compaq Management Agents to exploit a .. attack? Right? TIA for the answers. -- Raffaele Spangaro [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should a Debian-security metapackage should provide?
Wel... nessus is almost graphic also (although it does run on the CLI) so you would just install the server (nessusd), and firestarter (see http://sourceforge.net/projects/firestarter/) would also be out of the list. We could maybe split it into security and network-analysis maybe (since most of them are of that kind...) Javi > > * Javier Fernandez-Sanguino Peña > > | For example, I would add dependancies on snort, nessus, nmap, queso, > | cracklib2, ethereal, firestarter (when available as a Debian > | package), john, netdiag, sniffit, otp, makepasswd, logcheck, > | secpolicy, libpam, lasg... > > etheral? That's an X program - I would _never_ install X on a > server. :) >begin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: What should a Debian-security metapackage should provide?
On 4 Dec 2000, Tollef Fog Heen wrote: > etheral? That's an X program - I would _never_ install X on a > server. :) you don't need to be running X to run X applications; just use ssh forwarding. just make sure you're not running anything setuid -- assuming this, i don't see where the risk is. -tl , , ,, ., ,. . . .. .. . . ,. who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should a Debian-security metapackage should provide?
* Javier Fernandez-Sanguino Peña | For example, I would add dependancies on snort, nessus, nmap, queso, | cracklib2, ethereal, firestarter (when available as a Debian | package), john, netdiag, sniffit, otp, makepasswd, logcheck, | secpolicy, libpam, lasg... etheral? That's an X program - I would _never_ install X on a server. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: What should a Debian-security metapackage should provide?
* J C Lawrence | Which does not mean that you can't install the X libraries and run | ethereal from a remote X server. Yes, X clients on servers are | bad. X client libraries are not so bad. Having depenency on Xlibs in a 'task-secure' package might not be a very good idea, anyhow? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should a Debian-security metapackage should provide?
On 04 Dec 2000 18:37:36 +0100 Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > etheral? That's an X program - I would _never_ install X on a > server. :) Which does not mean that you can't install the X libraries and run ethereal from a remote X server. Yes, X clients on servers are bad. X client libraries are not so bad. -- J C Lawrence [EMAIL PROTECTED] -(*): http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securing Debian HOWTO - Now in SGML
Ok. I will like to include this, with your permission in the Debian's DDP. An put you as the main maintainer. Is this ok? Alexander Reelsen escribió: > > Hi folks > > As I've had sometime during the weekend I rewrote the HOWTO in SGML as > some of you had wished. The URL is (note the slash ;)) > > http://joker.rhwd.de/doc/Securing-Debian-HOWTO/ > > Currently there is the text, html and SGML version available. Ought to be > enough for everybody. I cleaned up some paragraphs (I wonder what awful (...) > > Oh, and if someone volunteers to write a paragraph about > dpkg-statoverrides, I would not be the only one to be grateful I guess ;) > I don't have a working woody station at the moment so I am not able to > write something about it. I might have time to do what I did when I opened my little mouth in the debian-java mailing list. I asked "is there a FAQ" answer: "no, write one", and I went through all the archived mail in the last half year in order to have a useful Debian-Java FAQ (now available at your nearest DDP :) One of the things I think will be most useful in order to give content to the FAQ is to re-read all the discussions that have taken place in the debian-security mailing list, since many of them will assault gurus/novice users... Regards Javibegin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
What should a Debian-security metapackage should provide?
(I'm taking this out of the previous thread) I've been giving some thought on a Debian metapackage related to security.. and I think that it might be useful to have a package that : - included security-related documentation (aka Debian Security FAQ) - provide useful scripts in examples dir(for example cron.daily updates from security.debian.org) - provided dependencies for free security tools in Debian so that users do not have to be gurus in order to know *what* to install. For example, I would add dependancies on snort, nessus, nmap, queso, cracklib2, ethereal, firestarter (when available as a Debian package), john, netdiag, sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have left others outs). Kind of a swiss-army security knife :) It could also Conflict with known no-security packages.. Any ideas? Is it really interesting or just a pointless idea? Javibegin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: Debian Security-HOWTO
Christian Kurz escribió: > > > > I have checked it out and would really like to see it included in > > the DDP and think that debian security guru's should help in > > Well, which package should include this documentation? May I also say, > that some debian security interested guys helped in creating this > document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... > > > improving it. One thing I would like to have nicely documented is to > > make chroot jails. But not Linux-wide but Debian-specific, that is: > > What should be documented? Mostly you need to have all config files, > libaries and binaries in the same structure as under / in a seperate > dir, where you chroot to. See below. > > > is there a way to build packages available in Debian in order to > > easily install them chrooted? My first thought is that only if the > > You don't need to statically link packages to chroot them. You can also > chroot them, if they use dynamic linking, but then you need to copy > these libs also into the chroot-dir. I do know. > > > ideas? Also, since the package would depend on other packages we > > need to have this in the chrooted environment too, is there an > > *easy* way to do this? (without needing to have two package > > databases) > > No, that's why I think chroots should always be set up by the admin and > not by any tool. And a good idea knows how to create chroots even for > programs using dynamic linking. > I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Did it make any sense? Regards Javibegin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: What should a Debian-security metapackage should provide?
Wel... nessus is almost graphic also (although it does run on the CLI) so you would just install the server (nessusd), and firestarter (see http://sourceforge.net/projects/firestarter/) would also be out of the list. We could maybe split it into security and network-analysis maybe (since most of them are of that kind...) Javi > > * Javier Fernandez-Sanguino Peña > > | For example, I would add dependancies on snort, nessus, nmap, queso, > | cracklib2, ethereal, firestarter (when available as a Debian > | package), john, netdiag, sniffit, otp, makepasswd, logcheck, > | secpolicy, libpam, lasg... > > etheral? That's an X program - I would _never_ install X on a > server. :) > begin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: What should a Debian-security metapackage should provide?
* Javier Fernandez-Sanguino Peña | For example, I would add dependancies on snort, nessus, nmap, queso, | cracklib2, ethereal, firestarter (when available as a Debian | package), john, netdiag, sniffit, otp, makepasswd, logcheck, | secpolicy, libpam, lasg... etheral? That's an X program - I would _never_ install X on a server. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securing Debian HOWTO - Now in SGML
Ok. I will like to include this, with your permission in the Debian's DDP. An put you as the main maintainer. Is this ok? Alexander Reelsen escribió: > > Hi folks > > As I've had sometime during the weekend I rewrote the HOWTO in SGML as > some of you had wished. The URL is (note the slash ;)) > > http://joker.rhwd.de/doc/Securing-Debian-HOWTO/ > > Currently there is the text, html and SGML version available. Ought to be > enough for everybody. I cleaned up some paragraphs (I wonder what awful (...) > > Oh, and if someone volunteers to write a paragraph about > dpkg-statoverrides, I would not be the only one to be grateful I guess ;) > I don't have a working woody station at the moment so I am not able to > write something about it. I might have time to do what I did when I opened my little mouth in the debian-java mailing list. I asked "is there a FAQ" answer: "no, write one", and I went through all the archived mail in the last half year in order to have a useful Debian-Java FAQ (now available at your nearest DDP :) One of the things I think will be most useful in order to give content to the FAQ is to re-read all the discussions that have taken place in the debian-security mailing list, since many of them will assault gurus/novice users... Regards Javi begin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
What should a Debian-security metapackage should provide?
(I'm taking this out of the previous thread) I've been giving some thought on a Debian metapackage related to security.. and I think that it might be useful to have a package that : - included security-related documentation (aka Debian Security FAQ) - provide useful scripts in examples dir(for example cron.daily updates from security.debian.org) - provided dependencies for free security tools in Debian so that users do not have to be gurus in order to know *what* to install. For example, I would add dependancies on snort, nessus, nmap, queso, cracklib2, ethereal, firestarter (when available as a Debian package), john, netdiag, sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have left others outs). Kind of a swiss-army security knife :) It could also Conflict with known no-security packages.. Any ideas? Is it really interesting or just a pointless idea? Javi begin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: Debian Security-HOWTO
Christian Kurz escribió: > > > > I have checked it out and would really like to see it included in > > the DDP and think that debian security guru's should help in > > Well, which package should include this documentation? May I also say, > that some debian security interested guys helped in creating this > document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... > > > improving it. One thing I would like to have nicely documented is to > > make chroot jails. But not Linux-wide but Debian-specific, that is: > > What should be documented? Mostly you need to have all config files, > libaries and binaries in the same structure as under / in a seperate > dir, where you chroot to. See below. > > > is there a way to build packages available in Debian in order to > > easily install them chrooted? My first thought is that only if the > > You don't need to statically link packages to chroot them. You can also > chroot them, if they use dynamic linking, but then you need to copy > these libs also into the chroot-dir. I do know. > > > ideas? Also, since the package would depend on other packages we > > need to have this in the chrooted environment too, is there an > > *easy* way to do this? (without needing to have two package > > databases) > > No, that's why I think chroots should always be set up by the admin and > not by any tool. And a good idea knows how to create chroots even for > programs using dynamic linking. > I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Did it make any sense? Regards Javi begin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
