Unidentified subject!
Concerne : Enregistrement des domaines *.INFO et .BIZ Ce courrier vous est envoyé par http://Yawadoo.com (enregistrement .INFO .BIZ .BE .COM ..ORG .NET ..DE) Agent agrée pour l'enregistrement de noms de domaines européens et étrangers. -- Cher internaute, Circulaire du 14/11/2001 concernant l'enregistrement des domaines ..INFO ..BIZ -- A partir de septembre les noms de domaines .INFO .BIZ sont disponibles ! -- Enfin on peut souscrire pour .INFO .BIZ Le domaine .INFO sera à l'avenir plus important que le .com. Actuellement il y a déjà plus d'1 million de demandes dans le monde. Inscrivez-vous à temps dés maintenant !. Début septembre toutes les demandes sont automatiquement délivrées. En fin septembre sera communiqué si vous avez obtenu un nom. INFO ou. BIZ La réservation se fait gratuitement. Si le nom du domaine est enregistré pour vous, vous payez la modique somme de 49 euro / an. Homepage- et emailforwarding sont compris dans le prix ! (voyez plus loin dans ce courrier). S'il y a plusieurs demandes pour le même nom . alors ? Premier inscrit, premier servi. c'est comme au Lotto. Qui ne risque pas, ne gagne pas ! Inscrivez-vous à temps. les premiers inscrits ont plus de chances ! Vous trouvez tout sur http://yawadoo.com les possibilités chez Yawadoo.Com ont été largement étendues à partir du 15.4.2001 ! -- Vous pouvez connecter n'importe quel homepage à votre domaine sans frais supplémentaires. Si votre homepage s'appelle user.provider.be/votrenom... vous pouvez connecter cela pour le prix de l'enregistrement à un Votredomaine.com. Ceci est valable également pour votre adresse e-mail ! A partir de maintenant tout le courrier [EMAIL PROTECTED] atterrit automatiquement dans le box de votre [EMAIL PROTECTED] actuel. Important: vous pouvez distribuer le courrier vous-même selon ce qui se trouve devant le @. Plus d'info sur le faq de http://yawadoo.com N'attendez pas plus longtemps pour voir si votre nom est encore disponible sur http://yawadoo.com http://yawadoo.com est un agent officiel pour l'enregistrement de noms de domaines. Quelques avis et recommandations. * a.. Commencez à protéger votre marque maintenant. N'avez-vous pas encore enregistré le nom de votre entreprise ou de votre marque ? Demandez le nom de votre domaine avant qu'il soit utilisé par quelqu'un d'autre. Pensez également à l'enregistrement de votre nom de famille. b.. Etablissez une liste avec tous les noms que vous voulez faire enregistrer. Dans le nouveau système on emploie la formule : premier entré, premier servi . Pensez également aux autres langues. c.. Consultez régulièrement le site de http://yawadoo.com Si vous avez un nom original que vous voulez enregistrer, il faut vous hâter. Vous pouvez réserver dès maintenant sur http://yawadoo.com Sincères salutations Peter Striegel dns-master yawadoo.com email: [EMAIL PROTECTED] yawadoo.com fait usage du OPT-OUT-Register où vous pouvez signaler que vous ne voulez plus recevoir de courrier non souhaité. Etabli selon les directives européennes . Informations et inscriptions sur http://opt-out.be xAddress-Sent:debian-security#lists.debian.org From:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lprng
On Fri, Dec 07, 2001 at 01:20:43PM +0200, Juha Jäykkä wrote: Most false positives are easily dismissed by knowing your setup which nessus does not. There are a couple of concering cases, though: This case of lprng: nessus only says it detects an lprng daemon, but NOT that it cannot tell the version number and just states what I describe in the beginning. Another is Trin00. It has this far detected three machines with Trin00. In one of them it most certainly is false since it claims to have found Windows version of Trin00 on an IRIX host... The other two cases, on the other hand give no hint of being falses. Does anyone know how reliable nessus is in detecting Trin00? Does it only check that port X is open, thus we have Trin00 there or does it really send some commands to the supposed Trin00 client/daemon and verify its existence from the reply? If nessus is not realiable, how can I check for it? You can see the code yourself. Just go to www.nessus.org and check out the plugins section. As you can see at http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/trinoo.nasl the trinoo test does send some UDP packet to the 27444 port and checks the result. If you find out a false positive in a given platform please report it to the nessus mailing list ([EMAIL PROTECTED]) Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: At 09.12.2001, Tim Haynes wrote: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? Plato -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:31:09AM +0200, Berend De Schouwer wrote: On Mon, 2001-12-10 at 08:19, mdevin wrote: On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: With ipchains you can make the following: ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? I'm not the original author, but I use ! interface too. Using ! destination would break ip forwarding. If your box is a gateway/router/firewall, it will drop all packets not destined for 192.168.0.1 (itself). OK, I see the problem. However, I think this only applies to ipchains where forwarded packets traverse the input and output chains. Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. All packets that need to be forwarded will traverse only the FORWARD chain and thus will not be checked against this rule. Thus on an iptables based firewall is there a preferance for which is the better approach? It is just that I came up with the rule above because it seemed more straightforward. In other words: If the packet came from interface eth0 and it is directed to localhost (INPUT chain) then it must have destination address 192.168.0.1 or we will DROP it. And you can make similar rules for every interface the firewall has. But I guess the same applies for the ipchains rule you use. It is just that the primary focus is on the IP address of each interface rather than the interface itself. The more I think about it, it doesn't seem to matter in iptables, unless you are putting your ethernet card into promiscuous mode or something. 'Cause then I guess you would see lots of packets not addressed to you coming in your INPUT chain. Then that iptables rule would DROP them all unless they were specifically addressed to you, whereas if I used your style of rule then other packets not addressed to my box directly would still get through. I don't know anything about ethernet cards in promiscuous mode - so not sure about this. What do you think? And thanks for highlighting that ipchains difference, I had forgotten about that. Since January, I have only been using iptables. Cheers. Mark. msg04734/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:54:31PM +, Tim Haynes wrote: Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. HTH. Cheers. Mark. msg04737/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 10:55:07PM +1000, mdevin wrote: On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. Hmmm. I don't know. On the test I ran in another part of this thread where I put a rule into my routing table to make packets destined for 192.168.0.2 get sent via loopback. Then made sshd bind to address 192.168.0.2. Then I was able to ssh into my box via the loopback interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was refused. All this was done while my iptables firewall was loaded and it does have the following in it: # Enable IP spoofing protection - turn on Source Address Verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 $f done However, the difference is that the packets that were being sent actually have destination address 192.168.0.2 and source address 192.168.0.2. And this didn't cause any problem for the return path filter. Whereas it might if it was trying to send back packets with a source of 127.0.0.1 and a destination of a.b.c.d. I can't test this at present since I don't have another computer I can network with this one for a couple of days. But a test could be run similar to the one I did earlier to check. No. On reading another post by Guido, this seems to do only what I have written in the comments above. ie. turn on Source Address Verification. It hasn't got anything to do with destination addresses. Cheers. Mark. msg04739/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:21:15PM +, Tim Haynes wrote: Ultimately, I want input forward to be drop-by-default. However, the `block' chain is meant to be good for both input forward scenarios; it has rules for stateful filtering and `open' things, then a drop log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. I think you are better to break your rules up into separate connection orientated rulesets. I will reply off list with more details as this is getting a little off topic now. Cheers. Mark. msg04740/pgp0.pgp Description: PGP signature
Re: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Petro writes: On Sat, Dec 08, 2001 at 01:40:06AM -0800, [EMAIL PROTECTED] wrote: After reading a previous thread about stopping services from listening on certains ports, I decided to investigate things a little further for my system. So, what I can figure out is that it seems that I have only the following daemons listening: postfix, sshd, cupsd, XF86_SVGA, portmap. I have only deliberately decided to run postfix, sshd and cupsd. Everything in /etc/inetd.conf is hashed out. In fact I renamed the file so that it is not accessed at all. Better just not to start inetd at all. man inetd and update-rc.d Once thing to keep in mind when turning off services is to use update-rc.d correctly. It's not a good idea to turn off services using update-rc.d -f remove because that completely removes the links for a package. If the links are completely removed, then when the package is upgraded the links will be restored and the service will start up again at the next reboot. The correct way to turn off a service is to remove all of the links except for one Kill link. That way the service won't start and won't be restarted when the service is upgraded. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8FPM2oayJfLoDSdIRAvxDAJwP23MMRJt5Wm2OehWKFDsgVkMQVgCdELOR EmhaF3/vOl5Z70foikd83ms= =1PVh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Greetings! At 09.12.2001, [EMAIL PROTECTED] wrote: [...] And thanks for all the replies. In fact I was most interested to hear that you could not make daemons listen on only one interface but you could make them bind to an IP address range. I guess that is what I achieved in my postfix main.cf file with the line: inet_interfaces = localhost If using the meta-daemon XINETD instead of INETD you can specify the interface (= bind) option where you can specify on which interface the service should listen only. See man xinetd.conf HTH Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research Development Division, WYAE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh and root
* Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. One could place a uid binary version of this there very easily: /usr/local/sbin/ls: cp /bin/bash ~h4x0r/r00t5h3ll chmod u+s ~h4x0r/r00t5h3ll rm /usr/local/sbin/bash exec /bin/ls $ARGS So, when doing this, only do it to accounts you trust very well and that are very well-guarded. It's best to only give group staff to (the person(s) who is/are root)'s user account(s). It is one step better than using root directly, though (IMO). This is also why you should specify full pathnames to anything you invoke as root =) good times, Vineet -- Satan laughs when # I disapprove of what you say, but I will we kill each other.# defend to the death your right to say it. Peace is the only way. # --Beatrice Hall, The Friends of Voltaire, 1906 msg04744/pgp0.pgp Description: PGP signature
Re: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:39:02AM -0800, Ted Cabeen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Petro writes: On Sat, Dec 08, 2001 at 01:40:06AM -0800, [EMAIL PROTECTED] wrote: After reading a previous thread about stopping services from listening on certains ports, I decided to investigate things a little further for my system. So, what I can figure out is that it seems that I have only the following daemons listening: postfix, sshd, cupsd, XF86_SVGA, portmap. I have only deliberately decided to run postfix, sshd and cupsd. Everything in /etc/inetd.conf is hashed out. In fact I renamed the file so that it is not accessed at all. Better just not to start inetd at all. man inetd and update-rc.d Once thing to keep in mind when turning off services is to use update-rc.d correctly. It's not a good idea to turn off services using update-rc.d -f remove because that completely removes the links for a package. If the links are completely removed, then when the package is upgraded the links will be restored and the service will start up again at the next reboot. The correct way to turn off a service is to remove all of the links except for one Kill link. That way the service won't start and won't be restarted when the service is upgraded. Thanks for that. I will change things so that the links are as you say. When you say: leave one kill link; Do you just leave the kill link in rc6.d or do you put a kill link in every one of rc1.d - rc6.d, or doesn't it matter so long as there is at least one. Thanks. Mark. msg04745/pgp0.pgp Description: PGP signature
Deducing key from encrypted original data
Hi, this is something I've been wondering for some time now: Is it possible (or at least much easier) to extract the encryption key if you both have the encrypted and original data? Dries PS. I know it isn't debian-related, but it's a good question anyway... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh and root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vineet Kumar [EMAIL PROTECTED] writes: * Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. That would indeed be a lot better than ssh'ing in as root. I believe the default setup doesn't even let you (or was that a configuration question?). It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. On my machine these come last by default(!) when I su user@frodo:~$ su Password: frodo:/home/user# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin frodo:/home/user# and they are not even there when logging in as root frodo login: root Password: [...] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. frodo:~# echo $PATH /usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 frodo:~# Besides, when r00t you use full pathnames, not? - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FUqCFsfyfWvjfZARAldtAJ47K/2STWf/fWny6AwLN2gC+k+VYwCcCQAH Bt1IvMKp58m/g2VDpQQFxoE= =CVXg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
thanks! [was Re: shutdown user and accountability]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf Meeuwissen [EMAIL PROTECTED] wrote: I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, Thanks to everyone who responded. I should have been a little clearer on the system setup. The machine in question consists of a main unit and a bunch of externally attached hard disks connected to a network. It has no monitor, keyboard (what Ctrl-Alt-Del?) and mouse. As I already feared, it is impossible to provide a shutdown account without giving up accountability. Some pointed out (correctly) that without physical security I didn't have accountability to begin with, but I was wondering whether I needed to sacrifice it even further. Some replies suggested I validate against a general database, e.g. for Winblows logon (that'd be just about the only viable alternative in my situation). That could be a nice approach, but one would have to be able to trust that database (and since it is not under my control ... btw, I hope it stays that way, win-DoS shudder ;-) The replies regarding journalling file systems reminded me of the fact that I still have to look into those (especially since we have annual thunderstorms occasionally knocking the power out). I liked the camera idea! If I get some time, I may give it a go. We have quite a few digital camera's around here and one on my machine wouldn't look like an obvious security measure. Finally, one reply mentioned that I would have the IP address logged right before the shutdown because people that want to shut down the machine have to ssh in. Shame on me for forgetting that. In the mean time, our network administrator seems to have seen the light and now requires a shutdown account so he can shut the machine down anytime he needs to. With that I can live, so I provided one where all he can do is shut the machine down. Should he choose to share the password, then that is his problem. So, I've added a user along the following line shutdown:x:1000:1000::/tmp:/usr/local/sbin/shutdown where /usr/local/sbin/shutdown (root.root 0755) looks like #! /bin/sh exec /usr/bin/sudo -K /sbin/halt and added the shutdown user to the users allowed to run /sbin/halt in my sudo setup. I liked this better than another setup they suggested at work (for a Solaris box) where they add a user as shutdown:x:0:0::/etc/shutdown:/etc/shutdown/shutdown with /etc/shutdown/shutdown (root.root 0744) looking like #! /bin/sh echo Do you want to shutdown now? (y or n): \c read yn if [ $yn = 'y' -o $yn = 'Y' ] ; then sync sync sync sleep 3 /usr/sbin/shutdown -i0 -g0 fi exit 0 I didn't see any obvious flaws in the above script, but I disliked the prompting and, what's more, the shutdown user has r00t privileges! Anyway, thanks to all the paranoid folks who responded. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FY+RFsfyfWvjfZARAl79AJ9dl/klAaeBF3dpm7IhUE1lG1FLXwCcC8EK udWwBZsyQAsDaVNVEpt3Yh0= =tMSt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: With ipchains you can make the following: ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? Please explain. Is it because you may later want to put your ethernet card into promiscuous mode and thus receive packets with any destination as if they were for you? My rule above would prevent this whereas your rule would not. Both rules would prevent the attacker trying to circumvent the sshd bound IP address restriction however. Can you explain why you choose your rule. Cheers. Mark. pgpGi2Wj4MGIX.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, 2001-12-10 at 08:19, mdevin wrote: On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: With ipchains you can make the following: ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? I'm not the original author, but I use ! interface too. Using ! destination would break ip forwarding. If your box is a gateway/router/firewall, it will drop all packets not destined for 192.168.0.1 (itself). Please explain. Is it because you may later want to put your ethernet card into promiscuous mode and thus receive packets with any destination as if they were for you? My rule above would prevent this whereas your rule would not. Both rules would prevent the attacker trying to circumvent the sshd bound IP address restriction however. Can you explain why you choose your rule. Cheers. Mark. -- Berend De Schouwer
Unidentified subject!
Concerne : Enregistrement des domaines *.INFO et .BIZ Ce courrier vous est envoyé par http://Yawadoo.com (enregistrement .INFO .BIZ .BE .COM ..ORG .NET ..DE) Agent agrée pour l'enregistrement de noms de domaines européens et étrangers. -- Cher internaute, Circulaire du 14/11/2001 concernant l'enregistrement des domaines ..INFO ..BIZ -- A partir de septembre les noms de domaines .INFO .BIZ sont disponibles ! -- Enfin on peut souscrire pour .INFO .BIZ Le domaine .INFO sera à l'avenir plus important que le .com. Actuellement il y a déjà plus d'1 million de demandes dans le monde. Inscrivez-vous à temps dés maintenant !. Début septembre toutes les demandes sont automatiquement délivrées. En fin septembre sera communiqué si vous avez obtenu un nom. INFO ou. BIZ La réservation se fait gratuitement. Si le nom du domaine est enregistré pour vous, vous payez la modique somme de 49 euro / an. Homepage- et emailforwarding sont compris dans le prix ! (voyez plus loin dans ce courrier). S'il y a plusieurs demandes pour le même nom . alors ? Premier inscrit, premier servi. c'est comme au Lotto. Qui ne risque pas, ne gagne pas ! Inscrivez-vous à temps. les premiers inscrits ont plus de chances ! Vous trouvez tout sur http://yawadoo.com les possibilités chez Yawadoo.Com ont été largement étendues à partir du 15.4.2001 ! -- Vous pouvez connecter n'importe quel homepage à votre domaine sans frais supplémentaires. Si votre homepage s'appelle user.provider.be/votrenom... vous pouvez connecter cela pour le prix de l'enregistrement à un Votredomaine.com. Ceci est valable également pour votre adresse e-mail ! A partir de maintenant tout le courrier [EMAIL PROTECTED] atterrit automatiquement dans le box de votre [EMAIL PROTECTED] actuel. Important: vous pouvez distribuer le courrier vous-même selon ce qui se trouve devant le @. Plus d'info sur le faq de http://yawadoo.com N'attendez pas plus longtemps pour voir si votre nom est encore disponible sur http://yawadoo.com http://yawadoo.com est un agent officiel pour l'enregistrement de noms de domaines. Quelques avis et recommandations. * a.. Commencez à protéger votre marque maintenant. N'avez-vous pas encore enregistré le nom de votre entreprise ou de votre marque ? Demandez le nom de votre domaine avant qu'il soit utilisé par quelqu'un d'autre. Pensez également à l'enregistrement de votre nom de famille. b.. Etablissez une liste avec tous les noms que vous voulez faire enregistrer. Dans le nouveau système on emploie la formule : premier entré, premier servi . Pensez également aux autres langues. c.. Consultez régulièrement le site de http://yawadoo.com Si vous avez un nom original que vous voulez enregistrer, il faut vous hâter. Vous pouvez réserver dès maintenant sur http://yawadoo.com Sincères salutations Peter Striegel dns-master yawadoo.com email: [EMAIL PROTECTED] yawadoo.com fait usage du OPT-OUT-Register où vous pouvez signaler que vous ne voulez plus recevoir de courrier non souhaité. Etabli selon les directives européennes . Informations et inscriptions sur http://opt-out.be xAddress-Sent:debian-security#lists.debian.org From:[EMAIL PROTECTED]
Re: Can a daemon listen only on some interfaces?
On Sat, Dec 08, 2001 at 03:54:21PM -0800, Mark Lanett wrote: Postfix is configurable as to which interfaces it listens to. So are samba, courier-imap, apache. The only problem is that each one has its own completely different kind of configuration file. Some of them are documented at the Debian Securing HOWTO (I will add some which appeared in this thread there too). Javi
Re: lprng
On Fri, Dec 07, 2001 at 01:20:43PM +0200, Juha Jäykkä wrote: Most false positives are easily dismissed by knowing your setup which nessus does not. There are a couple of concering cases, though: This case of lprng: nessus only says it detects an lprng daemon, but NOT that it cannot tell the version number and just states what I describe in the beginning. Another is Trin00. It has this far detected three machines with Trin00. In one of them it most certainly is false since it claims to have found Windows version of Trin00 on an IRIX host... The other two cases, on the other hand give no hint of being falses. Does anyone know how reliable nessus is in detecting Trin00? Does it only check that port X is open, thus we have Trin00 there or does it really send some commands to the supposed Trin00 client/daemon and verify its existence from the reply? If nessus is not realiable, how can I check for it? You can see the code yourself. Just go to www.nessus.org and check out the plugins section. As you can see at http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/trinoo.nasl the trinoo test does send some UDP packet to the 27444 port and checks the result. If you find out a false positive in a given platform please report it to the nessus mailing list (nessus@list.nessus.org) Regards Javi
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: At 09.12.2001, Tim Haynes wrote: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? Plato
Re: Fw: Can a daemon listen only on some interfaces?
Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night |
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:31:09AM +0200, Berend De Schouwer wrote: On Mon, 2001-12-10 at 08:19, mdevin wrote: On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: With ipchains you can make the following: ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? I'm not the original author, but I use ! interface too. Using ! destination would break ip forwarding. If your box is a gateway/router/firewall, it will drop all packets not destined for 192.168.0.1 (itself). OK, I see the problem. However, I think this only applies to ipchains where forwarded packets traverse the input and output chains. Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. All packets that need to be forwarded will traverse only the FORWARD chain and thus will not be checked against this rule. Thus on an iptables based firewall is there a preferance for which is the better approach? It is just that I came up with the rule above because it seemed more straightforward. In other words: If the packet came from interface eth0 and it is directed to localhost (INPUT chain) then it must have destination address 192.168.0.1 or we will DROP it. And you can make similar rules for every interface the firewall has. But I guess the same applies for the ipchains rule you use. It is just that the primary focus is on the IP address of each interface rather than the interface itself. The more I think about it, it doesn't seem to matter in iptables, unless you are putting your ethernet card into promiscuous mode or something. 'Cause then I guess you would see lots of packets not addressed to you coming in your INPUT chain. Then that iptables rule would DROP them all unless they were specifically addressed to you, whereas if I used your style of rule then other packets not addressed to my box directly would still get through. I don't know anything about ethernet cards in promiscuous mode - so not sure about this. What do you think? And thanks for highlighting that ipchains difference, I had forgotten about that. Since January, I have only been using iptables. Cheers. Mark. pgpfk8ar4ESTJ.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. Hmmm. I don't know. On the test I ran in another part of this thread where I put a rule into my routing table to make packets destined for 192.168.0.2 get sent via loopback. Then made sshd bind to address 192.168.0.2. Then I was able to ssh into my box via the loopback interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was refused. All this was done while my iptables firewall was loaded and it does have the following in it: # Enable IP spoofing protection - turn on Source Address Verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 $f done However, the difference is that the packets that were being sent actually have destination address 192.168.0.2 and source address 192.168.0.2. And this didn't cause any problem for the return path filter. Whereas it might if it was trying to send back packets with a source of 127.0.0.1 and a destination of a.b.c.d. I can't test this at present since I don't have another computer I can network with this one for a couple of days. But a test could be run similar to the one I did earlier to check. Cheers. Mark. pgpjH6YLjXNpS.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:54:31PM +, Tim Haynes wrote: Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. HTH. Cheers. Mark. pgpReAk6ndWZ9.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
mdevin [EMAIL PROTECTED] writes: [snip firewall overview] how come packets still seem to get dropped when being forwarded between interfaces? I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Righty. That's much as I expected. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. Ultimately, I want input forward to be drop-by-default. However, the `block' chain is meant to be good for both input forward scenarios; it has rules for stateful filtering and `open' things, then a drop log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. ~Tim -- A spark of life |[EMAIL PROTECTED] On a wire from heaven |http://spodzone.org.uk/
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:21:15PM +, Tim Haynes wrote: Ultimately, I want input forward to be drop-by-default. However, the `block' chain is meant to be good for both input forward scenarios; it has rules for stateful filtering and `open' things, then a drop log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. I think you are better to break your rules up into separate connection orientated rulesets. I will reply off list with more details as this is getting a little off topic now. Cheers. Mark. pgpEbZPBkAy9n.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Henrique de Moraes Holschuh writ es: On Sun, 09 Dec 2001, Guido Hennecke wrote: At 09.12.2001, Henrique de Moraes Holschuh wrote: On Sun, 09 Dec 2001, Guido Hennecke wrote: 127.0.0.1 Gateway your official ip address Interface his externel interface he can reach your service bound to 127.0.0.1. And this without activating ip_forward on your computer! Is this true even if the policy of the forward chain (for ipchains) is set to deny ? (and the equivalent, for iptables) ? Those packets did not go throught the forwards chain. For local interfaces no routing is needed. If they came over the network, they should have. That is a broken behaviour (breaks principle of less surprise, at the very least). Well, ipmasq needs an update to trash anything incoming and outgoing from !lo with a destination of 127.0.0.1/8 then. It already does this. Check out /etc/ipmasq/rules/I15lospoof.def. It also blocks and logs packets coming from external interfaces claiming to be from an internal address in the /etc/ipmasq/rules/I70masq.def file. The ipmasq firewall is very careful about blocking these sorts of attacks. The only change I make to its default operation is to lock down the external interface. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8FO+BoayJfLoDSdIRAgxhAKCYYeJrtaUAtbbeGowq1hBE2GyaCACgkKhf gmdv3uF0kXlJkN2V/gukl9k= =bm4W -END PGP SIGNATURE-
Re: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Petro writes: On Sat, Dec 08, 2001 at 01:40:06AM -0800, [EMAIL PROTECTED] wrote: After reading a previous thread about stopping services from listening on certains ports, I decided to investigate things a little further for my system. So, what I can figure out is that it seems that I have only the following daemons listening: postfix, sshd, cupsd, XF86_SVGA, portmap. I have only deliberately decided to run postfix, sshd and cupsd. Everything in /etc/inetd.conf is hashed out. In fact I renamed the file so that it is not accessed at all. Better just not to start inetd at all. man inetd and update-rc.d Once thing to keep in mind when turning off services is to use update-rc.d correctly. It's not a good idea to turn off services using update-rc.d -f remove because that completely removes the links for a package. If the links are completely removed, then when the package is upgraded the links will be restored and the service will start up again at the next reboot. The correct way to turn off a service is to remove all of the links except for one Kill link. That way the service won't start and won't be restarted when the service is upgraded. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8FPM2oayJfLoDSdIRAvxDAJwP23MMRJt5Wm2OehWKFDsgVkMQVgCdELOR EmhaF3/vOl5Z70foikd83ms= =1PVh -END PGP SIGNATURE-
Re: Fw: Can a daemon listen only on some interfaces?
Greetings! At 09.12.2001, [EMAIL PROTECTED] wrote: [...] And thanks for all the replies. In fact I was most interested to hear that you could not make daemons listen on only one interface but you could make them bind to an IP address range. I guess that is what I achieved in my postfix main.cf file with the line: inet_interfaces = localhost If using the meta-daemon XINETD instead of INETD you can specify the interface (= bind) option where you can specify on which interface the service should listen only. See man xinetd.conf HTH Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research Development Division, WYAE
Re: ssh and root
* Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. One could place a uid binary version of this there very easily: /usr/local/sbin/ls: cp /bin/bash ~h4x0r/r00t5h3ll chmod u+s ~h4x0r/r00t5h3ll rm /usr/local/sbin/bash exec /bin/ls $ARGS So, when doing this, only do it to accounts you trust very well and that are very well-guarded. It's best to only give group staff to (the person(s) who is/are root)'s user account(s). It is one step better than using root directly, though (IMO). This is also why you should specify full pathnames to anything you invoke as root =) good times, Vineet -- Satan laughs when # I disapprove of what you say, but I will we kill each other.# defend to the death your right to say it. Peace is the only way. # --Beatrice Hall, The Friends of Voltaire, 1906 pgptUlrdr29IT.pgp Description: PGP signature
Re: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:39:02AM -0800, Ted Cabeen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Petro writes: On Sat, Dec 08, 2001 at 01:40:06AM -0800, [EMAIL PROTECTED] wrote: After reading a previous thread about stopping services from listening on certains ports, I decided to investigate things a little further for my system. So, what I can figure out is that it seems that I have only the following daemons listening: postfix, sshd, cupsd, XF86_SVGA, portmap. I have only deliberately decided to run postfix, sshd and cupsd. Everything in /etc/inetd.conf is hashed out. In fact I renamed the file so that it is not accessed at all. Better just not to start inetd at all. man inetd and update-rc.d Once thing to keep in mind when turning off services is to use update-rc.d correctly. It's not a good idea to turn off services using update-rc.d -f remove because that completely removes the links for a package. If the links are completely removed, then when the package is upgraded the links will be restored and the service will start up again at the next reboot. The correct way to turn off a service is to remove all of the links except for one Kill link. That way the service won't start and won't be restarted when the service is upgraded. Thanks for that. I will change things so that the links are as you say. When you say: leave one kill link; Do you just leave the kill link in rc6.d or do you put a kill link in every one of rc1.d - rc6.d, or doesn't it matter so long as there is at least one. Thanks. Mark. pgpPhO0n1JU7R.pgp Description: PGP signature
Re: ssh and root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vineet Kumar [EMAIL PROTECTED] writes: * Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. That would indeed be a lot better than ssh'ing in as root. I believe the default setup doesn't even let you (or was that a configuration question?). It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. On my machine these come last by default(!) when I su [EMAIL PROTECTED]:~$ su Password: frodo:/home/user# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin frodo:/home/user# and they are not even there when logging in as root frodo login: root Password: [...] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. frodo:~# echo $PATH /usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 frodo:~# Besides, when r00t you use full pathnames, not? - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FUqCFsfyfWvjfZARAldtAJ47K/2STWf/fWny6AwLN2gC+k+VYwCcCQAH Bt1IvMKp58m/g2VDpQQFxoE= =CVXg -END PGP SIGNATURE-
Deducing key from encrypted original data
Hi, this is something I've been wondering for some time now: Is it possible (or at least much easier) to extract the encryption key if you both have the encrypted and original data? Dries PS. I know it isn't debian-related, but it's a good question anyway...
Re: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], mdevin writes: Once thing to keep in mind when turning off services is to use update-rc.= d=20 correctly. It's not a good idea to turn off services using=20 update-rc.d -f remove because that completely removes the links for a= =20 package. If the links are completely removed, then when the package is= =20 upgraded the links will be restored and the service will start up again a= t=20 the next reboot. The correct way to turn off a service is to remove all = of=20 the links except for one Kill link. That way the service won't start and= =20 won't be restarted when the service is upgraded. Thanks for that. I will change things so that the links are as you say. When you say: leave one kill link; Do you just leave the kill link in rc6.d or do you put a kill link in every one of rc1.d - rc6.d, or doesn't it matter so long as there is at least one. It doesn't matter as long as there is at least one. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8FV2EoayJfLoDSdIRAps5AKCLhePAPTd+l2nyT8Bp5xVZk88hkACgmdDS RuSPmuw9I0RtEXwDUfdcRxU= =Gy0E -END PGP SIGNATURE-
Re: Deducing key from encrypted original data
On Tue, Dec 11, 2001 at 01:00:40AM +0100, Dries Kimpe wrote: Hi, this is something I've been wondering for some time now: Is it possible (or at least much easier) to extract the encryption key if you both have the encrypted and original data? Dries PS. I know it isn't debian-related, but it's a good question anyway... It's called a known-plaintext attack. The answer depends on the encryption scheme, but one of the properties of a good scheme is that having a plaintext won't help you recover the key. In fact, this is an essential requirement for public-key cryptography, because the enemy can generate as much encrypted+plaintext data as they like. ...unless you are from Hollywood - in which case a good encryption scheme is one that can be cracked by having lots of digits flash up on the screen, and gradually have individual digits lock into the correct key. Andrew -- Andrew Bolt, [EMAIL PROTECTED] 110 Fulbourn Road, Cambridge, CB1 9NJ, ENGLAND, +44 1223 400650
thanks! [was Re: shutdown user and accountability]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf Meeuwissen [EMAIL PROTECTED] wrote: I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, Thanks to everyone who responded. I should have been a little clearer on the system setup. The machine in question consists of a main unit and a bunch of externally attached hard disks connected to a network. It has no monitor, keyboard (what Ctrl-Alt-Del?) and mouse. As I already feared, it is impossible to provide a shutdown account without giving up accountability. Some pointed out (correctly) that without physical security I didn't have accountability to begin with, but I was wondering whether I needed to sacrifice it even further. Some replies suggested I validate against a general database, e.g. for Winblows logon (that'd be just about the only viable alternative in my situation). That could be a nice approach, but one would have to be able to trust that database (and since it is not under my control ... btw, I hope it stays that way, win-DoS shudder ;-) The replies regarding journalling file systems reminded me of the fact that I still have to look into those (especially since we have annual thunderstorms occasionally knocking the power out). I liked the camera idea! If I get some time, I may give it a go. We have quite a few digital camera's around here and one on my machine wouldn't look like an obvious security measure. Finally, one reply mentioned that I would have the IP address logged right before the shutdown because people that want to shut down the machine have to ssh in. Shame on me for forgetting that. In the mean time, our network administrator seems to have seen the light and now requires a shutdown account so he can shut the machine down anytime he needs to. With that I can live, so I provided one where all he can do is shut the machine down. Should he choose to share the password, then that is his problem. So, I've added a user along the following line shutdown:x:1000:1000::/tmp:/usr/local/sbin/shutdown where /usr/local/sbin/shutdown (root.root 0755) looks like #! /bin/sh exec /usr/bin/sudo -K /sbin/halt and added the shutdown user to the users allowed to run /sbin/halt in my sudo setup. I liked this better than another setup they suggested at work (for a Solaris box) where they add a user as shutdown:x:0:0::/etc/shutdown:/etc/shutdown/shutdown with /etc/shutdown/shutdown (root.root 0744) looking like #! /bin/sh echo Do you want to shutdown now? (y or n): \c read yn if [ $yn = 'y' -o $yn = 'Y' ] ; then sync sync sync sleep 3 /usr/sbin/shutdown -i0 -g0 fi exit 0 I didn't see any obvious flaws in the above script, but I disliked the prompting and, what's more, the shutdown user has r00t privileges! Anyway, thanks to all the paranoid folks who responded. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FY+RFsfyfWvjfZARAl79AJ9dl/klAaeBF3dpm7IhUE1lG1FLXwCcC8EK udWwBZsyQAsDaVNVEpt3Yh0= =tMSt -END PGP SIGNATURE-
