Loading ...
Sorry, an error occurred while loading the content.

Re: [Raspberry_Pi_4-Ham_RADIO] Re: Books

Expand Messages
  • Kristoff Bonne
    Hi Jeff, I personly like to keep a middle-road attitude in this. Do keep security in the back of your mind when doing system administration or coding, but
    Message 1 of 35 , Mar 21, 2013
    • 0 Attachment
      Hi Jeff,


      I personly like to keep a middle-road attitude in this.
      Do keep security in the back of your mind when doing system administration or coding, but there is no need to get paranoid.


      Althou I think the raspberry-pi organisation itself would need to take the leading role in this, I do think Rick and Max have a point.
      A very simple document describing "the 10 steps to properly secure your pi" (if possible with some background information) would be very welcome. I'm not a fan of the "one script to change it all" approach where people just start a script and everything is done for them. Security depends on knowledge, and I think the idea of the "pi" is to allow people to learn things.



      For me, security not only applies to system administration but also going applies to coding. When looking at the different videos on the web, the idea seams to be "you need to have root to do gpio, so you just start the application with "sudo .." ".

      In fact, that is not true. You need root-access to _configure_ GPIO, but -if properly set up- _not_ to use it.
      This means that gpio-setup can be done with an seperate application (running with root-priviledges) that does gpio setup and sets the proper group-priviledges and then quit. After that, using the GPIO can be done with any application with only "user" priviledges, if the user is in a particular group.


      When writing some code for testing DTMF decoding on an icom D-STAR repeater, I had part of the code that needed to run as root (the part that intercepts the D-STAR traffic between the centos box and the icom repeater-controller), but I put that in a seperate application that only did that and have it root-priviledges with "setuid". I then pipped its output to standard-out so I could put a perl-script on top of that that processed that data and executed the external scrips based on the DTMF-codes received. This ran as a normal user and so did any external scripts it spawned.


      For people new to writing programs, this is probably not the the first thing they think about.
      Also there, knowledge-sharing is needed.
      And, it is important to make sure we do not scare people away from programming. After all, this is one of the main reasons the pi was created, get more people to code and understand computing.


      73
      Kristoff - ON1ARF

      On 20-03-13 23:59, Jeff Francis™ wrote:
       

        As someone who does computer and network security for a living (as well as being a former programmer, former linux systems administrator, and former network engineer), I've had to put up a mental wall between work and hobby, lest I turn into "that guy" who does nothing but rant and rave about security.  But I have to agree that the vast majority of new converts to the Pi are playing with fire and don't have the vaguest idea.  The only true security is a system with no wires (or wifi) connected to it whatsoever.  In the industry, we call that "air gap security".  Believe it or not, even that's not secure.  The Iranian centrifuges were hacked via thumb drives, in spite of the air gap.  So (supposedly) was our US Air Force drone infrastructure.  Thumb drives are every bit as effective as a network connection to a determined attacker.

        There are some easy steps you can take to make things better.  Don't connect to a network if you don't need to.  If you need the network, don't allow access to the Internet unless you need to.  If you need access to the Internet, carefully filter what you allow outbound (and don't allow inbound unless you have absolutely no other choice).  Don't run any services on the box you don't need to.  With luck, a port scan of your box will show nothing more than ssh open.  If you *must* allow ssh from the Internet, be smart.  Set up port knocking.  Install denyhosts.  Use two-factor authentication (or certificates).  Even moving ssh off of port 22 helps a little (it won't even delay a human for ten seconds, but at least you'll be skipped over by the automated sweeps).  Don't run *anything* as root.  If you have to start something as root for permissions issues, open the file descriptors necessary as root, then do a system call to drop privs to a normal user as early in the code as possible.  Run your app in a chroot environment.  Sandbox (ie, dmz) whatever can be accessed from the Internet so if that box is compromised, they can't get to anything else in your network (ie, what we call a leapfrog attack).

        These are all trivial, simple things that can be easily done, and each one helps.  But be aware, if it's connected to the Internet, it can be compromised.  Period.  No exceptions.  Somebody just has to want to.  Believe me, I spend my life inside of Fortune 500 company networks, and the hack rate is 100%.  The only companies that haven't been compromised either have and don't know it yet (which is unbelievably common) or haven't been targeted yet (rare, but occasionally happens).

        Stop and think about it before you hook your newest creation to the Internet.  What does it control?  If somebody got remote access to it, could they harm someone?  Or something?  Cost you money somehow?  Use that access to stage attacks deeper into your own network?  Or maybe use it to stage attacks against somebody else (using your IP address, meaning you'll get to meet the nice men from the FBI)?  The comment about not caring about the D-STAR repeaters is asinine and shockingly ignorant.  A box does not need to have any value in and of itself to be of value to an attacker.  If nothing else, it's another anonymizing stepping stone for use in staging other attacks.

        Ok, putting my soapbox away.  Please, think before you connect.  Somebody, maybe somebody you don't know, will be grateful.

      Jeff N0GQ







      On Wed, Mar 20, 2013 at 2:29 PM, Ray Wells <vk2tv@...> wrote:
       

      My RPi runs as a headless aprs gateway and, like many others I use ssh to provide remote access.

      I changed my Pi's password (and hostname) and I disabled root access for ssh as part of the initial setting up process. What I forgot to do was change the standard ssh port (22) to something more obscure. It now has five digits.

      For three days I logged continuous attempts from three Chinese based IP addresses to log into my RPi - unsuccessfully, I should add.

      My RPi contains no mission critical files but the attempted intrusions do highlight how determined some people are to gain access to YOUR information.

      Since the ssh server in the RPi is now enabled by default, if your RPi has an internet connection it is probably at risk of intrusion.

      Change these now;

      RPi password. Changing the hostname is also recommended.
      don't allow root access for ssh - modify the config file. You can sudo after you've connected with your user account.
      change the default port number to something obscure. The only inconvenience this causes is you'll need to specify that port number in your ssh connect line. It's a lot harder stumble across, for example, 57642 than 22.

      Ray vk2tv


      On 21/03/13 03:11, John D. Hays wrote:
       

      I think there are two main reasons:

      1. The operator lacks the experience and knowledge to properly implement security
      2. They have that knowledge and make a conscious decision that for the device's intended use, security isn't that important.
      Sometimes we get wrapped in our 'professional' or even personal view of how things should be done, however, what we see as important may not be so for someone else.


      John D. Hays
      K7VE
      PO Box 1223, Edmonds, WA 98020-1223 
        



      On Wed, Mar 20, 2013 at 8:42 AM, Kristoff Bonne <kristoff@...> wrote:
       

      Hi Jeff,


      Sadly enough, there seams to be one thing that people do not seams to "port over" to the pi: security conciderations.


      When we worked on unix machines, there where some core ideas like "you shall not run applications run as root unless really necessairy", etc.

      If I see that people happily run the whole application as root/sudo only because they need access to a GPIO pin, or do not even bother to change the password of the "pi" user, I get a very bad feeling in my stomach!

      Concidering the spread of ipv6 -where devices are becoming more and more accessable from the web- and embedded devices (like the pi) controlling more and more critical infrastructure; making sure these devices are properly protected in not a luxury anymore!!!


      73
      Kristoff - ON1ARF




      On 20-03-13 15:50, Jeff Francis™ wrote:
       

        The beauty of the Pi is that it's a Linux box.  Pretty much anything (including books, tutorials, code examples, etc.) that applies to full-sized Linux boxes applies to the Pi.  The only real difference is that it's smaller and has some handy IO ports right on the board.  Think of the Pi as running Linux on a mid-90s era home PC.  It's about the same speed, power, storage, and RAM, but with the benefit of much newer software.  If you know linux, there's zero learning curve to using the Pi.







      --
      -=jeff=-

    • Timothy-Allen Albertson
      i first used linux, eg, ubuntu and puppy, abt five years ago---i dont have any MS systems on any of my machines---but i learn something every day==and i dont
      Message 35 of 35 , Apr 19, 2013
      • 0 Attachment
        i first used linux, eg, ubuntu and puppy, abt five years ago---i dont have any MS
        systems on any of my machines---but i learn something every day==and i dont
        worry abt viruses anywhere as much as i did with MS


        On Thu, Apr 18, 2013 at 7:39 PM, Jeff Francis™ <jeff@...> wrote:
         


        On Thu, Apr 18, 2013 at 2:54 PM, Ray Wells <vk2tv@...> wrote:
         

        One would have to question the sanity of a book for beginners that references vi instead of one of the user friendly text editors that are available today, such as nano. Vi's only purpose in life is for geeks to prove they're macho Linux users. It would have to rate as the least intuitive, most confusing and most user unfriendly text editor ever (yes I have persevered with vi at length in days gone by and occasionally I still use it when forced to).

          Ok, it's getting a little deep in here.  Yes, I would agree that vi is not the best editor for beginners, but claiming that vi's only purpose is for proving how macho you are is just plain ignorant.  Text editors are tools, much like vehicles are tools.  Both nano and vi (and emacs, for that matter) can be used to edit a simple text file.  Both a moped and a Formula One car can be used to drive to the grocery store for milk.  The fact that the Formula One car is far more of a tool than is required for going to the store does not make the car itself a tool only for macho drivers any more than using vi to edit a text file make it only a tool for macho linux users (though the choice to *USE* the F1 car for a milk run might be considered a bit over the top).

          There is no shame in not knowing how to use vi.  It is a very very powerful tool that provides far more capabilities than will ever be required to add a host to /etc/hosts, very much in the same sense that there's no shame in the average driver not being able to drive a Formula One car without stalling and crashing it before they make it to the end of the street.  There is a gradient of tools.  Simple tools (like nano or notepad) require minimal skills, experience, and training to use effectively, but are of very marginal use for complex problems.  Nobody in their right mind would write complex code with such a tool.  Complex tools require a great deal of skill, experience, and training, but provide tremendous power in the hands of a skillful user (and may be overkill for simple tasks).  Doing software development without the macros, programability, integration, and other features of an editor such as vi, emacs, or eclipse is almost suicidal.  I can do tasks in emacs in four or five keystrokes that would quite literally take hours of tedious work to do in nano.  Not because I'm smarter than a nano user, but because I've been using emacs since 1986.  It's experience, not intelligence.  Again, I agree that vi is not the appropriate tool for a beginner, but that doesn't make it useless or "macho".  And at least in the case of vi, it's certainly not too much tool for the job of editing a text file, unless you don't happen to be good at vi.  In which case the tool itself gets in the way of getting things done, and you should fine an alternative that lets you focus on your problem, not your tool.  But don't blame the tool, blame the level of experience.

          And if you think vi is horrible to use, you've never used teco (probably the most powerful (and hardest to use) text editor in existence, prior to emacs) or edlin (probably the least powerful text editor in history, which shipped with MSDOS back in the day).  vi is a paragon of usability compared to either of those.

          Linux was not designed for beginners.  Never was.  If you want a version of Unix for beginners, buy a Mac (which is BSD Linux with a very pretty GUI shell on top).  Linux is a remarkably powerful tool, but one should not expect to just jump in and master it without time and effort.  There is something on the order of 40+ years of development that have gone into Unix (not to mention it's ancestors, such as Multics).  There's a culture, a history, and a reason for everything you do in Unix.  Jumping into Linux with zero experience and expecting to accomplish anything of significance by following a few simple directions is probably aiming a little high for a beginner.  Like any extremely powerful tool, you have to learn some basics before you can jump ahead to the hard stuff.  man pages were not designed for a beginner to learn how to use a command.  They're intended to remind an experienced user what all of the arcane flags and arguments are.  The philosophy of Unix has always been "we don't give you documentation, we give you source code - if you want to know how something works, go read the source".  This does not make it the perfect choice for everyone.  It takes years of hard work and pain to master Unix.  But when you've climbed that hill, you are master of a tool of unparalleled power.  But there's no shame in not having the time, energy, and resources to reach that level of mastery.  Most of us have jobs, kids, and other hobbies.  If Linux doesn't sound like it's your thing, it's perfectly ok.  Windows certainly gets a lot of things done without the arcana of Unix.  And there's lots of Microsoft books at the local Barnes and Noble to bring your skills up to whatever level you desire to accomplish what you want to do.
         
          As the famous saying goes, "Unix is very user friendly, it's just very picky about who it's friends are." :D  If you want to learn Linux/Unix, don't be discouraged.  There's lots of help available.  Just be reasonable in setting your expectations.  One wouldn't expect to master a CNC machine in a day (or even a month), even if all you want to do is drill a hole with it (something you can do with a $10 drill from Harbor Freight Tools).  Don't be discouraged, just expect to put in some effort.  Your effort will be rewarded.  Linux is awesome and worth the effort.  It's just a little picky who it's friends are.



        Linux newbies have enough difficulty, and then they're steered in the direction of vi to edit text files. Makes no sense to me.

        Nano ships with Debian distros and it's at least user friendly.

        Ray vk2tv


        On 18/04/13 23:05, Paul M wrote:
         
        A book recommendation (fon't know if it has already been mentioned - too much quoted text to scroll through) is 'Learn Raspberry Pi with Linux - learn the ins and outs of Linux, the operating system that runs Raspberry Pi', by Peter Membrey & David Hows (Apress).

        First couple of chapters  deals with the very basics (unpacking, connecting, getting image onto SD, etc), Chapter 3 looks at the graphic interface (LXDE), theturns to Linux, e.g. basic commands, introduction to Bash, vi, files & paths, whilst the final 3 deal with WiPi (sic), a media centre & 'the Raspberry Spi' (using Pi with webcam to setup surveillance camera.

         
        ___________________________________________________________________________________

        Disclaimers: I have entered into no agreements regarding mails erroneously sent to this address, and reserve the right to do as I wish with any such emails.




        --
        -=jeff=-




        --
        72/73 TIM ALBERTSON KDOIA (ex KG6IRH)
      Your message has been successfully submitted and would be delivered to recipients shortly.