Se­cure your Linux desk­top

Linux can thwart a ma­jor­ity of at­tacks on its own, but Mayank Sharma’s on hand to help you put up a level 10 force-field around your com­puter.

APC Australia - - Contents -

Run­ning Linux just be­cause you think it’s safer than Win­dows? Think again. Se­cu­rity in Linux is a built-in fea­ture and ex­tends right from the ker­nel to the desk­top, but it still leaves enough room to let some­one muck about with your /home folder. Sure, Linux is im­per­vi­ous to viruses and worms writ­ten for Win­dows, but at­tack­ers have sev­eral other tricks up their sleeves to il­le­gally ac­cess your pre­cious bits and bytes that make up ev­ery­thing from your per­sonal emails to your credit card de­tails.

Lock­ing your data be­hind a user­name and pass­word shouldn’t be your only line of de­fence, and isn’t enough to hold off a de­ter­mined at­tacker. As the num­ber, na­ture and va­ri­ety of com­puter at­tacks es­ca­late ev­ery day, you too should go out of the way and take ex­tra mea­sures to se­cure your com­puter against unau­tho­rised ac­cess.

All main­stream Linux dis­tri­bu­tions such as De­bian, Ubuntu and Fe­dora have se­cu­rity teams that work with the pack­age devs to make sure you stay on top of se­cu­rity vul­ner­a­bil­i­ties. Gen­er­ally, th­ese teams work with each other to make sure that se­cu­rity patches are avail­able as soon as a vul­ner­a­bil­ity is dis­cov­ered.

Your distri­bu­tion will have a repos­i­tory ded­i­cated to se­cu­rity up­dates. All you have to do is make sure the se­cu­rity-spe­cific repos­i­tory is en­abled (chances are it will be, by de­fault), and choose whether you’d like to in­stall the up­dates au­to­mat­i­cally or man­u­ally at the press of a but­ton. For ex­am­ple, from the Up­dates tab in the Soft­ware & Up­dates app, you can ask Ubuntu to down­load and in­stall se­cu­rity up­dates au­to­mat­i­cally.

In ad­di­tion to the up­dates, dis­tri­bu­tions also have a se­cu­rity mail­ing list to an­nounce vul­ner­a­bil­i­ties, and also share pack­ages to fix them. It’s gen­er­ally a good idea to keep an eye on the se­cu­rity list for your dis­tro, and look out for any se­cu­rity up­dates to pack­ages that are crit­i­cal to you. There’s a small lag be­tween the an­nounce­ment and the pack­age be­ing pushed to the repos­i­tory; the se­cu­rity mail­ing lists guide the im­pa­tient on how to grab and in­stall the up­dates man­u­ally.

You should also take some time to dis­able un­nec­es­sary ser­vices. A Linux desk­top dis­tro starts a num­ber of ser­vices to be of use to as many peo­ple as pos­si­ble. But you re­ally don’t need all th­ese ser­vices. Samba, for ex­am­ple, shouldn’t re­ally be en­abled on a se­cure server, and why would you need the Blue­tooth ser­vice to con­nect to Blue­tooth de­vices on a com­puter that doesn’t have a Blue­tooth adapter? All dis­tri­bu­tions en­able you to con­trol the ser­vices that run on your Linux in­stal­la­tion usu­ally with a built-in graph­i­cal util­ity. How­ever, some ap­pli­ca­tions might stop func­tion­ing be­cause you de­cided to dis­able a ser­vice on which they rely. For ex­am­ple, many server ap­pli­ca­tions rely on data­bases, so be­fore you turn off MySQL or Post­greSQL you should make sure you aren’t run­ning any ap­pli­ca­tions that rely on them.

SE­CURE USER AC­COUNTS

On a multi-user sys­tem like Linux, it’s im­per­a­tive that you limit ac­cess to the su­per-user root ac­count. Most dis­tri­bu­tions th­ese days don’t en­able you to log in as root at boot time, which is good. Fur­ther­more, in­stead of giv­ing mul­ti­ple peo­ple root per­mis­sion, you should grant root ac­cess on a per-com­mand ba­sis with the sudo com­mand. Us­ing sudo in­stead of log­ging in as the root user has sev­eral ad­van­tages. All ac­tions per­formed with sudo are logged in the /var/log/se­cure file, which also records all failed at­tempts.

One of the ma­jor ad­van­tages of us­ing sudo is that it makes it pos­si­ble to re­strict root ac­cess to cer­tain com­mands. For this you need to make changes in the /etc/su­do­ers file, which should al­ways be edited with the vi­sudo com­mand. This com­mand locks the su­do­ers file, saves ed­its to a tem­po­rary file and en­sures the con­fig­u­ra­tion is cor­rect be­fore writ­ing it to /etc/su­do­ers. The de­fault ed­i­tor for vi­sudo is vi.

To en­able a user named ‘ad­min’ to gain full root priv­i­leges when they pre­cede a com­mand with sudo , add the fol­low­ing line in the /etc/ su­do­ers file: ad­min ALL=(ALL) ALL To make it pos­si­ble for a user named Joe to run all com­mands as any user but only on the ma­chine whose host­name is viper­host, add joe viper­host=(ALL) ALL You can also re­strict ac­cess to cer­tain com­mands. For ex­am­ple, the fol­low­ing line will only en­able a user called Susie to run the kill, shut­down, halt and re­boot com­mands:

susie ALL = /bin/ kill, /sbin/shut­down, /sbin/ halt, /sbin/re­boot Sim­i­larly, a user called Jack can only add and re­move other users, like so:

jack ALL = /usr/sbin/ ad­duser

You can also re­strict a user’s scope. The fol­low­ing en­ables the user named Nate to kill un­re­spon­sive pro­cesses, but only on his work­sta­tion named Tango and not any­where else: nate tango = KILL

On a re­lated note, you should also set ex­pi­ra­tion dates for ac­counts used by non-per­ma­nent users. This can in­clude any in­terns, tem­po­rary em­ploy­ees and con­sul­tants who need to ac­cess your Linux in­stal­la­tion. Ideally, you should im­me­di­ately de­ac­ti­vate and re­move the tem­po­rary ac­counts as soon as they aren’t re­quired. The ex­pi­ra­tion date acts as a safe­guard to en­sure th­ese ac­counts can’t be mis­used.

Use the user­mod com­mand to tweak a user’s ac­count and set an ex­pi­ra­tion date, such as: $ sudo user­mod -e 2018-0902 bodhi

In this ex­am­ple, the user named Bodhi won’t be able to log into the ac­count from Septem­ber 2, 2018.

PER­MIS­SIONS PRIMER

An­other im­por­tant part of se­cur­ing your Linux sys­tem is set­ting proper per­mis­sions. In Linux and Unix, ev­ery­thing is a file. Direc­to­ries are files, files are files and de­vices are files. Ev­ery file and pro­gram must be owned by a user. Each user has a unique iden­ti­fier called a user ID (UID), and each user must also be­long to at least one group, which is de­fined as a col­lec­tion of users that has been es­tab­lished by the sys­tem ad­min­is­tra­tor and can be as­signed to files, fold­ers and more.

Users may be­long to mul­ti­ple groups. Like users, groups also have unique iden­ti­fiers, called group IDs (GIDs). The ac­ces­si­bil­ity of a file or pro­gram is based on its UIDs and GIDs. Users can ac­cess only what they own or have been given per­mis­sion to run. Per­mis­sion is granted be­cause the user ei­ther be­longs to the file’s group or be­cause the file is ac­ces­si­ble to all users. The one ex­cep­tion is the root or su­pe­ruser who is al­lowed to ac­cess all files and pro­grams in the sys­tem. Also, files in Linux have three kinds of per­mis­sion as­so­ci­ated to them — users, groups and oth­ers — that de­ter­mine whether a user can read, write or ex­e­cute a file.

You can view the per­mis­sions of a file or direc­tory with the ls -l com­mand. The com­mand to use when mod­i­fy­ing per­mis­sions is chmod . There are two ways to mod­ify per­mis­sions: with num­bers or with let­ters. Us­ing let­ters is eas­ier to un­der­stand for most peo­ple, but num­bers are much bet­ter once you get used to them. The ta­ble (over the page) lists the chmod val­ues for each of the per­mis­sion types. For ex­am­ple, chmod u+x

<some­file> gives ex­e­cute per­mis­sions to the owner of the file. The chmod 744 <some­file> does the same thing, but is ex­pressed in num­bers. Sim­i­larly, chmod g+wx

<some­file> adds write and ex­e­cute per­mis­sion to the group while chmod

764 <some­file> is how you’ll ex­press it with num­bers.

How­ever, this ar­range­ment can’t be used to de­fine per-user or per-group per­mis­sions. For that, you need to em­ploy ac­cess con­trol lists (ACL) that en­able you to spec­ify elab­o­rate per­mis­sions for mul­ti­ple users and groups. While you can de­fine them man­u­ally, graph­i­cal tools such as Ei­ciel make the process more in­tu­itive and help you save a lot of time and ef­fort. You can in­stall Ei­ciel from the re­pos of most ma­jor desk­top dis­tri­bu­tions. Once in­stalled, the tool can be used to fine-tune the ac­cess per­mis­sions for each in­di­vid­ual file.

To get a bet­ter hang of the filesys­tem per­mis­sions on Linux, let’s put them into prac­tice to lock sen­si­tive files, such as the ones that house pass­word in­for­ma­tion. The file should be­long to the root owner and

group with 644 per­mis­sions. This en­ables users to log in and view the as­so­ci­ated user­name. How­ever, it will pre­vent them from mod­i­fy­ing the /etc/passwd file di­rectly. Then there’s the /etc/shadow file that con­tains en­crypted pass­words as well as other in­for­ma­tion, such as ac­count or pass­word ex­pi­ra­tion val­ues. The owner of this file is the user root while the group is of­ten set to an ad­min group, like shadow. The per­mis­sions on this file are set to 000 to pre­vent any user from even read­ing it.

Still, while there’s no ac­cess per­mis­sion on the file, the root user can still ac­cess it. But if no one can ac­cess the file, how can users change their pass­words that are stored in this file? This is be­cause the /usr/ bin/ passwd util­ity uses the spe­cial per­mis­sion known as SUID. Thanks to this spe­cial pro­vi­sion, the user run­ning the passwd com­mand tem­po­rar­ily be­comes root while the com­mand is run­ning and can then write to the /etc/shadow file. Sim­i­larly, the /etc/group file that con­tains all the groups on the sys­tem should have the same file per­mis­sions as the /etc/ passwd file. In the same vein, the group pass­word file /etc/gshadow should have the same per­mis­sions as /etc/shadow.

MAN­AGE PASS­WORDS WITH PAM

The plug­gable au­then­ti­ca­tion mod­ules (PAM) mech­a­nism was orig­i­nally im­ple­mented in the So­laris op­er­at­ing sys­tem, but has been a Linux main­stay for quite a while now. PAM sim­pli­fies the au­then­ti­ca­tion man­age­ment process and pro­vides a flex­i­ble mech­a­nism for au­then­ti­cat­ing users and apps.

In or­der to reap the ben­e­fits of PAM, in­di­vid­ual ap­pli­ca­tions have to be writ­ten with sup­port for the PAM li­brary. The com­mand

ldd /{,usr/}{bin,sbin}/* |grep -B 5 lib­pam | grep ‘^/’ will dis­play a list of all the pro­grams on your sys­tem that are PAM-aware in some way or the other. From the list you’ll no­tice that many of the com­mon Linux util­i­ties make use of PAM.

You can also use PAM to force users to select a com­plex pass­word. PAM stores its con­fig­u­ra­tion files un­der the /etc/pam.d direc­tory. Here you’ll find a con­fig­u­ra­tion file for vir­tu­ally all the pro­grams that re­quest PAM au­then­ti­ca­tion. When you look in­side th­ese con­fig­u­ra­tion files, you’ll no­tice that they all be­gin with calls to in­clude other con­fig­u­ra­tion files with the com­mon- pre­fix. For ex­am­ple, the /etc/ pam.d/passwd file calls the com­mon­pass­word file. Th­ese com­mon- pre­fixed files are gen­eral con­fig­u­ra­tion files whose rules should be ap­plied in most sit­u­a­tions.

The com­mon-pass­word file con­trols pass­word com­plex­ity. The

cat /etc/pam.d/com­mon­pass­word | grep pass­word com­mand will list the rel­e­vant lines that de­fine the ba­sic rules for pass­words, such as:

pass­word [suc­cess=1 de­fault=ig­nore] pam_ unix. so ob­scure sha512

pass­word req­ui­site pam_ deny.so

pass­word re­quired pam_ per­mit.so

pass­word op­tional pam_ gnome_ keyring.so We’re in­ter­ested in the first line that de­fines the rules for pass­words. Some rules are al­ready de­fined, such as ask­ing for pass­words to be en­crypted with the SHA512 al­go­rithm. The ob­scure pa­ram­e­ter en­sures com­plex­ity based on var­i­ous fac­tors such as pre­vi­ous pass­words, num­ber of dif­fer­ent types of char­ac­ters and more.

For more pass­word-check­ing ca­pa­bil­i­ties, let’s in­stall an ad­di­tional PAM mod­ule with sudo apt in­stall lib­pam-crack­lib . In­stalling this mod­ule will au­to­mat­i­cally change the /etc/pam.d/com­mon-pass­word file that lists the fol­low­ing ad­di­tional line:

pass­word req­ui­site pam_ crack­lib.so retry=3 minlen=8 di­fok=3 This line en­ables the pam_crack­lib mod­ule and gives the users three chances to pick a good pass­word. It also sets the min­i­mum num­ber of char­ac­ters in the pass­word to eight. The di­fok=3 op­tion sets the min­i­mum num­ber of char­ac­ters that must be dif­fer­ent from the pre­vi­ous pass­word.

You can ap­pend re­mem­ber=5 on this line to pre­vent users from set­ting the five most re­cently used pass­words. You can also use the dcredit , ucredit , lcredit and ocre­dit op­tions to force the pass­word to in­clude dig­its, up­per-case char­ac­ters, lower-case char­ac­ters and spe­cial-case char­ac­ters. For ex­am­ple, you can use the fol­low­ing code to force the user to choose a pass­word that’s not the same as the user­name and con­tains a min­i­mum of 10 char­ac­ters with at least four dig­its, one up­per-case char­ac­ter, and one spe­cial char­ac­ter:

pass­word req­ui­site pam_ crack­lib.so dcredit=-4 ucredit=-1 ocre­dit=-1 lcredit= 0 minlen=10 re­ject_ user­name

OBFUSCATE YOUR STUFF

One of the best ways to keep your per­sonal data to your­self is to en­crypt it, so oth­ers can’t read the files. To this

end, the in­stall­ers of some lead­ing dis­tri­bu­tions make it pos­si­ble for you to en­crypt your en­tire disk dur­ing the ini­tial setup of the dis­tro.

If you wish to en­crypt in­di­vid­ual files, how­ever, you can use the zu­luCrypt ap­pli­ca­tion. This blocks de­vice en­cryp­tion, which means that it en­crypts ev­ery­thing writ­ten to a par­tic­u­lar block de­vice. The block de­vice can be a whole disk, a par­ti­tion or even a file mounted as a loop­back de­vice. With block de­vice en­cryp­tion, the user cre­ates the filesys­tem on the block de­vice, and the en­cryp­tion layer trans­par­ently en­crypts the data be­fore writ­ing it to the ac­tual lower block de­vice.

Us­ing zu­luCrypt, you can cre­ate an en­crypted disk within a file or within a non-sys­tem par­ti­tion or USB disk. It can also en­crypt in­di­vid­ual files with GPG. Zu­luCrypt has an in­tu­itive user in­ter­face; you can use it to cre­ate ran­dom key­files and use th­ese to en­crypt the con­tain­ers. The pro­gram also in­cludes the zu­luMount tool that can mount all en­crypted vol­umes sup­ported by zu­luCrypt.

To in­stall zu­luCrypt head to http://mhogom­chungu.github.io/ zu­luCrypt/ and scroll down the page to the bi­nary pack­ages sec­tion. The pro­gram is avail­able as in­stal­lable .deb pack­age files for De­bian and Ubuntu. Down­load the pack­age for your dis­tro and ex­tract it with tar xf

zu­luCrypt*.tar.xz . In­side the ex­tracted folder, switch to the folder cor­re­spond­ing to your ar­chi­tec­ture (i386 for older 32-bit ma­chines and amd64 for new 64-bit ones). Both fold­ers con­tain four bi­nary pack­ages that you can in­stall in one go with the sudo dpkg -i *deb com­mand. On other dis­tri­bu­tions you’ll have to in­stall zu­luCrypt man­u­ally. Down­load the app’s tar­ball and fol­low the de­tailed steps in the in­cluded BUILDINSTRUCTIONS file to fetch the de­pen­den­cies from your dis­tro’s re­pos.

PUT UP A FIREWALL

Linux dis­tri­bu­tions comes with the ven­er­a­ble net­fil­ter/ipt­a­bles frame­work. This is a set of ker­nel mod­ules that can be utilised to cre­ate packet fil­ter­ing rules at the ker­nel level. Ubuntu ships with the Un­com­pli­cated FireWall (UFW), which is a userspace ap­pli­ca­tion that can be used to cre­ate ipt­a­bles rules.

There’s also a GUI for UFW called Gufw. It takes the pain out of man­ag­ing ipt­a­bles. The pro­gram can eas­ily al­low or block ser­vices as well as user-spec­i­fied ports. You con­fig­ure your pol­icy based on pre-in­stalled pro­files for Home, Pub­lic and Of­fice and set the poli­cies for in­com­ing and out­go­ing traf­fic. The de­fault con­fig­u­ra­tion should sat­isfy most of the users, although you can set in­di­vid­ual rules if you wish for a more ad­vanced con­fig­u­ra­tion.

Be­gin by first en­abling the firewall. Once en­abled you can set the In­com­ing and Out­go­ing poli­cies by se­lect­ing one of the three op­tions in the drop-down menus. The Al­low op­tion will per­mit traf­fic with­out ask­ing any ques­tions. The Deny op­tion will silently dis­card all in­com­ing or out­go­ing pack­ets. The Re­ject op­tion is dif­fer­ent in that it sends an er­ror packet to the sender of the in­com­ing pack­ets.

After you’ve set the pol­icy for both In­com­ing and Out­go­ing traf­fic you can de­fine spe­cific rules for in­di­vid­ual pro­grams and ser­vices. To cre­ate a rule, click the Add but­ton after ex­pand­ing the Rules sec­tion. This opens a win­dow that of­fers three tabs that en­able the cre­ation of rules in dif­fer­ent ways. The Pre­con­fig­ured op­tion en­ables you to select ready­made rules for spe­cific pro­grams or ser­vices, while the other two en­able you to de­fine rules for spe­cific ports.

We’d sug­gest that most users should stick to the Pre­con­fig­ured tab. All you need to do is select the pro­gram you wish to con­trol traf­fic for from the drop­down menu and Gufw will au­to­mat­i­cally de­fine the most ef­fec­tive rules. As men­tioned ear­lier: for a se­cure sys­tem, you should drop all in­com­ing and out­go­ing traf­fic and then se­lec­tively add rules for the pro­grams and ser­vices that you use, such as the web browser, in­stant mes­sag­ing and BitTor­rent.

Pre­vent browser-based breaches with the NoScript and Bet­terPri­vacy ex­ten­sions that stop your web browser from run­ning ma­li­cious scripts.

Ei­ciel adds an Ac­cess Con­trol List tab in the file man­ager’s file prop­er­ties di­a­log win­dow that’s ac­cessed by right- click­ing over a file.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.