Re: Re: [SLUG] General question Re: Securing Redhat Linux IS: question re: sshd
Can you explain why you exclude sshd? Buffer overruns ? ;-) Properly protected from the outside it should be OK though. Chris -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
If you spend enough time on it you can convince yourself that any box is secure. Secure systems is one area where debian excels though. Debian packaging policy means that old, reliable software is used in favour of newer, possibly more functional, but possibly also less secure software. NB: This is not a Debian bash, I've just got very little (tending to zero) experience of it. I would hope that Debian, whilst keeping to more elderly software, back-ports security fixes to their distribution ? Also, given that some software releases happen because of security fixes, you may well find that older software is not always more secure. I remember the old sendmail bug of the month club times, where those unlucky enough to still be using that MTA would be updating their software on a fairly regular basis to try and keep up-to-date with the fixes. Fortunately we were using Smail, and then Qmail. :-) cheers, Chris -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: WAS: Re: [SLUG] General question Re: Securing Redhat Linux
If there is no port for them to logon to then how can they gain access unless they are a local user? Buffer overruns in your IDS or libpcap ? :-) Chris -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
quote who=Chris Samuel I would hope that Debian, whilst keeping to more elderly software, back-ports security fixes to their distribution ? Like, totally. http://lists.debian.org/debian-security-announce/debian-security-announce-2002/threads.html (If you go back in the LWN archives, there's a comparison between distro security practices. It's a bit different now, because Red Hat have improved enormously, but Debian was on top back then, and I'd be surprised if they weren't still there, or nearby, now.) - Jeff -- Love never misses the chance to put the boot in. - Kelly, SLOU -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
Quoting Chris Samuel [EMAIL PROTECTED]: If you spend enough time on it you can convince yourself that any box is secure. Secure systems is one area where debian excels though. Debian packaging policy means that old, reliable software is used in favour of newer, possibly more functional, but possibly also less secure software. NB: This is not a Debian bash, I've just got very little (tending to zero) experience of it. I would hope that Debian, whilst keeping to more elderly software, back-ports security fixes to their distribution ? security fixes for anything on the current stable release are always available on security.debian.org for example :) -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
RE: [SLUG] General question Re: Securing Redhat Linux
This is true. But where do you stop. What happens if somebody hacks login and starts sending your keystrokes over the net ? or iptables which tricks you into believing everything is being blocked properly, or one of your cron scripts ? :) And I need a way to monitor file system changes. I could write my own `find' script, and hide it in some obscure directory that wouldn't be noticed, and hire somebody at $0.05/hr to log in and run it manually everyday, and then delete ~/.bash_history :) I think it's safe to say that once a hacker gets root, you're finished. At the moment, I'll try to make things as secure as I can, and when I get hacked again hopefully I'll have more experience to build a more secure box. I'll probably use Debian the 3rd or 4th time around. _Anything_ is better than what I had :) I didn't take security seriously before because it was too time consuming and I was busy learning other things. This new found attitude and motivation will benefit me in the long run :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Gregory Sent: Wednesday, 18 December 2002 13:22 To: Minh Van Le Cc: [EMAIL PROTECTED] Subject: Re: [SLUG] General question Re: Securing Redhat Linux [snip] btw - you wanna be careful with tripwire et al. What happens when someone hacks your box and replaces the tripwire executable with one that sends an email at the alotted time intervals reporting that everything is ok? It's better than nothing, but don't rely on it. HTH James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
RE: WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS: question re: sshd
Or just plug the monitor keyboard in :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Fox Sent: Wednesday, 18 December 2002 8:48 To: Kevin Saenz Cc: Graeme Robinson; Minh Van Le; [EMAIL PROTECTED] Subject: Re: WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS: question re: sshd Quoting Kevin Saenz [EMAIL PROTECTED]: [snip] I guess a little too paranoid indeed. I couldn't live without sshd, since every machine I've ever installed is completely headless. However if I couldn't have sshd, I'd be just as happy to tweak the kernel and hook up a serial cable to be a console from another machine with has a terminal client and/or old wyse terminal :) -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
On Thu, 19 Dec 2002 00:07:19 +1100 Minh Van Le [EMAIL PROTECTED] wrote: And I need a way to monitor file system changes. I could write my own `find' script, and hide it in some obscure directory that wouldn't be noticed, and hire somebody at $0.05/hr to log in and run it manually everyday, and then delete ~/.bash_history :) Free tripwire like tools include: aide, integrit, samhain. And tripwire itself for free unices. To prevent themselves being compromised you can boot from a read only floppy to do the check. Also, some (samhain?) send checksummed logs offsite immediately. Matt -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
RE: [SLUG] General question Re: Securing Redhat Linux
On Wed, 2002-12-18 at 13:07, Minh Van Le wrote: This is true. But where do you stop. What happens if somebody hacks login and starts sending your keystrokes over the net ? or iptables which tricks you into believing everything is being blocked properly, or one of your cron scripts ? :) oh sure, you use the best technology available to you. All I'm saying is don't assume that your system is secure because tripwire says so. Always augment it with something else. I think it's safe to say that once a hacker gets root, you're finished. well yes and no. It's safe to say that you don't know anything about your system post-hacking (if indeed you know it was hacked). At the moment, I'll try to make things as secure as I can, and when I get hacked again hopefully I'll have more experience to build a more secure box. I'll probably use Debian the 3rd or 4th time around. _Anything_ is better than what I had :) I didn't take security seriously before because it was too time consuming and I was busy learning other things. This new found attitude and motivation will benefit me in the long run :) your call of course. I'm not sure this next time I get hacked philosophy is the right thing to aim for though. For a home network a firewall is the most important bit. I'd recommend you proceed by setting up the best firewall you can and then running Nessus from a remote box to see if it can get in. Not foolproof but it gives you a way to gauge progress. HTH James. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Gregory Sent: Wednesday, 18 December 2002 13:22 To: Minh Van Le Cc: [EMAIL PROTECTED] Subject: Re: [SLUG] General question Re: Securing Redhat Linux [snip] btw - you wanna be careful with tripwire et al. What happens when someone hacks your box and replaces the tripwire executable with one that sends an email at the alotted time intervals reporting that everything is ok? It's better than nothing, but don't rely on it. HTH James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
RE: [SLUG] General question Re: Securing Redhat Linux
This is true. But where do you stop. What happens if somebody hacks login and starts sending your keystrokes over the net ? or iptables which tricks you into believing everything is being blocked properly, or one of your cron scripts ? :) oh sure, you use the best technology available to you. All I'm saying is don't assume that your system is secure because tripwire says so. Always augment it with something else. I agree Tripwire is not the be all and end all of anti hacking. The hacker/cracker's credo is what I can't get into today I will tomorrow. I think it's safe to say that once a hacker gets root, you're finished. well yes and no. It's safe to say that you don't know anything about your system post-hacking (if indeed you know it was hacked). If you have the time to spare and you know your systems then you can do some forensic work on your system see excatly how they got in also check to see if it was a kiddie or someone skilled in the art of cracking. I would advise anyone interested in security have a look at honeypot.net I think it is, read Lance's whitepapers. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
RE: WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS: question re: sshd
Quoting Minh Van Le [EMAIL PROTECTED]: Or just plug the monitor keyboard in :) Thats a novel plan, but as always not always possible if the machine and monitor are several rooms apart. Cheers -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] General question Re: Securing Redhat Linux
Redhat has been known to be buggy and insecure to say the least, however it is my choice amung all distributions. My question is probably a security question that applies to all OS in general: In my case, I'm setting up a firewall that is directly exposed to the internet, and will be my frontline defense against attacks and intrusions. Provided that I - install only what I need - are aware of the functions of utils/packages that I install - do not install things that can be used against me eg. compilers, sudo, screen, debugfs, dd etc. - do not install any irrelevant servers/daemons eg. httpd, ftpd, named, rpc*d etc. - keep my packages updated stable - securing any services at the application level eg. customising kernel, xinetd, /etc/security/* etc. - monitor and apply errata (redhat.com/errata/) - monitor all logs - spend some time monitoring security advisories - use network monitoring, auditing, intrusion tools eg. snort, tripwire, user space plugins for iptables - physically isolate machines and services through better network topology/structure with security in mind I think any distribution can be ironclad. The difference then would be the effort required to secure a box OS. So provided that I stick to the fundamental security concepts, am I wasting my time with Redhat compared to Debian or Slackware etc ? There're a lot of other little things that I've come to be aware of over the years eg. mount (ro) /, find / -perms +444 etc etc. I'm reading some security guides, Redhat 8.0 has an Official Red Hat Linux Security Guide (http://www.redhat.com/docs/manuals/linux) and other Redhat related security guides can be found at linuxdoc.org. Does anybody have further advice/suggestions on securing a Redhat box ? - don't use computers maybe ? :) I'm looking forward to having a less embarassing setup, and taking better security measures this time around. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
On Tue, 2002-12-17 at 14:49, Minh Van Le wrote: I think any distribution can be ironclad. I think that any distribution can be equally insecure. If you spend enough time on it you can convince yourself that any box is secure. Secure systems is one area where debian excels though. Debian packaging policy means that old, reliable software is used in favour of newer, possibly more functional, but possibly also less secure software. If nothing else debian packages are much more a known quantity than other distributions (debian stable, not unstable et al). Debian maintainers also do helpful things like disabling the no-encryption option on ssh. They also had that bug fix for ssh out before anyone else (I don't even know if that made its way into redhat etc - I assume it did but no-one made the same fuss about it that debian did) You theoretically can make redhat as secure as debian, but I would argue that your time would be better spent on more important aspects of system security. I like redhat and its bretheren, but I don't use it on servers. btw - you wanna be careful with tripwire et al. What happens when someone hacks your box and replaces the tripwire executable with one that sends an email at the alotted time intervals reporting that everything is ok? It's better than nothing, but don't rely on it. HTH James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
I have a tendency to agree with what you have there. This may be only my thoughts and someone can counter argue this point. I do install compilers on to my firewall, in case I want to compile a package mind you I never install any servers, especially either telnetd or sshd, on my firewall. If I want to make a mod to my firewall I have to do it locally. Isolate machines through topologies is excellent idea, you don't want to mix live or potentially vulnerable servers with workstations. So you will have a DMZ where you will house your servers that can access the Internet, and a LAN network which will be completely seperate to the DMZ. Even though I have 6 machines at home I have broken my network environment into DMZ, and LAN. My machines on the LAN can only access services I what them to access on the DMZ, My DMZ can only access DNZ, Web, mail, ssh services on the internet. My LAN uses NAT to access internet protocols. A Distro is a Distro, some have more issues than others but if you have a look at most of redhat issues to date most of the problems exist if the user already has access to the box and wants to elevate their privileges. Provided that I - install only what I need - are aware of the functions of utils/packages that I install - do not install things that can be used against me eg. compilers, sudo, screen, debugfs, dd etc. - do not install any irrelevant servers/daemons eg. httpd, ftpd, named, rpc*d etc. - keep my packages updated stable - securing any services at the application level eg. customising kernel, xinetd, /etc/security/* etc. - monitor and apply errata (redhat.com/errata/) - monitor all logs - spend some time monitoring security advisories - use network monitoring, auditing, intrusion tools eg. snort, tripwire, user space plugins for iptables - physically isolate machines and services through better network topology/structure with security in mind I think any distribution can be ironclad. The difference then would be the effort required to secure a box OS. So provided that I stick to the fundamental security concepts, am I wasting my time with Redhat compared to Debian or Slackware etc ? There're a lot of other little things that I've come to be aware of over the years eg. mount (ro) /, find / -perms +444 etc etc. I'm reading some security guides, Redhat 8.0 has an Official Red Hat Linux Security Guide (http://www.redhat.com/docs/manuals/linux) and other Redhat related security guides can be found at linuxdoc.org. Does anybody have further advice/suggestions on securing a Redhat box ? - don't use computers maybe ? :) I'm looking forward to having a less embarassing setup, and taking better security measures this time around. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS:question re: sshd
On 18 Dec 2002, Kevin Saenz wrote: I do install compilers on to my firewall, in case I want to compile a package mind you I never install any servers, especially either telnetd or sshd, on my firewall. If I want to make a mod to my firewall I have to do it locally. Can you explain why you exclude sshd? Sure, telnet passes clear passwords and text, but the entire sshd communication is encrypted and has been proven extremely difficult to crack, particularly where key-exchange authentication is used instead of passwords. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] General question Re: Securing Redhat Linux
I asked a similar question to this the other day ( See my post 'Learning about security'). Basically I wanted to know: If a firewall explicitly DROP's all new connections on the external (ppp0 in my case) interface, how can a cracker get access to the sshd/telnetd/httpd/whatever running on that firewall machine? The firewall does allows ESTABLISHED or RELATED connections on that inteface though. ( Ala Rusty's quick Firewall rules from the HOWTO) cheers Steve At 18 December 2002, Kevin Saenz [EMAIL PROTECTED] wrote: I never install any servers, especially either telnetd or sshd, on my firewall. If I want to make a mod to my firewall I have to do it locally. -- We live in an age of continuous partial attention. --Ms. Linda Stone, researcher and VP at Microsoft http://www.helmsdeep.net/capn-k/ Linux | Windows | CAD | Audio Visualisation and more -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS:question re: sshd
Probably I am a little too paranoid, I just don't want anyone to logon to the box at all. My theory is if there are no services open then people cannot log on to the box. My firewall is just there to forward and filter packets. I agree with you with the power of sshd. I just believe that if someone wants to get in then there is no way of stopping them. If there is no port for them to logon to then how can they gain access unless they are a local user? Yes I could use IPtables to filter the access to specific addresses and ports. I just wanted to ensure that my box was a tight as you could get it. I do install compilers on to my firewall, in case I want to compile a package mind you I never install any servers, especially either telnetd or sshd, on my firewall. If I want to make a mod to my firewall I have to do it locally. Can you explain why you exclude sshd? Sure, telnet passes clear passwords and text, but the entire sshd communication is encrypted and has been proven extremely difficult to crack, particularly where key-exchange authentication is used instead of passwords. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: WAS: Re: [SLUG] General question Re: Securing Redhat Linux IS: question re: sshd
Quoting Kevin Saenz [EMAIL PROTECTED]: Probably I am a little too paranoid, I just don't want anyone to logon to the box at all. My theory is if there are no services open then people cannot log on to the box. My firewall is just there to forward and filter packets. I agree with you with the power of sshd. I just believe that if someone wants to get in then there is no way of stopping them. If there is no port for them to logon to then how can they gain access unless they are a local user? Yes I could use IPtables to filter the access to specific addresses and ports. I just wanted to ensure that my box was a tight as you could get it. I guess a little too paranoid indeed. I couldn't live without sshd, since every machine I've ever installed is completely headless. However if I couldn't have sshd, I'd be just as happy to tweak the kernel and hook up a serial cable to be a console from another machine with has a terminal client and/or old wyse terminal :) -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
