Re: help needed with firewall logging ..please
On Mon, Feb 09, 2004 at 08:21:15PM -0800, Jeff wrote: > suhail, 2004-Feb-09 15:15 -0800: [snip] > > Now how do i actually find out if the packets are being dropped. > > i.e where shud I chk my system log files to see the dropped packets > > ... I mean which file is it n under which dir .. > > The logging done as shown above goes to syslog. I use syslog-ng and > filter the firewall log messages into a separate file. Look in /var/log/messages. -- Michael Wood <[EMAIL PROTECTED]>
Re: help needed with firewall logging ..please
On Mon, Feb 09, 2004 at 08:21:15PM -0800, Jeff wrote: > suhail, 2004-Feb-09 15:15 -0800: [snip] > > Now how do i actually find out if the packets are being dropped. > > i.e where shud I chk my system log files to see the dropped packets > > ... I mean which file is it n under which dir .. > > The logging done as shown above goes to syslog. I use syslog-ng and > filter the firewall log messages into a separate file. Look in /var/log/messages. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sniffing SSH and HTTPS
On Tue, Aug 28, 2001 at 05:57:39PM -0600, Hubert Chan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >>>>> "Richard" == Richard <[EMAIL PROTECTED]> writes: > > [...] > > Richard> There also an analasis of the ssh packetstream > Richard> revealing the number of chars in the passwd. > > Small clarification: this may reveal the number of characters > in any password that you type _within_ the ssh session. This > does not affect the password that you use to initially log in, > as the whole password is sent in one packet. indeed. > Of course, the attacker would need to know that you are typing > in a password at that time. Ahhh, but this is quite easily guessable, since for most stuff you type, the server echos it. For passwords, it doesn't. i.e. just watch the SSH session, and when you see packets going to the server that aren't being echoed you know the person is typing a password and you can count the characters. > Richard> Attacks can still be done when the fingerprint is > Richard> unkown (e.g. first connect to the box) > > Yes, and to answer the OP's second question (how to make ssh > secure), copy the server's public key over a known secure > channel (e.g. if you're at work, get the admin to stick it on > a floppy for you), or get the fingerprint over a known secure > channel (e.g. phone the admin and ask for the fingerprint). And make SSH refuse to connect if it doesn't have the server in /etc/ssh/known_hosts. > Richard> or brute-force on fingerprint / rsa / dsa. > > And if you manage to brute-force the fingerprint/rsa/dsa, > we've got problems. :) The problem with man in the middle attacks is that people far too easily click on "Yes" when asked to accept a key that has changed (or type in "yes" when asked a similar question by SSH.) i.e. you should make sure you copy the relevant keys over a secure channel (as mentioned above) and then make sure your client is configured not to work if it doesn't have the server's key already. This doesn't work when you want to connect to some arbitrary "secure" web site, though. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: none
Unless you are actually using NFS, uninstall all NFS related stuff. If you are using NFS, make sure your machine is up to date. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mutt & tmp files
On Thu, Nov 15, 2001 at 10:17:39PM -0800, Wade Richards wrote: [snip] > Some security is better than no security. More security is > better than less security. If you find a security flaw in a > system, you should try to fix that flaw, even if the system is > not otherwise perfect. > [snip] > Also, what makes you thing root "knows what he's doing?" I > suspect that many people with the "root" password could not > install a tty sniffer or any other spying tool unless they > could type "apt-get install ttysniffer". I agree with the above, but: Package: ttysnoop Priority: optional Section: admin Installed-Size: 116 Maintainer: Paul Haggart <[EMAIL PROTECTED]> Architecture: i386 Version: 0.12c-7 Depends: libc6 (>= 2.1) Filename: dists/potato/main/binary-i386/admin/ttysnoop_0.12c-7.deb Size: 13430 MD5sum: c8d903ea4a5e399a19eb1439e8eb01d7 Description: TTY Snoop - allows you to spy on telnet+serial connections TTYSnoop allows you to snoop on login tty's through another tty-device or pseudo-tty. The snoop-tty becomes a 'clone' of the original tty, redirecting both input and output from/to it. :) -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a daemon listen only on some interfaces?
Hi On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: [snip] > 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. Commenting everything out should be sufficient. > The only ones I didn't know about in this list are portmap and > XF86_SVGA. Firstly, I can't seem to find the config file for > X where you set the --nolisten parameter - but I have not > unset this at any stage and I thought Debian did this by Make sure your /etc/X11/xinit/xserverrc contains something like this: #!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp > default. Secondly, I guess everyone needs portmap it seems, > so I can't turn this off or some things won't work. Someone > please educate me here. No. You do not need portmap unless you're using NFS or something like that. (i.e. SUN RPC services.) portmap is started by /etc/init.d/portmap when your machine boots. Disable it. (Why was portmap part of net-base to begin with?) It you're using testing/unstable, portmap is in it's own package (called portmap) and you should be able to uninstall it. > So my question is: > Is there some way to make certain daemons, (say postfix) > listen only on some interfaces? For example, I have > everything firewalled from outside, so I really only need > postfix to listen on the loopback interface for local > connections. Is this possible? It's technically possible, but this depends on if the particular daemon has support for this. Postfix does. Just put a line like this in main.conf: inet_interfaces = localhost > Then netstat -ln might show something like: > tcp0 0 0.0.0.0:25 127.0.0.1:* LISTEN [snip] Well, not quite :) Here's what it looks like: Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.1:250.0.0.0:* LISTEN I have no idea if cups supports binding to a particular interface, but the documentation should tell you. If you can't figure out how to do it or it's not possible without modifying the source, you should use ipchains/iptables to restrict access to the port it uses. I hope this helps. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a daemon listen only on some interfaces?
On Sat, Dec 08, 2001 at 08:09:50PM +0100, Guido Hennecke wrote: > At 08.12.2001, Michael Wood wrote: > > On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: > [...] > > > So my question is: > > > Is there some way to make certain daemons, (say postfix) > > > listen only on some interfaces? For example, I have > > > everything firewalled from outside, so I really only need > > > postfix to listen on the loopback interface for local > > > connections. Is this possible? > > It's technically possible, but this depends on if the particular > > daemon has support for this. Postfix does. > > It is a little bit different on Linux: > > It is not possible to configure a deamon to listen on an > interface only. It is only possible to bind it to an ip > address. That's splitting hairs ;) > The problem on linux is, that all local ip addresses are > reachable over all local interfaces. The only problem is the > routing and that depends on your infrastructure. > > But it is posible to use a packetfilter and configure it, that > packets for an interface must come in over the target > interface. Indeed. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Exim mail
On Sat, Dec 15, 2001 at 10:53:13AM -0500, Brian P. Flaherty wrote: > Josh <[EMAIL PROTECTED]> writes: > > > hmmm, im a bit of a newbie here, but how do you bind a > > daemon, eg telnetd to a certain nic? > > Try running xinetd, if you aren't already. In each service > block, you can use the 'bind' option, which ties the service > to a NIC's IP address. Someone please correct me if I am > wrong, but I think this effectively keeps the service from > listening on other interfaces. You should still firewall the port on the interfaces you don't want it to listen on, since the above is not sufficient to block connections when you have other people on the same subnet as you. There was a thread on one of the Debian lists a week or two ago (probably this list) with a subject something like "Can a daemon listen on only one interface?" where this was discussed. Someone (can't remember his name) pointed out that the above is insufficient. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secure 2.4.x kernel
> could explain it, in laymens terms, was to describe someone walking > up to her house and jiggling the locks and trying all the windows to > find a weakness or a kink in the armour so that they could get > inside to either do "bad things" like use the house or allow others to > come by and party... Her response: "Thats illegal, how come if > someone try's to get into your computer, they aren't arrested.". > Hmmm... Mom has a good point. > > I think the bottom line is that we'll never have 100% security until > there are laws that protect the break-in's and hacking that occurs. > Still laws... not crappy little wrist slapping type laws. > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Funky Arp Stuff
On Sun, Jan 06, 2002 at 01:52:45PM -0500, Phillip Hofmeister wrote: > My computer is rambling on over eth0 (External interface) > about a bunch of ARP request. Any Idea what could cause it? [snip] 20:50:05.245819 arp who-has 10.67.178.85 tell 10.67.178.1 20:50:05.367348 arp who-has 66.188.34.36 tell 66.188.32.1 20:50:05.418712 arp who-has 10.67.178.125 tell 10.67.178.1 20:50:05.419229 arp who-has 10.67.178.12 tell 10.67.178.1 20:50:05.427456 arp who-has 10.67.178.123 tell 10.67.178.1 20:50:05.453245 arp who-has 10.67.178.115 tell 10.67.178.1 20:50:05.464775 arp who-has 10.67.178.37 tell 10.67.178.1 20:50:05.465226 arp who-has 10.67.178.68 tell 10.67.178.1 20:50:05.488555 arp who-has 10.67.178.101 tell 10.67.178.1 20:50:05.489197 arp who-has 10.67.178.44 tell 10.67.178.1 20:50:05.489659 arp who-has 10.67.178.93 tell 10.67.178.1 20:50:05.556405 arp who-has 10.67.178.40 tell 10.67.178.1 20:50:05.578308 arp who-has 10.67.178.110 tell 10.67.178.1 20:50:05.641715 arp who-has 24.247.174.229 tell 24.247.174.1 20:50:05.696083 arp who-has 10.67.178.67 tell 10.67.178.1 [snip] You have a machine on your network with IP address 10.67.178.1 trying to talk to other machines with IP addresses in the range 10.67.178.x, which appear not to exist. You also have a machine with the IP address 66.188.32.1 and another with the IP address 24.247.174.1. 10.67.178.1 is most likely misconfigured. The other two resolve, so maybe they're OK, but they didn't get ARP replies, according to your packet capture. Is your machine connected to the 'net via DSL or cable or something? -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: [snip] > > Debian being what it is, are there any reasons why the > > debian bind package should not be chroot as the default > > instalation? > > RTFM. That is: > >http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind > > :) [snip] The above link contains the following: FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified. My opinion is that things that need to be writable should be owned by the user that runs named, but everything else should be owned by root. i.e. secondary zones etc., should be owned by the user that runs named. If you're doing dynamic DNS, the primary zones will also need to be writable. named.conf (and primary zones if you're not doing dynamic DNS) should be owned by root and not writable by named. This way, if there's a bind exploit, an attacker can't corrupt your zone files or config file (except for the secondary zones.) Of course, they may still be able to make the DNS server serve incorrect information, but at least it's another hurdle for them to jump over. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to create MD5 passwords
On Thu, Jan 24, 2002 at 08:56:56AM +0100, Rainer Sigl wrote: > Hi everyone, > please can me tell somebody how to make MD5 passwords in order > to supply it to ftppasswd file? You just need to call the standard crypt() function with the apropriate arguments. You can use perl or python or C or whatever to do it. e.g.: $ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> import random >>> import crypt >>> saltchars = string.uppercase + string.lowercase + string.digits + "./" >>> s = [] >>> for i in range(8): ... s.append(random.choice(saltchars)) ... >>> salt = "$1$" + string.join(s, "") >>> passwd = "Password" >>> print crypt.crypt(passwd, salt) $1$e6TSyRDd$OcJO4kuY0I/mLED6n.tNi1 -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with chrooting bind 9.2.0
On Wed, Feb 13, 2002 at 11:12:36PM +0100, Marcus Frings wrote: > Wednesday, February 13, 2002, 9:16:48 PM, Reagan Blundell wrote: > > > Feb 13 17:04:40 iridium named[1525]: none:0: open: /etc/bind/rndc.key: \ > > file not found > > Its looking for the rndc.key file in /etc/bind/ which would be > > /chroot/named/etc/bind > > You have it in /chroot/named/etc - hence it can't find it. > > Well, I tried 3 ways: > > 1) copying it back to the real /etc/bind This will not work, because named can't see the real /etc/bind when it's chrooted. > 2) copying it to /chroot/named/etc/bind i.e. /chroot/named/etc/bind is a directory containing the file rndc.key? This should work. What do the logs look like now? > 3) using symbolic links from the chroot jail to /etc/bind This won't work for the same reason as 1. -- Michael Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sniffing SSH and HTTPS
On Tue, Aug 28, 2001 at 05:57:39PM -0600, Hubert Chan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >>>>> "Richard" == Richard <[EMAIL PROTECTED]> writes: > > [...] > > Richard> There also an analasis of the ssh packetstream > Richard> revealing the number of chars in the passwd. > > Small clarification: this may reveal the number of characters > in any password that you type _within_ the ssh session. This > does not affect the password that you use to initially log in, > as the whole password is sent in one packet. indeed. > Of course, the attacker would need to know that you are typing > in a password at that time. Ahhh, but this is quite easily guessable, since for most stuff you type, the server echos it. For passwords, it doesn't. i.e. just watch the SSH session, and when you see packets going to the server that aren't being echoed you know the person is typing a password and you can count the characters. > Richard> Attacks can still be done when the fingerprint is > Richard> unkown (e.g. first connect to the box) > > Yes, and to answer the OP's second question (how to make ssh > secure), copy the server's public key over a known secure > channel (e.g. if you're at work, get the admin to stick it on > a floppy for you), or get the fingerprint over a known secure > channel (e.g. phone the admin and ask for the fingerprint). And make SSH refuse to connect if it doesn't have the server in /etc/ssh/known_hosts. > Richard> or brute-force on fingerprint / rsa / dsa. > > And if you manage to brute-force the fingerprint/rsa/dsa, > we've got problems. :) The problem with man in the middle attacks is that people far too easily click on "Yes" when asked to accept a key that has changed (or type in "yes" when asked a similar question by SSH.) i.e. you should make sure you copy the relevant keys over a secure channel (as mentioned above) and then make sure your client is configured not to work if it doesn't have the server's key already. This doesn't work when you want to connect to some arbitrary "secure" web site, though. -- Michael Wood <[EMAIL PROTECTED]>
Re: none
Unless you are actually using NFS, uninstall all NFS related stuff. If you are using NFS, make sure your machine is up to date. -- Michael Wood <[EMAIL PROTECTED]>
Re: Mutt & tmp files
On Thu, Nov 15, 2001 at 10:17:39PM -0800, Wade Richards wrote: [snip] > Some security is better than no security. More security is > better than less security. If you find a security flaw in a > system, you should try to fix that flaw, even if the system is > not otherwise perfect. > [snip] > Also, what makes you thing root "knows what he's doing?" I > suspect that many people with the "root" password could not > install a tty sniffer or any other spying tool unless they > could type "apt-get install ttysniffer". I agree with the above, but: Package: ttysnoop Priority: optional Section: admin Installed-Size: 116 Maintainer: Paul Haggart <[EMAIL PROTECTED]> Architecture: i386 Version: 0.12c-7 Depends: libc6 (>= 2.1) Filename: dists/potato/main/binary-i386/admin/ttysnoop_0.12c-7.deb Size: 13430 MD5sum: c8d903ea4a5e399a19eb1439e8eb01d7 Description: TTY Snoop - allows you to spy on telnet+serial connections TTYSnoop allows you to snoop on login tty's through another tty-device or pseudo-tty. The snoop-tty becomes a 'clone' of the original tty, redirecting both input and output from/to it. :) -- Michael Wood <[EMAIL PROTECTED]>
Re: Can a daemon listen only on some interfaces?
Hi On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: [snip] > 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. Commenting everything out should be sufficient. > The only ones I didn't know about in this list are portmap and > XF86_SVGA. Firstly, I can't seem to find the config file for > X where you set the --nolisten parameter - but I have not > unset this at any stage and I thought Debian did this by Make sure your /etc/X11/xinit/xserverrc contains something like this: #!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp > default. Secondly, I guess everyone needs portmap it seems, > so I can't turn this off or some things won't work. Someone > please educate me here. No. You do not need portmap unless you're using NFS or something like that. (i.e. SUN RPC services.) portmap is started by /etc/init.d/portmap when your machine boots. Disable it. (Why was portmap part of net-base to begin with?) It you're using testing/unstable, portmap is in it's own package (called portmap) and you should be able to uninstall it. > So my question is: > Is there some way to make certain daemons, (say postfix) > listen only on some interfaces? For example, I have > everything firewalled from outside, so I really only need > postfix to listen on the loopback interface for local > connections. Is this possible? It's technically possible, but this depends on if the particular daemon has support for this. Postfix does. Just put a line like this in main.conf: inet_interfaces = localhost > Then netstat -ln might show something like: > tcp0 0 0.0.0.0:25 127.0.0.1:* LISTEN [snip] Well, not quite :) Here's what it looks like: Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.1:250.0.0.0:* LISTEN I have no idea if cups supports binding to a particular interface, but the documentation should tell you. If you can't figure out how to do it or it's not possible without modifying the source, you should use ipchains/iptables to restrict access to the port it uses. I hope this helps. -- Michael Wood <[EMAIL PROTECTED]>
Re: Can a daemon listen only on some interfaces?
On Sat, Dec 08, 2001 at 08:09:50PM +0100, Guido Hennecke wrote: > At 08.12.2001, Michael Wood wrote: > > On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: > [...] > > > So my question is: > > > Is there some way to make certain daemons, (say postfix) > > > listen only on some interfaces? For example, I have > > > everything firewalled from outside, so I really only need > > > postfix to listen on the loopback interface for local > > > connections. Is this possible? > > It's technically possible, but this depends on if the particular > > daemon has support for this. Postfix does. > > It is a little bit different on Linux: > > It is not possible to configure a deamon to listen on an > interface only. It is only possible to bind it to an ip > address. That's splitting hairs ;) > The problem on linux is, that all local ip addresses are > reachable over all local interfaces. The only problem is the > routing and that depends on your infrastructure. > > But it is posible to use a packetfilter and configure it, that > packets for an interface must come in over the target > interface. Indeed. -- Michael Wood <[EMAIL PROTECTED]>
Re: Exim mail
On Sat, Dec 15, 2001 at 10:53:13AM -0500, Brian P. Flaherty wrote: > Josh <[EMAIL PROTECTED]> writes: > > > hmmm, im a bit of a newbie here, but how do you bind a > > daemon, eg telnetd to a certain nic? > > Try running xinetd, if you aren't already. In each service > block, you can use the 'bind' option, which ties the service > to a NIC's IP address. Someone please correct me if I am > wrong, but I think this effectively keeps the service from > listening on other interfaces. You should still firewall the port on the interfaces you don't want it to listen on, since the above is not sufficient to block connections when you have other people on the same subnet as you. There was a thread on one of the Debian lists a week or two ago (probably this list) with a subject something like "Can a daemon listen on only one interface?" where this was discussed. Someone (can't remember his name) pointed out that the above is insufficient. -- Michael Wood <[EMAIL PROTECTED]>
Re: Secure 2.4.x kernel
> could explain it, in laymens terms, was to describe someone walking > up to her house and jiggling the locks and trying all the windows to > find a weakness or a kink in the armour so that they could get > inside to either do "bad things" like use the house or allow others to > come by and party... Her response: "Thats illegal, how come if > someone try's to get into your computer, they aren't arrested.". > Hmmm... Mom has a good point. > > I think the bottom line is that we'll never have 100% security until > there are laws that protect the break-in's and hacking that occurs. > Still laws... not crappy little wrist slapping type laws. > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Michael Wood <[EMAIL PROTECTED]>
Re: Funky Arp Stuff
On Sun, Jan 06, 2002 at 01:52:45PM -0500, Phillip Hofmeister wrote: > My computer is rambling on over eth0 (External interface) > about a bunch of ARP request. Any Idea what could cause it? [snip] 20:50:05.245819 arp who-has 10.67.178.85 tell 10.67.178.1 20:50:05.367348 arp who-has 66.188.34.36 tell 66.188.32.1 20:50:05.418712 arp who-has 10.67.178.125 tell 10.67.178.1 20:50:05.419229 arp who-has 10.67.178.12 tell 10.67.178.1 20:50:05.427456 arp who-has 10.67.178.123 tell 10.67.178.1 20:50:05.453245 arp who-has 10.67.178.115 tell 10.67.178.1 20:50:05.464775 arp who-has 10.67.178.37 tell 10.67.178.1 20:50:05.465226 arp who-has 10.67.178.68 tell 10.67.178.1 20:50:05.488555 arp who-has 10.67.178.101 tell 10.67.178.1 20:50:05.489197 arp who-has 10.67.178.44 tell 10.67.178.1 20:50:05.489659 arp who-has 10.67.178.93 tell 10.67.178.1 20:50:05.556405 arp who-has 10.67.178.40 tell 10.67.178.1 20:50:05.578308 arp who-has 10.67.178.110 tell 10.67.178.1 20:50:05.641715 arp who-has 24.247.174.229 tell 24.247.174.1 20:50:05.696083 arp who-has 10.67.178.67 tell 10.67.178.1 [snip] You have a machine on your network with IP address 10.67.178.1 trying to talk to other machines with IP addresses in the range 10.67.178.x, which appear not to exist. You also have a machine with the IP address 66.188.32.1 and another with the IP address 24.247.174.1. 10.67.178.1 is most likely misconfigured. The other two resolve, so maybe they're OK, but they didn't get ARP replies, according to your packet capture. Is your machine connected to the 'net via DSL or cable or something? -- Michael Wood <[EMAIL PROTECTED]>
Re: default security
On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: [snip] > > Debian being what it is, are there any reasons why the > > debian bind package should not be chroot as the default > > instalation? > > RTFM. That is: > http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind > > :) [snip] The above link contains the following: FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified. My opinion is that things that need to be writable should be owned by the user that runs named, but everything else should be owned by root. i.e. secondary zones etc., should be owned by the user that runs named. If you're doing dynamic DNS, the primary zones will also need to be writable. named.conf (and primary zones if you're not doing dynamic DNS) should be owned by root and not writable by named. This way, if there's a bind exploit, an attacker can't corrupt your zone files or config file (except for the secondary zones.) Of course, they may still be able to make the DNS server serve incorrect information, but at least it's another hurdle for them to jump over. -- Michael Wood <[EMAIL PROTECTED]>
Re: how to create MD5 passwords
On Thu, Jan 24, 2002 at 08:56:56AM +0100, Rainer Sigl wrote: > Hi everyone, > please can me tell somebody how to make MD5 passwords in order > to supply it to ftppasswd file? You just need to call the standard crypt() function with the apropriate arguments. You can use perl or python or C or whatever to do it. e.g.: $ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> import random >>> import crypt >>> saltchars = string.uppercase + string.lowercase + string.digits + "./" >>> s = [] >>> for i in range(8): ... s.append(random.choice(saltchars)) ... >>> salt = "$1$" + string.join(s, "") >>> passwd = "Password" >>> print crypt.crypt(passwd, salt) $1$e6TSyRDd$OcJO4kuY0I/mLED6n.tNi1 -- Michael Wood <[EMAIL PROTECTED]>
Re: Problems with chrooting bind 9.2.0
On Wed, Feb 13, 2002 at 11:12:36PM +0100, Marcus Frings wrote: > Wednesday, February 13, 2002, 9:16:48 PM, Reagan Blundell wrote: > > > Feb 13 17:04:40 iridium named[1525]: none:0: open: /etc/bind/rndc.key: \ > > file not found > > Its looking for the rndc.key file in /etc/bind/ which would be > > /chroot/named/etc/bind > > You have it in /chroot/named/etc - hence it can't find it. > > Well, I tried 3 ways: > > 1) copying it back to the real /etc/bind This will not work, because named can't see the real /etc/bind when it's chrooted. > 2) copying it to /chroot/named/etc/bind i.e. /chroot/named/etc/bind is a directory containing the file rndc.key? This should work. What do the logs look like now? > 3) using symbolic links from the chroot jail to /etc/bind This won't work for the same reason as 1. -- Michael Wood <[EMAIL PROTECTED]>
