Re: Task-harden
On Mon, Apr 02, 2001 at 01:45:14PM -0300, DrPablo@mail.com wrote:
> Hi!
> That would be nice. Have you consider my suggestion of adopting
> SubDomain (http://www.immunix.org/subdomain.html) instead of chroot?
> I've never used it, and I guess chroot is probably a most common and
> known solution, but, anyway, I guess it worth a look.
It was worth a look but I do not like to register myself. And
I suspect that the license is not that good. :(
Interesting idéa though. But the kernel had to be modified and I
personally do not want to force that...
Nice reading though.
But if there are (and it seems to exist) replacement for bind
I'll conflict that package. There are just too many eploits for
that one.
Ahh now I remember one more package.
imap should be avoided, imap-ssl is better. :)
No protocols that needs passwords in plaintext. :)
> | timed, dos on the entire machine or just the specific service?
>
> I have to dig this up: BugTraq emailed me this advisory:
> http://www.securityfocus.com/bid/2491 . Take a lok for yourself. Looks
> like it comprimises just the time service.
I can't see the package. What package includes the timed?
> | slrn, isn't that a news reader? suid root or?
>
> I guess so! (I use nn, BTW). I remember to have an advisory
> someplace. As soon as I dig this up you will be notified.
That sounds good. I do not want to conflict with packages if there
are just single exploits for some versions. If there are _very lot_
of exploits and new ones arise now and then maybe the whole package
should be avoided. And of course if the entire concept is wrong. :)
If there are single versions that are exploited I intend to just
conflict that version.
> | > Tripwire (I guess LIDS or AIDE can be an option to this. You can
> | > make a Require: IDS and Tripwire, AIDE and LIDS may contain a Provide:
> | > IDS. You should contact David Spreen which is maintaining lids, I
> | > guess), qmail or postfix, gnupg, snort, ssh (of course), shadow, PAM
> | > with md5 and cracklib, john (maybe).
> |
> | Added gnupg, john to suggest.
> |
> | is IDS with capital letters?
>
> I guess so... since it is an abbreviature.
ok.
By the way is there a list of all virtual packages somewhere?
Or a easy way to see what virtual packages a pacakge provides.
No I do not want to download the source. :)
> | > | And now some questions (that can be dicussed).
> | > | * I intend to conflict with inetd. Do you think that is ok?
> | >
> | > Great! I hate that godamned thing! Too much exploitable!!! I
> | > guess not so much with tcpd. I guess a good approach (as we could have
> | > some inetd lovers) is to make inetd require tcpd or replace it with
> | > xinetd or tcpserver.
> |
> | Is it inetd that is the prob or the packages that needs it?
>
> Don't know. There's just too many e-books for script kidies
> written (at least in Portuguese) that teaches how to exploit inetd
> services. I guess if tcpd is ok, we have nothing to worry (this is why
> I use inetd after all. But you bet if we have xinetd or tcpserver
> packaged I'd use that).
I think it is the tools that needs inetd...
But (as someone said) inetd should not be installed as default.
Only the packages that really needs inetd should depend on it.
Like telnetd (and so on).
>
> BTW, what do you think of packaging DTK (Deception ToolKit)
> (http://all.net/dtk/dtk.html). I don't know about their licensing
> issues, but I think it is a good tool.
Well I do not think I personally like the license. Quite good
but we have to report all changes back...
I think it is too similar to something that I myself wrote some
years ago. Maybe they got a bit further but personally I do not
like the idéa. Use firewall rules instead. :) But if you like
it package it and see how good it works. I just do not like the
idéa (that I used myself before I know about things like ipchains)
to hook on tcpd...
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: