ipchains
Hi. My network situation: 192.168.1.0/24 192.168.1.1194.24.227.236 Sistel company LAN - (eth0) linux firewall (ppp0) internet my ipchains configuration: cat begin --- # Vycisteni ipchains ipchains -F ipchains -X # vytvoreni SISTEL--INTERNET ipchains -N s--i # vse co prochazi ze SISTEL do INTERNETu ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j s--i ipchains -A forward -j DENY -l ipchains -A s--i -s 192.168.1.20 -j DENY ipchains -A s--i -s 192.168.1.21 -j DENY ipchains -A s--i -p tcp --dport www -j MASQ ipchains -A s--i -p tcp --dport pop3 -j MASQ ipchains -A s--i -p tcp --dport ftp -j MASQ ipchains -A s--i -p tcp --dport domain -j MASQ ipchains -A s--i -p udp --dport domain -j MASQ ipchains -A s--i -p icmp --icmp-type ping -j MASQ ipchains -A s--i -p udp --dport 33434:33500 -j MASQ ipchains -A s--i -j DENY # definice ICMP-ACCEPT ipchains -N icmp-acc ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT # vytvoreni SYSTEL-INTERFACE, INTERNET-INTERFACE ipchains -N s-if ipchains -N i-if # pravidla pro INTERNET-INTERFACE ipchains -A input -d 194.24.227.236 -j i-if ipchains -A i-if -s 194.24.224.0/27 -j ACCEPT ipchains -A i-if -i ! ppp0 -j DENY -l ipchains -A i-if -p TCP --dport 61000:65095 -j ACCEPT ipchains -A i-if -p UDP --dport 61000:65095 -j ACCEPT ipchains -A i-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A i-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A i-if -j icmp-acc ipchains -A i-if -j DENY -l # pravidla pro SISTEL-INTERFACE ipchains -A input -d 192.168.1.1 -j s-if ipchains -A s-if -i ! eth0 -j DENY -l ipchains -A s-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A s-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A s-if -j icmp-acc ipchains -A s-if -j DENY -l # vypis pravidel firewallu ipchains -L -n ---cat end--- Is possible to allow all connection from firewall to the internet? In example firewall to be ftp client. But still must be DENY all access from Internet to the firewall. Thank You for help! -- S pozdravem, Michal Kolesar +420 608 225025 [EMAIL PROTECTED] http://www.egarden.cz server of free unix services S pozdravem, Michal Kolesar +420 608 225025 [EMAIL PROTECTED] http://www.egarden.cz server of free unix services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Without SSH enabled, I was able to pass my root user account from one trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. #cat .rhost Doctor #cat /etc/host.equiv Doctor root For example, Doctor would be the solaris hostname and root would be the account. This leaves a big security hole, so I only activate it when I am doing backups for about 4-5 hours each month. Maybe someone on the list can help with the RSA since I am fairly new in that field also Dan Duane Powers [EMAIL PROTECTED] wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Duane Powers wrote: Hi all, [ ... ] I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? [ ... ] He probably simply generated a public/private key on his local machine, and then ftp'd (or somehow transmitted) his public key to the remote host. Somewhere within the SSH protocol, his local private key is used to sign something which is then decrypted by the remote public key. Only someone who holds the correct private key would be able to sign something which could be decrypted by the public key so this authorises client (you) to the server. To set this up, you just have to do ssh-keygen locally then append ~local_user/.ssh/identity.pub to ~remote_user/.ssh/authorized_keys. You should then be able to do "ssh -l remote_user foo.com" without being asked for a password. I think that's right, but check the manpages anyway. -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
On Mon, Feb 19, 2001 at 10:14:18AM -0800, Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. Ok... check your /etc/ssh/sshd_options file You need to enable some options with RSA in their name, they are all there, only commented out by default. Next you need to go to your user's .ssh directory (the user/system you want to ssh to... so root on your solaris boxes) and create a file called authorized_keys (check the local sshd manual page for exact name, it will differer between implementations) and append your public key to it so: cat my-public-key ~/.ssh/authorized_keys Then you should be able to login with your key and key passphrase, and not the local account password. I just tried it on my local system and it works great (using teraterm ssh on windows to my debian linux box) Here's the line from the sshd_options file: RSAAuthentication yes More info can be found in the sshd_options file and the manual page for sshd (not ssh) ;) Have fun... As always, You guys are great, thanks in advance for the help, ~duane -- Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED]GnuPG Key Id: 357D2178 http: markjanssen.homeip.net and markjanssen.[com|net|org|nl] Fax/VoiceMail: +31 20 8757555 Finger for GPG and GeekCode PGP signature
Re: SSH and RSA
Hi Duane, from 'man ssh' you can find some answer: As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This stores the private key in .ssh/identity and the public key in .ssh/identity.pub in the user's home directory. The user should then copy the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication. I hope this will help you Bye On Mon, Feb 19, 2001 at 10:14:18AM -0800, Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- 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]
Re: SSH and RSA
On Mon, Feb 19, 2001 at 01:21:45PM -0500, Dan Hutchinson wrote: Without SSH enabled, I was able to pass my root user account from one trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. #cat .rhost Doctor #cat /etc/host.equiv Doctor root For example, Doctor would be the solaris hostname and root would be the account. This leaves a big security hole, so I only activate it when I am doing backups for about 4-5 hours each month. Maybe someone on the list can help with the RSA since I am fairly new in that field also Dan Duane Powers [EMAIL PROTECTED] wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, Hi, guys. Here's what I've got: -- terminal copy start: -- $ ssh -v SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0. -- terminal copy snip -- $ man ssh SSH(1) System Reference Manual SSH(1) NAME ssh - OpenSSH secure shell client (remote login program) -- terminal copy snip -- DESCRIPTION -- terminal copy snip -- SSH protocol version 1 -- terminal copy snip -- As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal- lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. -- terminal copy snip -- -- terminal copy end: -- I also suggest re-reading the ssh-keygen(1) manual page. To use RSA/DSA authentication you need to generate a personal log-in key pair (via ssh-keygen). Then, copy your public key to the remote machine's "$HOME/.ssh/authorized_keys" for RSA or "$HOME/.ssh/authorized_keys2" for DSA where "$HOME" is the home directory for the user as who you want to log in on the remote machine. After this step, assuming the other configuration is fine, an "$ ssh -l remote_user_name remote_host_name" should be about enough to log in to the remote machine. A piece of advice: if you want security, read all the manual documentation you have about ssh. Good luck, -- Pavel M. Penev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: SSH and RSA
-Original Message- From: Duane Powers [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 20, 2001 7:37 AM To: Mike Dresser Cc: [EMAIL PROTECTED] Subject: Re: SSH and RSA Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Duane, Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; from=10.0.0.1,command="uptime" 1024 3513948513452723553495234978502397465902 3475923475089234758907234057564387523487589234750234765079234658079623457862 34076 9510950293476590175907234650934234948571390874534925902345907623490562347895 63892 4765923876589237465892374659389234752348907569234590234579013465978234658972 34658 9762349856239487562347896 Bilbo Baggins 1024 35 139485134527235534952349785023974659023475923475089234758907234057564 3875234875892347502347650792346580796234578623407951095029347659017590723465 0934 2349485713908745349259023459076234905623478956389247659238765892374658923746 5934 8923475234890756923459023457901346597823465897234658976234985623948756234789 6 Joe Random 1024 35 139485134527235534952349785023974659023475923475089234758907234057564 3875234875892347502347650792346580796234578623407951095029347659017590723465 0934 2349485713908745349259023459076234905623478956389247659238765892374658923746 5934 8923475234890756923459023457901346597823465897234658976234985623948756234789 6 Jayne Eyre Each line in this file contains some directives (as in the first entry above (from=, command=), a public key (starts with 1024 35 XXX in the examples above), and a comment, usually the name or email address of the person who generated it. Remove any appearing to belong to the previous admin. Those containing a command="..." directive will only be able to execute that command and so may be related to automated processes. To add your own key first generate it (possibly on your workstation if you are sure it is well secured) using ssh-keygen. Make sure you use a passphrase. A command like; ssh-keygen -b 1024 -f .ssh/identity -C "Joe New Admin" should suffice. Make sure that the generated .ssh/identity is not readable by any but you and shouldn't be writeable by anybody. Now copy the file .ssh/identity.pub onto all of the machines running SSH and add it to the end of ~root/.ssh/authorized_keys on each machine. You can do this using scp or even a cut-and-paste via ssh. Make sure that you do not split the line up when adding it to authorized_keys. This will give you RSA keypair authentication to all of those machines instead of password access. I would also recommend creating a non-root account to log in with and totally disallow root logins. You would be able to simply move the authorized_keys file to the non-root .ssh directory. -- Andrew J. Stephen Network Operations Manager "The important thing about standards is to have them." -- Bruce Schneier, creator of the Twofish algorithm A couple of quick notes, I just realized that by trying to be cute and putting my comments in angle brackets, those among us who may read html mail, may not be able to see my comments (my bad). And second, I saw him login once, he was prompted for his RSA key as follows: (to the best of my recollection) ssh [EMAIL PROTECTED] enter RSA passkey: # remote prompt Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe".
Debian or Linux 7???
Hi! I am frustrated with the linux 2.2 kernel. I have had two hacks in 3 months and I am going broke rebuilding my server. I went out and bought Redhat 7, and got hacked 6 weeks later. I have been placed in contact with a guy who wants me to use Debian. But if it based upon the same kernel as redhat, how is it going to be more secure? I checked and found that from (http://www.securityfocus.com/) Security risks for years: 1997-2000 respectively: Debian 3, 2, 32, 45, 12 RedHat 6, 10, 49, 85, 20 So Debian is about twice as good as redhat, but that is not real reassuring. I am considering joining the debian family, but am a bit concerned about security. Just how much more secure is Debian than redhat? Thanks! Steve Rudd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Linux 7???
Just how much more secure is Debian than redhat? Security comes from knowing how to use and administrate Unix, it doesn't just fall into your lap at the press of a button. If you want a secure OS you have to work for it and understand what you're doing. Debian is no more secure than Redhat is no more secure than Solaris is no more secure than OpenBSD. We could make a lot of vague generalizations about default setup and what-not but its really just a waste of time. If you don't want to be hacked, learn how to prevent it. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen (you might want to move it out of the way till you're set up though) and start from scratch. As the admin you want to know who can get in as root on your machines. Besides script kiddies of course :-) There was a good mini HOWTO kind of posting on debian-user a while back that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.html Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Linux 7???
The distribution is only as secure as the administrator makes it. If you just install it and let it sit, you WILL get hacked/cracked. It may take weeks, or months, but it will happen .. only a matter of time. --Henry On Mon, 19 Feb 2001, Steve Rudd wrote: Hi! I am frustrated with the linux 2.2 kernel. I have had two hacks in 3 months and I am going broke rebuilding my server. I went out and bought Redhat 7, and got hacked 6 weeks later. I have been placed in contact with a guy who wants me to use Debian. But if it based upon the same kernel as redhat, how is it going to be more secure? I checked and found that from (http://www.securityfocus.com/) Security risks for years: 1997-2000 respectively: Debian 3, 2, 32, 45, 12 RedHat 6, 10, 49, 85, 20 So Debian is about twice as good as redhat, but that is not real reassuring. I am considering joining the debian family, but am a bit concerned about security. Just how much more secure is Debian than redhat? Thanks! Steve Rudd -- 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]
Re: Debian or Linux 7???
It might be more secure, because the packages chosen for distribution or often more tested - not the latest versions with brand new bugs but (somewhat) older packages with known bugs removed. I would also have to add: I find it easier to keep Debian secure because it is easier to get and install updated packages with Debian than with Redhat. Typing 'apt-get install package' beats digging around Redhat's FTP site hands down... and switching would be worthwhile even just for that. I have been hacked myself twice in the past two years while running RedHat systems, and it was because I was not diligent enough in the way I kept up with security updates. Get Debian, read the HOWTOs to get an idea how to secure it, and then stay on the security annoucement mailing list. That really should get you most of the way there... (Just my $0.02, anyway) KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Linux 7???
Steve Rudd wrote: Hi Steve, It's not just the kernel that can get hacked. Is it Linux 7 or Redhat 7 ? (I'm pretty sure it's Redhat 7). Anyway, I'm pretty new to Debian and Linux so anyone please feel free to correct me. An example of the different methodologies between Redhat and Debian: the stable version of Debian doesn't use the latest kernel; it hasn't been tested enough yet (I assume). I heard that Redhat and Mandrake (no offense, I like all Linuxes) act a bit like capitalist companies; they want their product to be popular, so they throw in all the latest stuff, sacrificing some stability and security (by not testing enough) for "the edge!", having the most popular product. I think that about sums up the security differences between Debian and most other distros. I believe the Debian maintainers and developers take a more methodical, technical view of things. --- A cool thing about Debian is the super control it gives you about what runs on your box and what it can access. I think it actually sacrifices user friendliness (for newbies like me) in exchange for control. I tried Corel Linux last week (which is kind of based on Debian) and it installed everything without me typing more than my name, hitting "next, next, next". It did a pretty good job, it only missed my sound card! But I didn't know what it had installed on my machine, and exactly what it was doing! I recently read the "Secure Install" thread in this group and tried it. I killed Corel, and re-installed from the CD and just exited out of DSelect. (I discovered by the way that you should at least select the "6) Remove..." option before exiting, so it can remove the pcmcia packages). Anyway, after that I installed things as I desired with apt-cache search and apt-get install. (Thank you developers of apt-setup, and apt-cdrom!). The point is, by installing packages one at a time, and checking things after, I could keep great control of everything on my machine. I also know what modules are loading from, /etc/modules.conf and /etc/modules. I also know what services are running in different run levels from the /etc/rc2.d and other directories. It's so cool. I'm not an expert on security, I've never been hacked or virused since I started Linux about a year ago! (Practically all of my MS friends have had viruses though!) Enough blurb... GBY -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Olaf Meeuwissen wrote: [EMAIL PROTECTED]">Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote:You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want,and he'll still be able to connect, assuming he can get to themachine via your network/internet.Mike has an exceptionally pertinant point here.Right now - even before you start trying to load your own RSA keyin, log into all machines running SSH and remove the previous adminskey from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen(you might want to move it out of the way till you're set up though)and start from scratch. As the admin you want to know who can get inas root on your machines. Besides script kiddies of course :-)There was a good mini HOWTO kind of posting on debian-user a whileback that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.htmlHope this helps, Thanks all for the prompt responses... The url and the advice helped immensely, I got it working. thanks [EMAIL PROTECTED]"> -- D U A N E P O W E R S duane@lots_of_placesThe plan was simple. Unfortunately, so was Bullwinkle.
Anti Virus for Debian
Are there any gpl or similar anti-virus programs for linux ? Any reccomendations ? GBY -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anti Virus for Debian
On Tue, Feb 20, 2001 at 04:41:02PM +1300, Matthew Sherborne wrote: Are there any gpl or similar anti-virus programs for linux ? If you mean filters that can scan incoming email and search for Windows or maybe Mac viruses, then yes, they exist, but I don't know of any released under the GPL. McAfee and other anti-virus companies make server side scanners that run on Unix (and Linux). They're both commercial and very expensive. If you mean anti-virus stuff to actually scan for Linux viruses, then no, I don't think any exist at all, GPL or otherwise. There has never been enough of a significant virus threat under Unix or Linux to warrant such a thing. However, you might want to look in to intrusion detection tools such as tripwire (www.tripwire.org). Tripwire constructs a database of info about every file on your system and can be used to search for changes in files. This can let you know if you've been the victim of a crack or worm or something. As with all tools like this, it can only do its job if you use it right. Read the docs...all of them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html PGP signature
Re: Anti Virus for Debian
I would also like to know of virus scanners especially for mail servers ie sendmail that will work on a SPARC ??? there are a few that work under i386 ie like amavris etc can be found on freshmeat.net but nothing will work under a sparc - Original Message - From: "Matthew Sherborne" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 20, 2001 1:41 PM Subject: Anti Virus for Debian Are there any gpl or similar anti-virus programs for linux ? Any reccomendations ? GBY -- 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]
Unknown file in login on proftpd 1.2.0pre10-2potato1
Hi, I've just found that an anonymous ftp connection to my box whould leave a file $FTPROOT/var , whose u/gid is ftp/nogroup, the same as proftpd. I'm using Debian 2.2 with proftpd 1.2.0pre10-2potato1 on an i386, and this didn't happen before I do an 'apt-get upgrade' some time ago. And while I was trying to close the daemon I found that a '/etc/init.d/proftpd stop' won't work. I have to manually kill the process. I had the daemon killed for now. What should I do to make sure that the daemon is safe? pm5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unknown file in login on proftpd 1.2.0pre10-2potato1
Poe-Min Oliver Wu wrote: Hi, I've just found that an anonymous ftp connection to my box whould leave a file $FTPROOT/var , whose u/gid is ftp/nogroup, the same as proftpd. I'm using Debian 2.2 with proftpd 1.2.0pre10-2potato1 on an i386, and this didn't happen before I do an 'apt-get upgrade' some time ago. Actually, we just noticed the exact same thing on one of our servers, running the exact same version of proftpd. There are now 30 of these files in different people's homedirectories. They are all owned by the user owning that directory; I guess this is because we are running with "DefaultRoot ~". All files have the exact same size, 1932 bytes. Almost all of them are full of nulls, except for one which contains a few readable words, seeming to come from the proftpd logs. My guess is that it's a small bug in proftpd that dumps some internal data, and has no security implications. But since you can't be too sure, it would be interesting to see what other people have to say about this. Maarten Vink -- Williams and Holland's Law: If enough data is collected, anything may be proven by statistical methods. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OpenSSH and CVS
I'm running Debian on a CVS server and have Debian clients. We're using OpenSSH to replace the rsh calls in CVS. The problem is that every time a cvs user makes a CVS call (like cvs diff file), they have to enter my password. I know there's a way around this, but I can't find clear documentation. Anyone have a similiar experience? -- Matt Ray [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenSSH and CVS
Matthew H. Ray wrote: I'm running Debian on a CVS server and have Debian clients. We're using OpenSSH to replace the rsh calls in CVS. The problem is that every time a cvs user makes a CVS call (like cvs diff file), they have to enter my password. I know there's a way around this, but I can't find clear documentation. If you don't want to enter passwords then you could use RSA keys. (man ssh) However you say - "enter my password" - that smacks of misconfiguration as they should be entering *their* passwords, not yours. Don't expect any system which uses a single account shared among many users to be secure. Also, if you have any wincvs users be sure you set your CVSROOT to something that a) includes the :ext: protocol hint, and b) doesn't include the username. I have found through experience that wincvs is pretty picky about those things, where unix clients aren't. For example a good CVSROOT is :ext:mycvsserver:/mycvs/root/path where as a bad one which will almost certainly make wincvs choke (these get stored in the CVS control files remember) is user@mycvsserver:/mycvs/root/path. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Linux 7???
On Mon, 19 Feb 2001 18:12:29 -0500 Steve Rudd [EMAIL PROTECTED] wrote: Hi! I am frustrated with the linux 2.2 kernel. I have had two hacks in 3 months and I am going broke rebuilding my server. The odds are good that your being cracked had nothing to do with the kernel version you were running. I went out and bought Redhat 7, and got hacked 6 weeks later. Hardly surprising. So Debian is about twice as good as redhat, but that is not real reassuring. You need to find out: a) How your systems were cracked. b) How you could have prevented that. c) How to harden a system. d) How to audit and monitor a system. e) How to actively maintain a secure system. Choice of Linux distribution or kernel version really isn't going to help you much there (minor exceptions).. -- J C Lawrence [EMAIL PROTECTED] -(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Realserver 8 Webinator on Debian
Steve here, I want to install "Real Basic Server 8" and "Webinator" search program on the latest version of Debian 2.2r2. 1. Will they install or are they not compatible. For example, while Webinator would work with Redhat 7, Realserver 8 would not. (But Real Server 7 did install on Redhat 6) 2. Do these programs pose any security risk. For example, Realserver uses several port addresses for administration. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Redhat 7???
Steve here, Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have been maintaining my own box from a su level for about 3 months. That is why I was calling in an expert to install Debian tomorrow. It has become quite obvious to me that I am way over my head in trying to get my server secure. But I would also like to say that I was humbled by the sheer volume of caring replies. I want to say that I have taken note of all of them and thank you. My personal/superficial conclusions to my own questions based upon your replies is that Debian (as a software package) is a little more secure (for a variety of reasons), than Redhat 7. But the biggest factor is me getting pro help by someone who knows what he is doing. Done! There is one primary reason why I would have chosen Debian over Redhat in the first place. The auto-update feature. I was on line for the Redhat Network. It never notified me of anything. Even now, after being hacked, is gives me those nice smiley icons saying all is ok! g For me to get the box set up, then issue a one line command as the SU via "CRT" program in SSH mode, to update is breathtakingly attractive! Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Redhat 7???
On Tue, Feb 20, 2001 at 04:39:09PM +1300, Matthew Sherborne wrote: It may get too heavy to not mirror the security update packages. Why don't we put signature verification into apt and dpkg and mirror everything ? Sounds to me like a good idea; however, it would probably mean rather extensive changes to both apt and dpkg. This would in my opinion be the ideal solution, but then again I'm not the one who would be doing all the work :) - Tal -- - Tal Danzig [EMAIL PROTECTED] | Libranet Linux http://tal.thepenismightier.net | http://www.libranet.com - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How I got hacked last week: Redhat 7
Steve here,
Several have voiced an interest in the hack. Well here is a guess and some
facts:
THE HACK:
For those interested in the hack, I think it was the "Dameon worm" but
could not find any evidence of the trace files on my system. Here is what
happened:
1. I get a letter from "[EMAIL PROTECTED]" saying: "Urgent! Security
incident on your machine! Attrition.org is a non-profit, hobby web site
that monitors
computer crime on the internet. In the past few minutes, we
have been notified that your domain was hacked, and your web
page defaced. This means that the intruder has edited your
web page in some way. Due to this, it is quite likely that
one or all of the machines on your network are compromised.
You may wish to take immediate action to correct this problem
and respond to the intrusion."
2, I noticed my clock went forward maybe a day and had to reset it via
"date" command.
3. I notice a single page was changed: "index.html"
Here is the code from that page:
!-- BEGIN Naviscope Javascript --
script language='javascript'
NS_ActualOpen=window.open;
function NS_NullWindow(){this.window;}
function NS_NewOpen(url,nam,atr){return(new NS_NullWindow());}
window.open=NS_NewOpen;
/script
!-- END Naviscope Javascript --
html
head
title..:: Quit Crew ::../title
/head
body bgcolor="#FF"
center
OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-44455354"
codebase="http://active.macromedia.com/flash2/cabs/swflash.cab#version=4,0,0,0"
ID=devil WIDTH=731 HEIGHT=562
PARAM NAME=movie VALUE="qc.swf"
PARAM NAME=loop VALUE=false
PARAM NAME=quality VALUE=high
PARAM NAME=bgcolor VALUE=#FF
/OBJECT
/center
/body
/html
=
end code
4. I have noticed nothing other than these changes.
So there you have it. I didn't even ever get to see what the flash was all
about it just loaded forever without anything. You know for all my trouble,
I should have at least got some free artwork!
Steve
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Redhat 7???
On Mon, Feb 19, 2001 at 07:13:40PM -0800, Rick Rezinas wrote: I've been loosely foloowing this thread, and hope you have the best of luck locking down. A few places to start with the inetd.conf file. You probably don't need any of those services. Install ssh. Setup your apt sources.list to check for deb http://security.debian.org stable/updates main contrib non-free but you may want to use a mirror, so they don't get nailed. There are no mirrors of security.debian.org (or shouldn't be) for security reasons. This way the authenticity of security packages can be better controlled. - Tal basically, each line in the sources.list has a list of packages, and they look to see who is the newest and install that puppy. those are a coupla basic steps to locking down your box. Others include not running named cux it's often a problem...I have no doubt that there are crackers out there with several named and sendmail holes in their pocket. That haven't been exposed before. So if you run mail, check out qmail. IMHO. Don't have key services run as root, like your webserver if that is key. That way if you get compromised they still need to work for root. have a nice day rick On Mon, 19 Feb 2001, Steve Rudd wrote: Steve here, Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have been maintaining my own box from a su level for about 3 months. That is why I was calling in an expert to install Debian tomorrow. It has become quite obvious to me that I am way over my head in trying to get my server secure. But I would also like to say that I was humbled by the sheer volume of caring replies. I want to say that I have taken note of all of them and thank you. My personal/superficial conclusions to my own questions based upon your replies is that Debian (as a software package) is a little more secure (for a variety of reasons), than Redhat 7. But the biggest factor is me getting pro help by someone who knows what he is doing. Done! There is one primary reason why I would have chosen Debian over Redhat in the first place. The auto-update feature. I was on line for the Redhat Network. It never notified me of anything. Even now, after being hacked, is gives me those nice smiley icons saying all is ok! g For me to get the box set up, then issue a one line command as the SU via "CRT" program in SSH mode, to update is breathtakingly attractive! Steve -- 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] -- - Tal Danzig [EMAIL PROTECTED] | Libranet Linux http://tal.thepenismightier.net | http://www.libranet.com - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Redhat 7???
It may get too heavy to not mirror the security update packages. Why don't we put signature verification into apt and dpkg and mirror everything ? And perhaps have a tool that checks a bunch of known mirrors for discrepencies in the keyring packages ? And have a single URL, location aware, load balancing server ? :) (I know we've been through this before. I just had a brainwave and wanted to see if anyone was interested in doing the above. Sorry for the lack of realism, but not for the extra zeal) GBY Tal Danzig wrote: There are no mirrors of security.debian.org (or shouldn't be) for security reasons. This way the authenticity of security packages can be better controlled. - Tal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ipchains
Hi. My network situation: 192.168.1.0/24 192.168.1.1194.24.227.236 Sistel company LAN - (eth0) linux firewall (ppp0) internet my ipchains configuration: cat begin --- # Vycisteni ipchains ipchains -F ipchains -X # vytvoreni SISTEL--INTERNET ipchains -N s--i # vse co prochazi ze SISTEL do INTERNETu ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j s--i ipchains -A forward -j DENY -l ipchains -A s--i -s 192.168.1.20 -j DENY ipchains -A s--i -s 192.168.1.21 -j DENY ipchains -A s--i -p tcp --dport www -j MASQ ipchains -A s--i -p tcp --dport pop3 -j MASQ ipchains -A s--i -p tcp --dport ftp -j MASQ ipchains -A s--i -p tcp --dport domain -j MASQ ipchains -A s--i -p udp --dport domain -j MASQ ipchains -A s--i -p icmp --icmp-type ping -j MASQ ipchains -A s--i -p udp --dport 33434:33500 -j MASQ ipchains -A s--i -j DENY # definice ICMP-ACCEPT ipchains -N icmp-acc ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT # vytvoreni SYSTEL-INTERFACE, INTERNET-INTERFACE ipchains -N s-if ipchains -N i-if # pravidla pro INTERNET-INTERFACE ipchains -A input -d 194.24.227.236 -j i-if ipchains -A i-if -s 194.24.224.0/27 -j ACCEPT ipchains -A i-if -i ! ppp0 -j DENY -l ipchains -A i-if -p TCP --dport 61000:65095 -j ACCEPT ipchains -A i-if -p UDP --dport 61000:65095 -j ACCEPT ipchains -A i-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A i-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A i-if -j icmp-acc ipchains -A i-if -j DENY -l # pravidla pro SISTEL-INTERFACE ipchains -A input -d 192.168.1.1 -j s-if ipchains -A s-if -i ! eth0 -j DENY -l ipchains -A s-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A s-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A s-if -j icmp-acc ipchains -A s-if -j DENY -l # vypis pravidel firewallu ipchains -L -n ---cat end--- Is possible to allow all connection from firewall to the internet? In example firewall to be ftp client. But still must be DENY all access from Internet to the firewall. Thank You for help! -- S pozdravem, Michal Kolesar +420 608 225025 [EMAIL PROTECTED] http://www.egarden.cz server of free unix services S pozdravem, Michal Kolesar +420 608 225025 [EMAIL PROTECTED] http://www.egarden.cz server of free unix services
SSH and RSA
Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle.
Re: SSH and RSA
Without SSH enabled, I was able to pass my root user account from one trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. #cat .rhost Doctor #cat /etc/host.equiv Doctor root For example, Doctor would be the solaris hostname and root would be the account. This leaves a big security hole, so I only activate it when I am doing backups for about 4-5 hours each month. Maybe someone on the list can help with the RSA since I am fairly new in that field also Dan Duane Powers [EMAIL PROTECTED] wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com
Re: SSH and RSA
Duane Powers wrote: Hi all, [ ... ] I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? [ ... ] He probably simply generated a public/private key on his local machine, and then ftp'd (or somehow transmitted) his public key to the remote host. Somewhere within the SSH protocol, his local private key is used to sign something which is then decrypted by the remote public key. Only someone who holds the correct private key would be able to sign something which could be decrypted by the public key so this authorises client (you) to the server. To set this up, you just have to do ssh-keygen locally then append ~local_user/.ssh/identity.pub to ~remote_user/.ssh/authorized_keys. You should then be able to do ssh -l remote_user foo.com without being asked for a password. I think that's right, but check the manpages anyway. -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/
Re: SSH and RSA
You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane
Re: SSH and RSA
On Mon, Feb 19, 2001 at 10:14:18AM -0800, Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. Ok... check your /etc/ssh/sshd_options file You need to enable some options with RSA in their name, they are all there, only commented out by default. Next you need to go to your user's .ssh directory (the user/system you want to ssh to... so root on your solaris boxes) and create a file called authorized_keys (check the local sshd manual page for exact name, it will differer between implementations) and append your public key to it so: cat my-public-key ~/.ssh/authorized_keys Then you should be able to login with your key and key passphrase, and not the local account password. I just tried it on my local system and it works great (using teraterm ssh on windows to my debian linux box) Here's the line from the sshd_options file: RSAAuthentication yes More info can be found in the sshd_options file and the manual page for sshd (not ssh) ;) Have fun... As always, You guys are great, thanks in advance for the help, ~duane -- Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED]GnuPG Key Id: 357D2178 http: markjanssen.homeip.net and markjanssen.[com|net|org|nl] Fax/VoiceMail: +31 20 8757555 Finger for GPG and GeekCode pgpjNnQjA5cs0.pgp Description: PGP signature
Re: SSH and RSA
Hi Duane, from 'man ssh' you can find some answer: As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This stores the private key in .ssh/identity and the public key in .ssh/identity.pub in the user's home directory. The user should then copy the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication. I hope this will help you Bye On Mon, Feb 19, 2001 at 10:14:18AM -0800, Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. No, he's not available for help, so yes, I want to change his passwords and the keys associated with the root account. A couple of quick notes, I just realized that by trying to be cute and putting my comments in angle brackets, those among us who may read html mail, may not be able to see my comments (my bad). And second, I saw him login once, he was prompted for his RSA key as follows: (to the best of my recollection) ssh [EMAIL PROTECTED] enter RSA passkey: # remote prompt Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle.
Re: SSH and RSA
On Mon, Feb 19, 2001 at 01:21:45PM -0500, Dan Hutchinson wrote: Without SSH enabled, I was able to pass my root user account from one trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. #cat .rhost Doctor #cat /etc/host.equiv Doctor root For example, Doctor would be the solaris hostname and root would be the account. This leaves a big security hole, so I only activate it when I am doing backups for about 4-5 hours each month. Maybe someone on the list can help with the RSA since I am fairly new in that field also Dan Duane Powers [EMAIL PROTECTED] wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, Hi, guys. Here's what I've got: -- terminal copy start: -- $ ssh -v SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0. -- terminal copy snip -- $ man ssh SSH(1) System Reference Manual SSH(1) NAME ssh - OpenSSH secure shell client (remote login program) -- terminal copy snip -- DESCRIPTION -- terminal copy snip -- SSH protocol version 1 -- terminal copy snip -- As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal- lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. -- terminal copy snip -- -- terminal copy end: -- I also suggest re-reading the ssh-keygen(1) manual page. To use RSA/DSA authentication you need to generate a personal log-in key pair (via ssh-keygen). Then, copy your public key to the remote machine's $HOME/.ssh/authorized_keys for RSA or $HOME/.ssh/authorized_keys2 for DSA where $HOME is the home directory for the user as who you want to log in on the remote machine. After this step, assuming the other configuration is fine, an $ ssh -l remote_user_name remote_host_name should be about enough to log in to the remote machine. A piece of advice: if you want security, read all the manual documentation you have about ssh. Good luck, -- Pavel M. Penev
RE: SSH and RSA
-Original Message- From: Duane Powers [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2001 7:37 AM To: Mike Dresser Cc: debian-security@lists.debian.org Subject: Re: SSH and RSA Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Duane, Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; from=10.0.0.1,command=uptime 1024 3513948513452723553495234978502397465902 3475923475089234758907234057564387523487589234750234765079234658079623457862 34076 9510950293476590175907234650934234948571390874534925902345907623490562347895 63892 4765923876589237465892374659389234752348907569234590234579013465978234658972 34658 9762349856239487562347896 Bilbo Baggins 1024 35 139485134527235534952349785023974659023475923475089234758907234057564 3875234875892347502347650792346580796234578623407951095029347659017590723465 0934 2349485713908745349259023459076234905623478956389247659238765892374658923746 5934 8923475234890756923459023457901346597823465897234658976234985623948756234789 6 Joe Random 1024 35 139485134527235534952349785023974659023475923475089234758907234057564 3875234875892347502347650792346580796234578623407951095029347659017590723465 0934 2349485713908745349259023459076234905623478956389247659238765892374658923746 5934 8923475234890756923459023457901346597823465897234658976234985623948756234789 6 Jayne Eyre Each line in this file contains some directives (as in the first entry above (from=, command=), a public key (starts with 1024 35 XXX in the examples above), and a comment, usually the name or email address of the person who generated it. Remove any appearing to belong to the previous admin. Those containing a command=... directive will only be able to execute that command and so may be related to automated processes. To add your own key first generate it (possibly on your workstation if you are sure it is well secured) using ssh-keygen. Make sure you use a passphrase. A command like; ssh-keygen -b 1024 -f .ssh/identity -C Joe New Admin should suffice. Make sure that the generated .ssh/identity is not readable by any but you and shouldn't be writeable by anybody. Now copy the file .ssh/identity.pub onto all of the machines running SSH and add it to the end of ~root/.ssh/authorized_keys on each machine. You can do this using scp or even a cut-and-paste via ssh. Make sure that you do not split the line up when adding it to authorized_keys. This will give you RSA keypair authentication to all of those machines instead of password access. I would also recommend creating a non-root account to log in with and totally disallow root logins. You would be able to simply move the authorized_keys file to the non-root .ssh directory. -- Andrew J. Stephen Network Operations Manager The important thing about standards is to have them. -- Bruce Schneier, creator of the Twofish algorithm A couple of quick notes, I just realized that by trying to be cute and putting my comments in angle brackets, those among us who may read html mail, may not be able to see my comments (my bad). And second, I saw him login once, he was prompted for his RSA key as follows: (to the best of my recollection) ssh [EMAIL PROTECTED] enter RSA passkey: # remote prompt Duane Powers wrote: Hi all, Recently I was made administrator over a dozen Solaris boxen heh The prior admin was offsite and used ssh with rsa keys to access the boxes. He allowed root login, and used the RSA key functionality to keep the root password safe. I am not as mature as he was regarding ssh newbie and have only used ssh as a plug in replacement to telnet, I tend to not set a different p/w during ssh-keygen and simply access the boxes as follows: ssh -l me hostname then I login using the normal p/w that is local to the box. I have found that he did not need to transmit the local password over the tunnel, but rather used RSA to verify his identity, but I can't find documentation on how to do it. man ssh, man ssh-agent, man ssh-add, Practical UNIX Internet Security does anyone have any information on how I can implement the same safeguards? Or where I can at least find some documentation on practical ssh implementation. As always, You guys are great, thanks in advance for the help, ~duane -- The plan was simple. Unfortunately, so was Bullwinkle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.
Debian or Linux 7???
Hi! I am frustrated with the linux 2.2 kernel. I have had two hacks in 3 months and I am going broke rebuilding my server. I went out and bought Redhat 7, and got hacked 6 weeks later. I have been placed in contact with a guy who wants me to use Debian. But if it based upon the same kernel as redhat, how is it going to be more secure? I checked and found that from (http://www.securityfocus.com/) Security risks for years: 1997-2000 respectively: Debian 3, 2, 32, 45, 12 RedHat 6, 10, 49, 85, 20 So Debian is about twice as good as redhat, but that is not real reassuring. I am considering joining the debian family, but am a bit concerned about security. Just how much more secure is Debian than redhat? Thanks! Steve Rudd
Re: Debian or Linux 7???
Just how much more secure is Debian than redhat? Security comes from knowing how to use and administrate Unix, it doesn't just fall into your lap at the press of a button. If you want a secure OS you have to work for it and understand what you're doing. Debian is no more secure than Redhat is no more secure than Solaris is no more secure than OpenBSD. We could make a lot of vague generalizations about default setup and what-not but its really just a waste of time. If you don't want to be hacked, learn how to prevent it. -- Jamie Heilman http://audible.transient.net/~jamie/ Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution. -Sathington Willoughby
Re: SSH and RSA
Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen (you might want to move it out of the way till you're set up though) and start from scratch. As the admin you want to know who can get in as root on your machines. Besides script kiddies of course :-) There was a good mini HOWTO kind of posting on debian-user a while back that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.html Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: Debian or Linux 7???
It might be more secure, because the packages chosen for distribution or often more tested - not the latest versions with brand new bugs but (somewhat) older packages with known bugs removed. I would also have to add: I find it easier to keep Debian secure because it is easier to get and install updated packages with Debian than with Redhat. Typing 'apt-get install package' beats digging around Redhat's FTP site hands down... and switching would be worthwhile even just for that. I have been hacked myself twice in the past two years while running RedHat systems, and it was because I was not diligent enough in the way I kept up with security updates. Get Debian, read the HOWTOs to get an idea how to secure it, and then stay on the security annoucement mailing list. That really should get you most of the way there... (Just my $0.02, anyway) KEN
Re: Debian or Linux 7???
Steve Rudd wrote: Hi Steve, It's not just the kernel that can get hacked. Is it Linux 7 or Redhat 7 ? (I'm pretty sure it's Redhat 7). Anyway, I'm pretty new to Debian and Linux so anyone please feel free to correct me. An example of the different methodologies between Redhat and Debian: the stable version of Debian doesn't use the latest kernel; it hasn't been tested enough yet (I assume). I heard that Redhat and Mandrake (no offense, I like all Linuxes) act a bit like capitalist companies; they want their product to be popular, so they throw in all the latest stuff, sacrificing some stability and security (by not testing enough) for the edge!, having the most popular product. I think that about sums up the security differences between Debian and most other distros. I believe the Debian maintainers and developers take a more methodical, technical view of things. --- A cool thing about Debian is the super control it gives you about what runs on your box and what it can access. I think it actually sacrifices user friendliness (for newbies like me) in exchange for control. I tried Corel Linux last week (which is kind of based on Debian) and it installed everything without me typing more than my name, hitting next, next, next. It did a pretty good job, it only missed my sound card! But I didn't know what it had installed on my machine, and exactly what it was doing! I recently read the Secure Install thread in this group and tried it. I killed Corel, and re-installed from the CD and just exited out of DSelect. (I discovered by the way that you should at least select the 6) Remove... option before exiting, so it can remove the pcmcia packages). Anyway, after that I installed things as I desired with apt-cache search and apt-get install. (Thank you developers of apt-setup, and apt-cdrom!). The point is, by installing packages one at a time, and checking things after, I could keep great control of everything on my machine. I also know what modules are loading from, /etc/modules.conf and /etc/modules. I also know what services are running in different run levels from the /etc/rc2.d and other directories. It's so cool. I'm not an expert on security, I've never been hacked or virused since I started Linux about a year ago! (Practically all of my MS friends have had viruses though!) Enough blurb... GBY
Re: SSH and RSA
Olaf Meeuwissen wrote: Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote:You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want,and he'll still be able to connect, assuming he can get to themachine via your network/internet.Mike has an exceptionally pertinant point here.Right now - even before you start trying to load your own RSA keyin, log into all machines running SSH and remove the previous adminskey from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen(you might want to move it out of the way till you're set up though)and start from scratch. As the admin you want to know who can get inas root on your machines. Besides script kiddies of course :-)There was a good mini HOWTO kind of posting on debian-user a whileback that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.htmlHope this helps, Thanks all for the prompt responses... The url and the advice helped immensely, I got it working. thanks -- D U A N E P O W E R S [EMAIL PROTECTED]The plan was simple. Unfortunately, so was Bullwinkle.
Re: Debian or Redhat 7???
To quote Steve Rudd [EMAIL PROTECTED], # Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have # been maintaining my own box from a su level for about 3 months. That is why # I was calling in an expert to install Debian tomorrow. It has become quite # obvious to me that I am way over my head in trying to get my server secure. That may be the case... Let me tell you something from my own experience. I've done tech support for going on twelve years, off and on. I'm not talking about customer tech support ... I'd call myself an admin, but I'm more of a troubleshooter. Of course, I have friends and family I always lend a hand to. Anyways, you seem fairly secure with yourself, so you probaly don't need to hear this, but I can't be sure, so I'll say it anyways. I'd say, without a doubt, 90% of the people I've ever met can get a $60,000 CDN a year job working with computers, with just a bit of tutelage. Usually I only need to work with a complete computer-illiterate person before they have the basic skills necessary to troubleshoot a problem. After that, the only thing you can get is experience. Anyways, I strongly encourage you to continue asking questions on the list here, in the #debian IRC channel on irc.openprojects.net, and to your friends. After a few months, if you're willing to put in the effort, you'll probably have enough general knowledge to start reading (and understanding!) various HOWTOs and program documentation packages. At that point, the only thing holding you back would be the amount of time you could spend reading and learning. Anyways, it's always best to administer your own box. Failing that, it's best to have a full-time admin, who's responsible for your box. Anyways, have fun :) David Barclay Harris, Clan Barclay Aut agere, aut mori. (Either action, or death.)
Realserver 8 Webinator on Debian
Steve here, I want to install Real Basic Server 8 and Webinator search program on the latest version of Debian 2.2r2. 1. Will they install or are they not compatible. For example, while Webinator would work with Redhat 7, Realserver 8 would not. (But Real Server 7 did install on Redhat 6) 2. Do these programs pose any security risk. For example, Realserver uses several port addresses for administration. Steve
Re: Debian or Redhat 7???
I've been loosely foloowing this thread, and hope you have the best of luck locking down. A few places to start with the inetd.conf file. You probably don't need any of those services. Install ssh. Setup your apt sources.list to check for deb http://security.debian.org stable/updates main contrib non-free but you may want to use a mirror, so they don't get nailed. basically, each line in the sources.list has a list of packages, and they look to see who is the newest and install that puppy. those are a coupla basic steps to locking down your box. Others include not running named cux it's often a problem...I have no doubt that there are crackers out there with several named and sendmail holes in their pocket. That haven't been exposed before. So if you run mail, check out qmail. IMHO. Don't have key services run as root, like your webserver if that is key. That way if you get compromised they still need to work for root. have a nice day rick On Mon, 19 Feb 2001, Steve Rudd wrote: Steve here, Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have been maintaining my own box from a su level for about 3 months. That is why I was calling in an expert to install Debian tomorrow. It has become quite obvious to me that I am way over my head in trying to get my server secure. But I would also like to say that I was humbled by the sheer volume of caring replies. I want to say that I have taken note of all of them and thank you. My personal/superficial conclusions to my own questions based upon your replies is that Debian (as a software package) is a little more secure (for a variety of reasons), than Redhat 7. But the biggest factor is me getting pro help by someone who knows what he is doing. Done! There is one primary reason why I would have chosen Debian over Redhat in the first place. The auto-update feature. I was on line for the Redhat Network. It never notified me of anything. Even now, after being hacked, is gives me those nice smiley icons saying all is ok! g For me to get the box set up, then issue a one line command as the SU via CRT program in SSH mode, to update is breathtakingly attractive! Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Redhat 7???
On Mon, Feb 19, 2001 at 07:13:40PM -0800, Rick Rezinas wrote: I've been loosely foloowing this thread, and hope you have the best of luck locking down. A few places to start with the inetd.conf file. You probably don't need any of those services. Install ssh. Setup your apt sources.list to check for deb http://security.debian.org stable/updates main contrib non-free but you may want to use a mirror, so they don't get nailed. There are no mirrors of security.debian.org (or shouldn't be) for security reasons. This way the authenticity of security packages can be better controlled. - Tal basically, each line in the sources.list has a list of packages, and they look to see who is the newest and install that puppy. those are a coupla basic steps to locking down your box. Others include not running named cux it's often a problem...I have no doubt that there are crackers out there with several named and sendmail holes in their pocket. That haven't been exposed before. So if you run mail, check out qmail. IMHO. Don't have key services run as root, like your webserver if that is key. That way if you get compromised they still need to work for root. have a nice day rick On Mon, 19 Feb 2001, Steve Rudd wrote: Steve here, Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have been maintaining my own box from a su level for about 3 months. That is why I was calling in an expert to install Debian tomorrow. It has become quite obvious to me that I am way over my head in trying to get my server secure. But I would also like to say that I was humbled by the sheer volume of caring replies. I want to say that I have taken note of all of them and thank you. My personal/superficial conclusions to my own questions based upon your replies is that Debian (as a software package) is a little more secure (for a variety of reasons), than Redhat 7. But the biggest factor is me getting pro help by someone who knows what he is doing. Done! There is one primary reason why I would have chosen Debian over Redhat in the first place. The auto-update feature. I was on line for the Redhat Network. It never notified me of anything. Even now, after being hacked, is gives me those nice smiley icons saying all is ok! g For me to get the box set up, then issue a one line command as the SU via CRT program in SSH mode, to update is breathtakingly attractive! Steve -- 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] -- - Tal Danzig [EMAIL PROTECTED] | Libranet Linux http://tal.thepenismightier.net | http://www.libranet.com -
Re: Debian or Redhat 7???
It may get too heavy to not mirror the security update packages. Why don't we put signature verification into apt and dpkg and mirror everything ? And perhaps have a tool that checks a bunch of known mirrors for discrepencies in the keyring packages ? And have a single URL, location aware, load balancing server ? :) (I know we've been through this before. I just had a brainwave and wanted to see if anyone was interested in doing the above. Sorry for the lack of realism, but not for the extra zeal) GBY Tal Danzig wrote: There are no mirrors of security.debian.org (or shouldn't be) for security reasons. This way the authenticity of security packages can be better controlled. - Tal
Anti Virus for Debian
Are there any gpl or similar anti-virus programs for linux ? Any reccomendations ? GBY
Re: Anti Virus for Debian
On Tue, Feb 20, 2001 at 04:41:02PM +1300, Matthew Sherborne wrote: Are there any gpl or similar anti-virus programs for linux ? If you mean filters that can scan incoming email and search for Windows or maybe Mac viruses, then yes, they exist, but I don't know of any released under the GPL. McAfee and other anti-virus companies make server side scanners that run on Unix (and Linux). They're both commercial and very expensive. If you mean anti-virus stuff to actually scan for Linux viruses, then no, I don't think any exist at all, GPL or otherwise. There has never been enough of a significant virus threat under Unix or Linux to warrant such a thing. However, you might want to look in to intrusion detection tools such as tripwire (www.tripwire.org). Tripwire constructs a database of info about every file on your system and can be used to search for changes in files. This can let you know if you've been the victim of a crack or worm or something. As with all tools like this, it can only do its job if you use it right. Read the docs...all of them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpIWHGu1cyY9.pgp Description: PGP signature
Re: Debian or Redhat 7???
On Tue, Feb 20, 2001 at 04:39:09PM +1300, Matthew Sherborne wrote: It may get too heavy to not mirror the security update packages. Why don't we put signature verification into apt and dpkg and mirror everything ? Sounds to me like a good idea; however, it would probably mean rather extensive changes to both apt and dpkg. This would in my opinion be the ideal solution, but then again I'm not the one who would be doing all the work :) - Tal -- - Tal Danzig [EMAIL PROTECTED] | Libranet Linux http://tal.thepenismightier.net | http://www.libranet.com -
Re: Debian or Redhat 7???
This may help you as well. http://www.securityportal.com/lasg/ http://www.cert.org/ Steve here, Well first, I repent of calling Linux 7: Redhat 7. Yes I am new. I have been maintaining my own box from a su level for about 3 months. That is why I was calling in an expert to install Debian tomorrow. It has become quite obvious to me that I am way over my head in trying to get my server secure.
Unknown file in login on proftpd 1.2.0pre10-2potato1
Hi, I've just found that an anonymous ftp connection to my box whould leave a file $FTPROOT/var , whose u/gid is ftp/nogroup, the same as proftpd. I'm using Debian 2.2 with proftpd 1.2.0pre10-2potato1 on an i386, and this didn't happen before I do an 'apt-get upgrade' some time ago. And while I was trying to close the daemon I found that a '/etc/init.d/proftpd stop' won't work. I have to manually kill the process. I had the daemon killed for now. What should I do to make sure that the daemon is safe? pm5
Re: Unknown file in login on proftpd 1.2.0pre10-2potato1
Poe-Min Oliver Wu wrote: Hi, I've just found that an anonymous ftp connection to my box whould leave a file $FTPROOT/var , whose u/gid is ftp/nogroup, the same as proftpd. I'm using Debian 2.2 with proftpd 1.2.0pre10-2potato1 on an i386, and this didn't happen before I do an 'apt-get upgrade' some time ago. Actually, we just noticed the exact same thing on one of our servers, running the exact same version of proftpd. There are now 30 of these files in different people's homedirectories. They are all owned by the user owning that directory; I guess this is because we are running with DefaultRoot ~. All files have the exact same size, 1932 bytes. Almost all of them are full of nulls, except for one which contains a few readable words, seeming to come from the proftpd logs. My guess is that it's a small bug in proftpd that dumps some internal data, and has no security implications. But since you can't be too sure, it would be interesting to see what other people have to say about this. Maarten Vink -- Williams and Holland's Law: If enough data is collected, anything may be proven by statistical methods.
OpenSSH and CVS
I'm running Debian on a CVS server and have Debian clients. We're using OpenSSH to replace the rsh calls in CVS. The problem is that every time a cvs user makes a CVS call (like cvs diff file), they have to enter my password. I know there's a way around this, but I can't find clear documentation. Anyone have a similiar experience? -- Matt Ray [EMAIL PROTECTED]
Re: OpenSSH and CVS
Matthew H. Ray wrote: I'm running Debian on a CVS server and have Debian clients. We're using OpenSSH to replace the rsh calls in CVS. The problem is that every time a cvs user makes a CVS call (like cvs diff file), they have to enter my password. I know there's a way around this, but I can't find clear documentation. If you don't want to enter passwords then you could use RSA keys. (man ssh) However you say - enter my password - that smacks of misconfiguration as they should be entering *their* passwords, not yours. Don't expect any system which uses a single account shared among many users to be secure. Also, if you have any wincvs users be sure you set your CVSROOT to something that a) includes the :ext: protocol hint, and b) doesn't include the username. I have found through experience that wincvs is pretty picky about those things, where unix clients aren't. For example a good CVSROOT is :ext:mycvsserver:/mycvs/root/path where as a bad one which will almost certainly make wincvs choke (these get stored in the CVS control files remember) is [EMAIL PROTECTED]:/mycvs/root/path. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy
