I have a host set up at a remote site in another state. I'm working to make it as secure as I can, so if you guys don't mind I'd like to run a brief description of the system by you and ask for your opinion of where I stand.
Here's a description of the system.
> Fedora 7 with all updates on Pentium 4 > Connected to the Internet > Services available: httpd, sshd, pop3d, sendmail > No rsh or rlogin (disabled in /etc/xinetd.d) > No FTP; only SFTP (FTP over SSH) allowed, and no anonymous access.
This host has only three remote users, all trusted (myself and two others). None are allowed to run any executable programs or scripts (that's not enforced by anything on the host, but I trust them sufficiently to not do it that I'm not concerned about it).
Any time anyone logs in, I get an email alert on my cell phone telling me who it is and from what IP.
sshd is restricted to certain IPs in hosts.allow... big pain in the ass, because the other two users have dynamic IPs and every time their IP changes they can't get in anymore... :-(
pop3d and sendmail are available in hosts.allow (sendmail is configured to disable relaying from untrusted hosts).
httpd is available to all (but, it's usually shut down unless we need it).
hosts.deny says ALL: ALL so if it's not listed in hosts.allow, it's not allowed in.
Telnet is available to two specific hosts only, and is used only for emergencies (sshd seems to shut itself down occasionally... been an issue with Linux for many of the distros I've used... so every few months or so I have to telnet in from one of the two trusted hosts and restart sshd).
Myself and the other two meed to be able to remotely access this thing, no way around it, so we have to keep it connected to the net.
What else can I do to keep this thing secure?
Les réponses au message de Eric (reply.in.group@nospam.no)
On 28 Jul, 15:50, Eric wrote: > sshd is restricted to certain IPs in hosts.allow... big pain in the ass, > because the other two users have dynamic IPs and every time their IP > changes they can't get in anymore... :-(
These ssh worms are a pain - considered using a port knocking script? Running on a different port? If you're really concerned about security you should disable root logins, constrain access to a nominated group and / or enforce keypair logins.
For the dynamic addresses - considered using address names in tcp wrappers and dynamic DNS? Sure its not 100% but neither is using an IP address.
> pop3d and sendmail are available in hosts.allow (sendmail is configured to > disable relaying from untrusted hosts).
If you're allowing POP access then users are sending their passwords in clear text - that's a problem. I'd suggest running stunnel in a chroot jail to proxy. It'd probably make sense to use your own CA or constrain access to known client certs.
> httpd is available to all (but, it's usually shut down unless we need it). > hosts.deny says ALL: ALL so if it's not listed in hosts.allow, it's not > allowed in.
...provided the service uses tcp wrappers.
> Telnet is available to two specific hosts only, and is used only for > emergencies (sshd seems to shut itself down occasionally... been an issue > with Linux for many of the distros I've used... so every few months or so > I have to telnet in from one of the two trusted hosts and restart sshd).
hmmm. You could route the Telnet through stunnel too.
> What else can I do to keep this thing secure?
Run a host based IDS like l5 or tripwire. It doesn't make it more secure but its very useful for detecting when your security is not working and determining how to get back where it should be.
On Sat, 28 Jul 2007, in the Usenet newsgroup comp.os.linux.security, in article , Eric wrote:
>sshd is restricted to certain IPs in hosts.allow... big pain in the ass, >because the other two users have dynamic IPs and every time their IP >changes they can't get in anymore... :-(
Several choices - are they always in the same _range_ of IPs? My home setup allows SSH from just 2825 addresses (a /21, 3 /24s and 9 /32s) world wide. As there are something like 2.509 billion IPv4 addresses currently allocated/assigned by the RIRs, this does narrow the gate a bit. Another choice would be to use a port-knocking technique where they must first attempt to connect to a specific closed port (the firewall notes this attempt, and opens another port where the SSHD is actually listening, for a minute - they STILL have to authenticate by what-ever technique you are using now once they connect to the server).
>pop3d and sendmail are available in hosts.allow (sendmail is configured >to disable relaying from untrusted hosts).
I's prefer these to only be accessible through a secure tunnel. Hate to tell you how often I've been able to use a simple packet sniffer to identify users. Username and passwords in the clear - my, my, my.
>hosts.deny says ALL: ALL so if it's not listed in hosts.allow, it's not >allowed in.
but only if that service is using tcp_wrappers, or is compiled with libwrap. Most are not. Use the firewall instead.
>Telnet is available to two specific hosts only, and is used only for >emergencies (sshd seems to shut itself down occasionally... been an issue >with Linux for many of the distros I've used... so every few months or so >I have to telnet in from one of the two trusted hosts and restart sshd).
I'd strongly recommend you find out exactly what is shutting down the server. You have something wrong, as this should not happen.
>Myself and the other two meed to be able to remotely access this thing, >no way around it, so we have to keep it connected to the net.
That's what the SSH is for.
>What else can I do to keep this thing secure?
Depends on how paranoid you are, what your threat model is, and how much complexity you want to add. One time passwords could be added, but additional complexity usually increases the chance of shooting yourself in the wobbly bits.
On Sun, 29 Jul 2007 17:10:58 -0500, Moe Trin wrote:
> Several choices - are they always in the same _range_ of IPs?
Good evening, Moe.
Not always. I have opened up a /24 range for each IP that one of the other two normally logs in from. Sometimes their ISP gives them something from a neighboring /24, so I open that one up too.
>>pop3d and sendmail are available in hosts.allow (sendmail is configured >>to disable relaying from untrusted hosts). > I's prefer these to only be accessible through a secure tunnel. Hate to > tell you how often I've been able to use a simple packet sniffer to > identify users. Username and passwords in the clear - my, my, my.
Yes, I actually mis-wrote. pop3d is not enabled on that machine, only sendmail is enabled for sending mail out (it is configured to send me mail in response to a number of different events). Any mail that comes in on that machine is relayed back out again to our real email addresses.
> Use the firewall instead.
I do have the firewall running but I'm not sure I have it configured correctly... but that's another issue for another RTFM session. :-)
> I'd strongly recommend you find out exactly what is shutting down the > server. You have something wrong, as this should not happen.
I actually don't believe it has happened on FC6 or F7. Used to happen occasionally on FC2 and some earlier releases like RH8.
> Depends on how paranoid you are, what your threat model is, and how much > complexity you want to add. One time passwords could be added, but > additional complexity usually increases the chance of shooting yourself > in the wobbly bits.
Pretty paranoid, but not paranoid enough for one-time passwords. :-)
Thanks for the suggestions, I will look into them especially the firewall one.
Thanks, Colin. Port knocking is a new one on me, will have to research that. As for POP access, I mis-wrote... I'm not allowing POP access on that machine. "host based IDS like l5 or tripwire"... hmmm, I've used tripwire in the past but the rest of it is new to me... guess I have some more reading to do... :-)
On Sun, 29 Jul 2007 13:49:42 +0000, C. wrote:
> On 28 Jul, 15:50, Eric wrote: >> sshd is restricted to certain IPs in hosts.allow... big pain in the ass, >> because the other two users have dynamic IPs and every time their IP >> changes they can't get in anymore... :-( >> These ssh worms are a pain - considered using a port knocking script? > Running on a different port? If you're really concerned about security > you should disable root logins, constrain access to a nominated group > and / or enforce keypair logins. > For the dynamic addresses - considered using address names in tcp > wrappers and dynamic DNS? Sure its not 100% but neither is using an IP > address. >> pop3d and sendmail are available in hosts.allow (sendmail is configured to >> disable relaying from untrusted hosts). >> If you're allowing POP access then users are sending their passwords > in clear text - that's a problem. I'd suggest running stunnel in a > chroot jail to proxy. It'd probably make sense to use your own CA or > constrain access to known client certs. >> httpd is available to all (but, it's usually shut down unless we need it). >>> hosts.deny says ALL: ALL so if it's not listed in hosts.allow, it's not >> allowed in. >> ...provided the service uses tcp wrappers. >> Telnet is available to two specific hosts only, and is used only for >> emergencies (sshd seems to shut itself down occasionally... been an issue >> with Linux for many of the distros I've used... so every few months or so >> I have to telnet in from one of the two trusted hosts and restart sshd). >> hmmm. You could route the Telnet through stunnel too. >> What else can I do to keep this thing secure? > Run a host based IDS like l5 or tripwire. It doesn't make it more > secure but its very useful for detecting when your security is not > working and determining how to get back where it should be. > C.
> I have a host set up at a remote site in another state. I'm working to > make it as secure as I can, so if you guys don't mind I'd like to run a > brief description of the system by you and ask for your opinion of where > I stand. > Here's a description of the system. >> Fedora 7 with all updates on Pentium 4 Connected to the Internet >> Services available: httpd, sshd, pop3d, sendmail No rsh or rlogin >> (disabled in /etc/xinetd.d) No FTP; only SFTP (FTP over SSH) allowed, >> and no anonymous access. > This host has only three remote users, all trusted (myself and two > others). None are allowed to run any executable programs or scripts > (that's not enforced by anything on the host, but I trust them > sufficiently to not do it that I'm not concerned about it). > Any time anyone logs in, I get an email alert on my cell phone telling > me who it is and from what IP. > sshd is restricted to certain IPs in hosts.allow... big pain in the ass, > because the other two users have dynamic IPs and every time their IP > changes they can't get in anymore... :-( > pop3d and sendmail are available in hosts.allow (sendmail is configured > to disable relaying from untrusted hosts). > httpd is available to all (but, it's usually shut down unless we need > it). > hosts.deny says ALL: ALL so if it's not listed in hosts.allow, it's not > allowed in. > Telnet is available to two specific hosts only, and is used only for > emergencies (sshd seems to shut itself down occasionally... been an > issue with Linux for many of the distros I've used... so every few > months or so I have to telnet in from one of the two trusted hosts and > restart sshd). > Myself and the other two meed to be able to remotely access this thing, > no way around it, so we have to keep it connected to the net. > What else can I do to keep this thing secure?
Use RSA authentication and disallow password authentication. You put the public keys of your trusted users into ~/.ssh/authorized_keys which allows them and only them to log in to their accounts. If you do it this what you won't have to worry about IP addresses. It's virtually impossible for someone to guess a public/private key combination. You will still the password guessing programs trying to break in but they're attempts will be futile because you've disallowed password access. If you want to hide your system from the password guessers then you can move the port number from 22 to something else. The password guessing programs all attack port 22 so using a different port makes you invisible to them. The only problem with using a different port is that the outgoing firewalls at many big companies restrict ssh traffic to port 22, but if your users are all at home or small offices this isn't an issue.
There is no reason to have telnet on the system at all, ssh does everything that telnet does. You should remove the legacy services RPM, you don't need it and it's a security problem.
On Sun, 29 Jul 2007, in the Usenet newsgroup comp.os.linux.security, in article , Eric wrote:
>Moe Trin wrote:
>> Several choices - are they always in the same _range_ of IPs? >Good evening, Moe.
Hi
>Not always. I have opened up a /24 range for each IP that one of the >other two normally logs in from. Sometimes their ISP gives them >something from a neighboring /24, so I open that one up too.
That's really an experience item. If you are trying to avoid skript kiddiez, and there is only the three of you actually allowed to connect, moving the server to a different port (some random value above 1050 to avoid port-scanners) is a very simple barrier.
>Yes, I actually mis-wrote. pop3d is not enabled on that machine, only >sendmail is enabled for sending mail out (it is configured to send me >mail in response to a number of different events). Any mail that comes >in on that machine is relayed back out again to our real email addresses.
I'd be really careful about that - the relay should only go to you (more a forward than a relay) no matter what the "original" envelope To: (or even body To:) says.
>I do have the firewall running but I'm not sure I have it configured >correctly... but that's another issue for another RTFM session. :-)
tcp_wrappers (and libwrap) work a little different from the firewall, in that they allow a connection - just not to the desired daemon. They are much easier to understand. But the firewall is more robust and may be easier to configure. What can I say? As for docs, most people recommend Rusty Russell's (author of the firewall code) "unofficial" HOWTOs - find those at http://www.netfilter.org/documentation/HOWTO/
>> I'd strongly recommend you find out exactly what is shutting down the >> server. You have something wrong, as this should not happen. >I actually don't believe it has happened on FC6 or F7. Used to happen >occasionally on FC2 and some earlier releases like RH8.
Never ran FC2, but never saw the problem on RH8.0. I'd try running a (perhaps daily) cron job to check on things - maybe a 'ps awx | grep' and 'netstat -atpn | grep' (where the grep looks for the process name if running stand-alone, or the appropriate wrapper daemon if not) to try to narrow it down.
>Pretty paranoid, but not paranoid enough for one-time passwords. :-)
They can be a real joy to try to set up, but once they're working right, they're pretty bullet-resistant. RSA authentication may be simpler to get going however.
Old guy
Vulnerabilite.com ne peut être tenu responsable des propos tenus dans le Newsgroup comp.os.linux.security
Message de C. (colin.mckinnon@gmail.com) (29 Juillet 2007)
