making a home server

This is a discussion on making a home server within the Tech Board forums, part of the Community Boards category; Originally Posted by zacs7 Code: zac@mercury:~ $ uptime 14:26:08 up 206 days, 2:21, 4 users, load average: 0.17, 0.30, 0.13 ...

  1. #16
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by zacs7 View Post
    Code:
    zac@mercury:~ $ uptime
     14:26:08 up 206 days, 2:21,  4 users,  load average: 0.17, 0.30, 0.13
    That's pretty impressive!
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #17
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    using a password one character off from the previous
    I thought passwords would be encrypted.

    cyberfish@servhost:~$ cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 15
    model : 3
    model name : Intel(R) Celeron(R) CPU 2.40GHz
    stepping : 4
    cpu MHz : 2392.035
    cache size : 256 KB
    fdiv_bug : no
    hlt_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 5
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid xtpr
    bogomips : 4784.07
    clflush size : 64
    power management:

    cyberfish@servhost:~$ uptime
    20:35:54 up 144 days, 35 min, 1 user, load average: 0.00, 0.03, 0.01
    I took it down 144 days ago because I went somewhere for summer vacation and took the server (it's in a virtual machine) with me. Before that it has been running for at least 2 years.

    Apache, Postfix, SMBD in a virtual machine with snapshot backup. Host has RAID-5.

    Just upgraded from P3 to Celeron a few years ago.

  3. #18
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by MK27 View Post
    That's pretty impressive!
    From my little bubba server (mail):
    Code:
    jeffc@bubba:~$ uptime
     21:27:54 up 222 days,  7:58,  1 user,  load average: 0.13, 0.05, 0.01
    jeffc@bubba:~$
    That was when we moved house
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,725
    Quote Originally Posted by DavidP
    The baseline for SliceHost is $20, and you implied through your post that you can get something cheaper than this if you go "unmanaged".
    Slicehost is unmanaged, but it has good documentation and support.

    Quote Originally Posted by MK27
    I've been using these people since last summer:

    Xen Hosting by VPS Village


    That is the "unmanaged VPS" branch of groknet, which when I signed up it was all together and clearly delineated, which now it does not clearly refer to the fact.
    I do not know about the current state of affairs, but back when I had an account with them, GrokThis had very good support. However, if I remember correctly, I did not choose VPS Village in the end because I felt Slicehost's admin console and documentation was better. (Though in retrospect the documentation is actually more widely applicable than just Slicehost, so somewhat ironically this should not have been a factor.)

    Quote Originally Posted by jeffcobb
    3. If you like to experiment like I do you can change the SW/OS on it all you like w/o asking someone to do it.
    This should be true of any VPS as well, though your choice of OS may or may not be limited. But I guess that having physical access to the hardware is a nice feeling

    Quote Originally Posted by jeffcobb
    I only make SSH available on an as-needed basis and then its with an intense password on a non-standard port.
    Why not disable password authentication? Alternatively, use a sudoer account, disable root login via SSH, and install denyhosts.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by zacs7 View Post
    And beware of making SSH visible to the world, the amount of attacks I get even running a non-standard port is bizarre.
    Quote Originally Posted by jeffcobb View Post
    Agreed and seconded. I only make SSH available on an as-needed basis and then its with an intense password on a non-standard port.
    This is excessively paranoid. I started work last year on a dedicated server for a "medium profile" public figure. We use ssh there; I had some security concerns because of some work I was doing and wanted to discuss this with one of the other staff, who's a C++ programmer for NASA. These had nothing to do with ssh , but in any case, he said there'd been no successful, noticeable break-ins on the site in a decade.

    @zacs7: what counts as "an attack" here? some bot scanning ports? They're irritating, but I do not think they are actually attempting anything malicious beyond surveying.
    Last edited by MK27; 01-27-2010 at 08:30 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #21
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    If you did want to get a really cheap computer, I have three of the Atom based processors. The whole system only cost me $140 each (that's with a 200GB HD and 2GB memory). Here is a list of these.

  7. #22
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,738
    This is excessively paranoid.
    My thoughts as well. I used to administer some servers running Mac OS X, on which we had SSH running non-stop on the standard port.

    What about using public/private key authentication in addition to a password?
    My Website

    "Circular logic is good because it is."

  8. #23
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by DavidP View Post
    My thoughts as well. I used to administer some servers running Mac OS X, on which we had SSH running non-stop on the standard port.

    What about using public/private key authentication in addition to a password?
    I haven't studied ssh much, I thought it always used a key (which is to say, it's all "ssh keys" on the servers I've worked on).

    I guess you can just use a password. Adding a key sure seems like a way harder thing to crack.
    Last edited by MK27; 01-27-2010 at 09:06 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  9. #24
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,725
    Quote Originally Posted by DavidP
    I used to administer some servers running Mac OS X, on which we had SSH running non-stop on the standard port.
    I always do that. Although it is probably true that using a non-standard port makes you less of a target, I find it somewhat of an attempt at security through obscurity. I reason that as long as the accounts that can be accessed via SSH have good passwords (especially with denyhosts limiting the number of incorrect tries), or are restricted to key based authentication, it should be good enough.

    Quote Originally Posted by DavidP
    What about using public/private key authentication in addition to a password?
    I do not think that that makes it any more secure than just using a password. In fact, it might arguably make it less secure, since there are two things to keep secret instead of one (i.e., the password and the private key, or the password and the password protecting the private key), yet either one is enough. But if you disable password authentication and just use key based authentication, then you still have only one thing to keep secret.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #25
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by laserlight View Post
    Slicehost is unmanaged, but it has good documentation and support.

    This should be true of any VPS as well, though your choice of OS may or may not be limited. But I guess that having physical access to the hardware is a nice feeling


    Why not disable password authentication? Alternatively, use a sudoer account, disable root login via SSH, and install denyhosts.
    Re: VPS vs using your own hardware: That may be....for a control freak having physical access to the HW is nice though. Just a personality quirk plus knowing I can up my hardware anytime I need at no additional cost (as long as the hardware is lying about the house) is nice too. However I know this is not for everyone and to an extent, while this has some practical advantages, my setup has also been a fun learning experience as well, knowing I can go from bare metal to working webserver. Same thing goes for my mail server.

    Re: SSH. All good points and suggestions. As rarely as I need to do this (like once every other year) this crosses the pain threshold. I may still do this at some point but logging into the firewall and disabling the port forward rule takes seconds. Still not a good excuse for slothfulness but its the only one I have...

    ^__^

    Jeff
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  11. #26
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by DavidP View Post
    My thoughts as well. I used to administer some servers running Mac OS X, on which we had SSH running non-stop on the standard port.

    What about using public/private key authentication in addition to a password?
    The attacks are real. Here is one posting on the subject:

    Slow brute force server security - distributed slow SSH brute-force attacks - slow vs fast brute force attacks run over days or weeks and are distributed from an IP net of hundreds of IPs

    This is just one of many. It describes exactly what I was seeing. With your SSH on a standard port you are one password away from being owned. Setting a strong password here really doesn't seem paranoid.

    Further, moving the ssh to a non-standard port stopped the attempts altogether...so if I have discouraged the zombies from even trying, is that considered overly paranoid?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  12. #27
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    That article, AFAICT, is exclusively about brute force attempts to crack passwords. I do not think a brute force attack on a key is very feasible (educated guess ).

    I'm pretty inexperienced here, but I am surprised to learn anybody uses ssh without keys. I thought the whole point of ssh was the public/private key system -- otherwise you might as well just use rlogin or something.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  13. #28
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by MK27 View Post
    That article, AFAICT, is exclusively about brute force attempts to crack passwords. I do not think a brute force attack on a key is very feasible (educated guess ).

    I'm pretty inexperienced here, but I am surprised to learn anybody uses ssh without keys. I thought the whole point of ssh was the public/private key system -- otherwise you might as well just use rlogin or something.
    First, if you use a dodgy/lame key (password) then its entirely possible it will get hacked and there are folks out there actively trying this. For every one of us "paranoids" out there, there are 50 knot-heads with a password like "sekrit". The hackers are not trying to get the careful ones, they are after the idiots. Darwin in action here.

    As for the "keyless" systems there are keys and then there are keys. Two basic types of SSH keys are ones you type from the keyboard and the ones I think you are thinking of as "keyless" are the public/private keys set up so that if you issue a keyset to a remote user, they can log in simply by using their name b/c the computer is auto-supplying the stronger key. It is not meaning "leave your system wide open".
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  14. #29
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by jeffcobb View Post
    Two basic types of SSH keys are ones you type from the keyboard and the ones I think you are thinking of as "keyless" are the public/private keys set up so that if you issue a keyset to a remote user, they can log in simply by using their name b/c the computer is auto-supplying the stronger key. It is not meaning "leave your system wide open".
    In ssh nomenclature, what you refer to as "keyless" are called keys, and they are clearly distinct from passwords. You cannot enter them on the keyboard. They are more than 1600 bytes. This is what I meant by "infeasible" by brute force. Isn't that 2^8^1600? Even if you made 4 attempts per second, I think this will take you more than a billion years...and you still won't be 1% done.

    And since it is a "horseshoes and handgrenades" type game, brute force is the only option. Like I said, it was my understanding that this was the whole purpose of ssh and using it without them is akin to installing a laser perimeter alarm -- then never plugging it in.

    This is probably why my man at NASA says no one has got in that way in 10 years (ie, the entire time). If brute force attacks are all you guys are worried about, I'm gonna say you're beyond paranoid -- you're totally insane
    Last edited by MK27; 01-27-2010 at 01:08 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #30
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by MK27 View Post
    In ssh nomenclature, what you refer to as "keyless" are called keys, and they are clearly distinct from passwords. You cannot enter them on the keyboard. They are more than 1600 bytes. This is what I meant by "infeasible" by brute force. Isn't that 2^8^1600? Even if you made 4 attempts per second, I think this will take you more than a billion years...and you still won't be 1% done.

    And since it is a "horseshoes and handgrenades" type game, brute force is the only option. Like I said, it was my understanding that this was the whole purpose of ssh and using it without them is akin to installing a laser perimeter alarm -- then never plugging it in.

    This is probably why my man at NASA says no one has got in that way in 10 years (ie, the entire time). If brute force attacks are all you guys are worried about, I'm gonna say you're beyond paranoid -- you're totally insane
    True enough; and I was generalizing. For password-based authentication however it makes nothing I said any the less valid. There is the old joke about "being paranoid doesn't mean they are not out to get you" but when I look at my server logs and find attempts to get in through everything from ssh to MS services from China, et al I can honestly say they ARE out to get you. I/we may seem paranoid to you; you seem naive to me, that's for sure. I cannot speak to your friend at NASA but if security was as simple as you would have us believe, I would wager far fewer machines would be hacked and set up as part of zombie nets...the thing with the above-mentioned attack is that while brute force, due to the nature of the relaxed timing it often falls below the radar of the typical IDS and therefore can go on for years w/o detection. To me, the attack that you cannot even see coming, lame or not is one of the most dangerous kinds...
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. "Blob" server?
    By cyberfish in forum Tech Board
    Replies: 10
    Last Post: 12-02-2009, 11:03 PM
  2. Replies: 15
    Last Post: 10-20-2009, 09:39 AM
  3. Connecting to Server
    By osal in forum Networking/Device Communication
    Replies: 58
    Last Post: 06-10-2004, 10:10 AM
  4. IE 6 status bar
    By DavidP in forum Tech Board
    Replies: 15
    Last Post: 10-23-2002, 05:31 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21