Re: how to check bind9 chroot
On Fri, 2004-03-26 at 18:53, Costas Magkos wrote: [...] Is there a way to test whether a chroot works? Does anyone know if the above syslog option is really needed? According to the man page of syslog it is needed. use lsof # lsof -p [pid number of bind process] check: - if the loaded libraries is in the chroot (by cheking the path and/or the inode) - if std in/out and err are connected inside the chroot to /dev/null - there is only one socket to syslog (in the real world) -- JJ van Gorkum Knowledge Zone If UNIX isn't the solution, you've got the wrong problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to check bind9 chroot
On Fri, 2004-03-26 at 18:53, Costas Magkos wrote: [...] Is there a way to test whether a chroot works? Does anyone know if the above syslog option is really needed? According to the man page of syslog it is needed. use lsof # lsof -p [pid number of bind process] check: - if the loaded libraries is in the chroot (by cheking the path and/or the inode) - if std in/out and err are connected inside the chroot to /dev/null - there is only one socket to syslog (in the real world) -- JJ van Gorkum Knowledge Zone If UNIX isn't the solution, you've got the wrong problem.
Re: AW: Traffic monitoring
On Tue, 2003-03-18 at 16:04, debian-security wrote: check out flowscan http://www.caida.org/tools/utilities/flowscan/ it gets close to what you want, assuming all the traffic is passing through a cisco router. A better choice (IMHO) would be flow-tools at http://www.splintered.net/sw/flow-tools/ there is no debian package yet... but working on it :) Description: Flow-tools is library and a collection of programs used to collect, send, process, and generate reports from NetFlow data. The tools can be used together on a single server or distributed to multiple servers for large deployments. The flow-toools library provides an API for development of custom applications for NetFlow export versions 1,5,6 and the 14 currently defined version 8 subversions. A Perl and Python interface have been contributed and are included in the distribution. Flow data is collected and stored by default in host byte order, yet the files are portable across big and little endian architectures. Commands that utilize the network use a localip/remoteip/port designation for communication. localip is the IP address the host will use as a source for sending or bind to when receiving NetFlow PDU's (ie the destination address of the exporter. Configuring the localip to 0 will force the kernel to decide what IP address to use for sending and listen on all IP addresses for receiving. remoteip is the destination IP address used for sending or the expected address of the source when receiving. If the remoteip is 0 then the application will accept flows from any source address. The port is the UDP port number used for sending or receiving. When using multicast addresses the localip/remoteip/port is used to represent the source, group, and port respectively. -- JJ van Gorkum Knowledge Zone If UNIX isn't the solution, you've got the wrong problem.
Re: questions about chrooting bind 8.3.3
On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote: Hello, Bind has the built in ability to chroot itself (-t). then all that needs to be done is altering the bind init script(/etc/init.d/bind), which contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into that variable and you should be ok. I've done this with Bind 8, and now upgraded them to 9. You are missing the point here, if I do it the way bind tells me in the man pages bind is NOT using the libraries inside the chroot environment. That is wat I try to proove with the lsmod command... -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions about chrooting bind 8.3.3
On Wed, 2002-10-30 at 22:15, Sean McAvoy wrote: Yes it is true that it's making use of the systems libs, but they can't be touched by the process as it has been chrooted. In order for someone to overwrite those files, they would first have to break of the chroot. I'm not sure of the real security implications of using the system libs are vs. using chrooted libs. Maybe I'm too much an old school admin but 'they' allways told me to move all the libraries into the chroot environment (no symlinks watsoever) and even (if possible) move the whole chroot environment onto an special (read-only) filesystem... In my second example when I start the named daemon without the -t option and use the (buggy) start-stop-daemon --chroot option the libraries are used from the chroot environment. That was my point -- and it seems that the 'standard' debian method of using a chroot environment (the link from my original post) is moving the libraries into the chroot environment and not using them. -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions about chrooting bind 8.3.3
On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote: Hello, Bind has the built in ability to chroot itself (-t). then all that needs to be done is altering the bind init script(/etc/init.d/bind), which contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into that variable and you should be ok. I've done this with Bind 8, and now upgraded them to 9. You are missing the point here, if I do it the way bind tells me in the man pages bind is NOT using the libraries inside the chroot environment. That is wat I try to proove with the lsmod command... -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem.
Re: questions about chrooting bind 8.3.3
On Wed, 2002-10-30 at 22:15, Sean McAvoy wrote: Yes it is true that it's making use of the systems libs, but they can't be touched by the process as it has been chrooted. In order for someone to overwrite those files, they would first have to break of the chroot. I'm not sure of the real security implications of using the system libs are vs. using chrooted libs. Maybe I'm too much an old school admin but 'they' allways told me to move all the libraries into the chroot environment (no symlinks watsoever) and even (if possible) move the whole chroot environment onto an special (read-only) filesystem... In my second example when I start the named daemon without the -t option and use the (buggy) start-stop-daemon --chroot option the libraries are used from the chroot environment. That was my point -- and it seems that the 'standard' debian method of using a chroot environment (the link from my original post) is moving the libraries into the chroot environment and not using them. -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem.
questions about chrooting bind 8.3.3
Hi, I have a question about chrooting bind 8.3.3 I have used the setup as described in http://people.debian.org/~pzn/howto/chroot-bind.sh.txt ... but when I then start bind evrything looks right but when I do a lsof -p pid of named I see: command to start bind: start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named -t /var/lib/chroot/named/ # lsof -p 22119 COMMAND PID USER FD TYPE DEVICESIZENODE NAME named 22119 named cwdDIR 8,224096 145479 /var/lib/chroot/named/var/cache/bind named 22119 named rtdDIR 8,224096 145467 /var/lib/chroot/named named 22119 named txtREG8,6 512088 130880 /usr/sbin/named named 22119 named memREG8,5 82503 30185 /lib/ld-2.2.5.so named 22119 named memREG8,5 1145456 30223 /lib/libc-2.2.5.so named 22119 named memREG8,5 32664 30232 /lib/libnss_files-2.2.5.so named 22119 named0u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named1u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named2u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named3u unix 0xe1086560 5375674 socket named 22119 named4u IPv45375686 UDP *:32943 named 22119 named5u unix 0xd9d1ec40 5375676 /var/run/ndc named 22119 named 20u IPv45375680 UDP localhost:domain named 22119 named 21u IPv45375681 TCP localhost:domain (LISTEN) and when I change the command to start bind to : start-stop-daemon --chroot /var/lib/chroot/named/ --start --pidfile /var/run/named.pid --exec /usr/sbin/named -- -u named -g named I see: # lsof -p 23433 COMMAND PID USER FD TYPE DEVICESIZENODE NAME named 23433 named cwdDIR 8,224096 145479 /var/lib/chroot/named/var/cache/bind named 23433 named rtdDIR 8,224096 145467 /var/lib/chroot/named named 23433 named txtREG 8,22 512088 145502 /var/lib/chroot/named/usr/sbin/named named 23433 named memREG 8,22 82503 145501 /var/lib/chroot/named/lib/ld-linux.so.2 named 23433 named memREG 8,22 1145456 145500 /var/lib/chroot/named/lib/libc.so.6 named 23433 named memREG 8,22 32664 146115 /var/lib/chroot/named/lib/libnss_files.so.2 named 23433 named0u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named1u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named2u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named3u unix 0xef055a80 5239772 socket named 23433 named4u IPv45239784 UDP *:32942 named 23433 named5u unix 0xeee6d140 5239774 /var/run/ndc named 23433 named 20u IPv45239778 UDP localhost:domain named 23433 named 21u IPv45239779 TCP localhost:domain (LISTEN) Look at the difference in the libraries, as I can see when I start named as stated in the script the libraries in the chrooted environment are not used Am I wrong here? -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
