Re: activating an unconfigured interface using /etc/network/interfaces...?
Hello Matthew, On Wed, Jul 23, 2003 at 10:34:32PM -0700, Matthew Whitworth wrote: I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string ifconfig eth1 0.0.0.0 up, but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. I use the following syntax, to bring up a MiniPCI wireless network interface with no address, so it can be added to a bridge. Different purpose but same idea, I think. auto wlan0 iface wlan0 inet static address 0.0.0.0 netmask 255.255.255.254 Nothing actually gets added to the routing table, AFAICT, but it's necessary to specify a netmask to stop ifupdown from complaining. HTH, - Keegan pgp0.pgp Description: PGP signature
Re: activating an unconfigured interface using /etc/network/interfaces...?
Hello Matthew, On Wed, Jul 23, 2003 at 10:34:32PM -0700, Matthew Whitworth wrote: I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string ifconfig eth1 0.0.0.0 up, but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. I use the following syntax, to bring up a MiniPCI wireless network interface with no address, so it can be added to a bridge. Different purpose but same idea, I think. auto wlan0 iface wlan0 inet static address 0.0.0.0 netmask 255.255.255.254 Nothing actually gets added to the routing table, AFAICT, but it's necessary to specify a netmask to stop ifupdown from complaining. HTH, - Keegan pgpo2dfsYSj2M.pgp Description: PGP signature
Re: Could sudo be an security issue?
On Wednesday 14 May 2003 04:17 pm, Stewart James wrote: Hi all, Hello Stewart, My manager just came in asking questions about sudo. We use sudo here as a replacement for hacing to know root passwords - in general there are around 5 of us who need root access to the machines we maintain. we typically have just fallen back to a ALL=ALL for ourselves so we can just prepend sudo to any command we need executed as root. Now in his mind this is removing a level of security. If someone manages to get my password, they also can gain access to root via sudo. IN an environment where I have 25+ machines, different passwords for all machines is not that workable. What are other peoples thoughts on this? Where have I gone wrong in implementation? What would be your recommendations in this case? Well, as you probably guessed, this is a big can of worms. You are using sudo the same way I am, and I believe it's proper. Some people might consider this to be removing a 'layer' of security, sure - it essentially makes it so any admin's password is just as good as the root password, to an intruder. Think about a scenario in which this would actually make a difference. If someone has cracked any admin's password, on a normal /etc/shadow-based system, why couldn't they also crack root? Sure, perhaps one could be sniffed, but that would point to another problem involving a lack of encryption. One might argue that root should have a 'harder to crack' password, but I would reply that administrators should be equally protected. So, basically, if you would really trust the integrity of your current system after some intruder has stolen an administrator password, then yes, using sudo is probably a bad idea. Just go back to su, which has a seperate set of risks involving sharing the single root password. If you (or your manager) really want multi-layered theoretical security, you should be taking advantage of SE Linux or something similar. (Cue Russell Coker explaining how well it solves this problem ... :) ) Having a second password for root might be an 'additional layer of security,' but IMHO it's a pretty weak one. - Keegan
Re: Kernel 2.4.21-rc2 still vulnarable or am I doing something wrong?
On Tuesday 13 May 2003 06:11 am, Peter Holm wrote: Did I something wrong? Or is this exploit, if not for a root shell, still good for a local DOS? Yes, any user on any system may use all of the available CPU time unless the administrator has placed limits on them doing so. Presumably the exploit is trying to do what it does, over and over, continually failing. Any software could do any pointless calculation or operation over and over for the same effect. - Keegan
Re: Apt-get only security patches
On Thursday 08 May 2003 03:30 am, Rudolph van Graan wrote: Hi, Rolf Kutz wrote: apt-listchanges. It displays the new changelog entries from the debs before installing them, but has to download them first, so no bandwidth saving. This is almost exactly what I looked for - it removes the blindly trusting apt-get that was my problem in the first place. At lease I can now decide if the change warrants installation to my machine. Strange thing is that I haven't seen this package before. You're still trusting that what the changelog says is true, actually, but with security.debian.org, that's pretty authoritative. Not all packages will always list all changes - it's up to the maintainer to remember what was modified. Also, sometimes changes are listed that were not actually made. For example, recently a package was marked as IPv6-enabled, when the actual code had not yet been implemented upstream. There is a significant level of trust involved with using apt-get (or any code from the Internet) at all. It's not a problem for me, or apparently many people, but the only way to really know what's changing on your system is to read the source code and compile it yourself. (Make sure you read the compiler code, too. :) - Keegan
Re: iptables with no module support?
On Wednesday 23 April 2003 07:17 am, David Ramsden wrote: I'm building a 'secure' server. I downloaded the 2.4.20 kernel source from kernel.org and patched with grsecurity (latest patch). I also disabled loadable modules or any module support in the kernel for added security - So everything is compiled in to the kernel. grsecurity - good. You should know that the actual benefit of not allowing modules is highly questionable, since there are other means of inserting kernel code. However, iptables won't work, saying it can't initialise iptables table 'filter' and saying do you need to insmod?. So does iptables require module support? I don't want to use modules though! :-) Surely the Netfilter people would have thought of this? iptables works fine compiled. You managed to avoid compiling in the actual iptables code when you built your kernel. Make sure you're defining CONFIG_IP_NF_IPTABLES and any related options you want, in your kernel configuration. - Keegan
Re: iptables with no module support?
Sorry for the duplicate. I seem to be about 3 hours behind on email delivery. - Keegan
Re: is iptables enough?
On Wednesday 19 March 2003 01:07 pm, Ian Garrison wrote: Imo iptables is a reasonably good stateful firewall and is fine in most cases. However, a very wise person once said that the ideal setup is to layer more than one implementation of packet filter and firewall between the wild and a host/network you wish to protect. Ideally implementations on diverse platforms. Just remember, that when you do this, you are introducing an additional point of failure for each device in the chain. Some people like to keep these at a minimum, especially in the 'revenue-generating' environments you describe. - Keegan
Re: is iptables enough?
Hello, On Wednesday 19 March 2003 11:44 am, Jones wrote: I am planning to replace a (dead) Windows 2000 computer that was used as a web server and email server with a Debian Linux solution. This machine is connected to the net via DSL and would run apache and exim/qpopper and sshd. Everything else would be turned off. It is a small church and their current site is not very busy, but she says they do get a lot of email. I would imagine that their 'lot of email' will be quite negligible to whatever server you can come up with. Am I right in assuming that iptabes is enough as a firewall solution and that I would not need to buy any additional software. That is what I understand from my past experience with Debian/iptables as a server and from the files at debian.org security howto at (http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) Absolutely. Dedicated firewall hardware in such a small installation would seem ridiculously paranoid, to me. I'm not even sure what additional software you could consider. On a less related note, what hardware config would you recommend for such a system? She has a number of machines that I could choose from. Most of them are 1.x Ghz Pentium systems with 256MB RAM and 10 GB IDE hard drives. After increasing the RAM to 512MB, I think this should more than adequate for a system doing nothing but HTTP and SMTP/POP requests. I'd say even without any additional RAM, you will be home free. Doubling it will make it fly, but I strongly doubt you will see any noticeable swapping at 256. The actual requirements of the installation you're describing are ridiculously small. Good luck, and happy Debian-ing! - Keegan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Is it so easy to break into an NIS?
On Tuesday 18 March 2003 04:13 pm, Haim Ashkenazi wrote: Hi Hello, A friend just asked me this question and I got curious. say I'm equipped with a linux laptop and some knowledge, I can walk into a company that uses NIS, find out the settings (NISDOMAIN, free ip address, etc...) and join their domain. now I can login as root on my computer, su to any user and see/change/delete his files. is it that easy? Yes, quite. NIS uses no authentication whatsoever. of-course, administrators should protect their mounts with netgroups permissions, and users should protect their important files with encryption, but how many of these you see? Not many. The problems you describe above are well-known. any ideas? suggestions? Use LDAP and Kerberos instead of NIS. They are equally or better supported in every situation I know of. - Keegan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
