Se­cure your Linux sys­tem

Read­ing Sun Tzu is just the first step in tack­ling those who seek to harm your Linux ma­chines. Shashank Sharma re­veals what you need to do next.

APC Australia - - Contents -

There’s an en­tire thread on Red­dit dis­cussing whether Pro­fes­sor Alas­tor ‘Mad-Eye’ Moody, from the Harry Pot­ter books, ever ut­tered the catchphrase, “Con­stant vig­i­lance!” Re­gard­less of who to at­tribute the state­ment to, if you’re con­cerned about se­cur­ing your Linux in­stal­la­tion, whether as a home user or a sys­tem ad­min­is­tra­tor, it’s good ad­vice to adopt this mantra.

The en­tire gamut of op­er­a­tions that you can em­ploy to de­fend your­self from threats are spread over the next few pages. We will walk you through cre­at­ing a dig­i­tal moat around your ma­chines to stop the march­ing in­vaders in their tracks. This in­volves us­ing pass­word man­agers such as Keep­ass2, us­ing se­cure lo­gin, work­ing with ClamAV to de­tect tro­jans, viruses and mal­ware, and more. We’ll also show you how you can make life eas­ier for your­self by au­tomat­ing a num­ber of es­sen­tial tasks, such as mon­i­tor­ing the ports for scan­ners us­ing tools like Nmap and im­ple­ment­ing tools such as logcheck and logro­tate to make sense of all the logs that are gen­er­ated by var­i­ous apps and ser­vices. Along the way, we’ll help you de­ploy a rootkit checker, dis­cuss var­i­ous pass­word­strength­en­ing mea­sures and lots more. Fi­nally, we’ll dis­cuss the projects that are work­ing to­wards mak­ing Linux even more se­cure for servers and net­works and the ef­forts be­ing made to make the ker­nel ro­bust.

While we’re us­ing Linux Mint for this fea­ture (which is on the cover disc), all the tools dis­cussed here can just as read­ily be used on any pop­u­lar dis­tro such as Cen­tOS, Fe­dora, Mageia, Ubuntu, De­bian and so on.

But first, baby steps. Th­ese are the tricks that you can and must adopt to se­cure your ma­chines. If you’re in­ter­ested in pro­tect­ing a rel­a­tive’s desk­top which they use to browse the in­ter­net for their daily dose of en­ter­tain­ment or world politics, even th­ese changes should be enough to set your mind at peace.

The first step is to choose the right dis­tro. Sounds rather silly, but there’s a rea­son why you should give se­ri­ous thought be­fore set­tling on any Linux dis­tro. You must con­sider whether the dis­tro has a ded­i­cated team work­ing on push­ing reg­u­lar bug fixes and se­cu­rity up­dates. This is im­por­tant, be­cause in re­cent years, many se­cu­rity weak­nesses in pop­u­lar Linux apps and ser­vices such as Samba have been found and un­less you plug th­ese your sys­tem is at risk. As a fur­ther pre­cau­tion, you can also dis­able or unin­stall ser­vices that you don’t need. For in­stance, if you only have a sin­gle ma­chine at home and haven’t con­fig­ured it for print­ing, you don’t need CUPS or the Samba ser­vices.

An­other trick to em­ploy is to opt for en­cryp­tion. Most Linux dis­tros nowa­days al­low you to en­crypt your home folder dur­ing in­stal­la­tion it­self. You can also op­tion­ally use apps such as zu­luCrypt to con­fig­ure en­cryp­tion on your cur­rent in­stal­la­tion.

It’s im­per­a­tive to not use dic­tio­nary words nor key­words such as ‘qw­erty’ or ‘god111’ as your pass­words. The safest op­tion is to en­sure that pass­words are re­set reg­u­larly, and you can pro­gram your sys­tem to re­ject pass­words that users have used pre­vi­ously.

Through­out the next few pages, you’ll find help­ful hints and some­times de­tailed in­struc­tions on how to adopt many of th­ese prin­ci­ples into your Linux in­stal­la­tion, apart from all the other ad­vanced tools and tricks which you can use to thwart at­tack­ers.

To se­cure your ma­chines, you must adopt a two-pronged strat­egy against po­ten­tial at­tacks. The first in­volves pre­par­ing against in­trud­ers by in­stalling a fire­wall and adopt­ing bet­ter pass­word poli­cies. But this alone isn’t enough. It’s one thing to lock all the win­dows in your house, but you must still make sure no one got in be­fore you closed them.


Trust­ing pass­words to hold all your data is fool­hardy. To pre­vent unau­tho­rised ac­cess to your ma­chine, you can add an ex­tra layer of au­then­ti­ca­tion. One of the eas­i­est meth­ods is by us­ing the Google Authen­ti­ca­tor ser­vice, which is­sues a time-based au­then­ti­ca­tion to­ken to sup­ple­ment the ex­ist­ing pass­word chal­lenge.

You can con­fig­ure the util­ity for all con­fig­ured users on your Linux ma­chine, and each will re­ceive the OTP on their con­fig­ured An­droid de­vices. Un­less a user en­ters the to­ken that quickly ex­pires, they can’t log in. If you’ve con­fig­ured your ma­chine to al­low re­mote lo­gins, you can also con­fig­ure Google Authen­ti­ca­tor to work with SSH.

To im­ple­ment this multi-fac­tor au­then­ti­ca­tion with Google Authen­ti­ca­tor, you’ll need the Google Authen­ti­ca­tor PAM mo­d­ule. PAM stands for ‘plug­gable au­then­ti­ca­tion mod­ules’ — a mech­a­nism for plug­ging dif­fer­ent forms of au­then­ti­ca­tion into a Linux com­puter.


The lib­pam-pwqual­ity tool is an­other such mo­d­ule that you can use to im­prove your pass­words. Open the /etc/pam.d/com­mon-pass­word file in your favourite text ed­i­tor and iden­tify the line that reads pass­word [suc­cess=1 de­fault=ig­nore] pam_ ob­scure sha512 . Add the minlen pa­ram­e­ter to the end of the line if you want users to choose pass­words with a min­i­mum-length pass­word [suc­cess=1 de­fault=ig­nore] pam_ ob­scure sha512 minlen=8 .

If you sim­i­larly want to en­sure that users choose pass­words with a mix of up­per/lower-case let­ters and spe­cial char­ac­ters, throw in pa­ram­e­ters such as lcredit=-3 ucredit=-2 dcredit=-2 , which forces users to re­spec­tively use three lower-case let­ter, two up­per-case let­ters and two dig­its. You can in­stall it us­ing the sudo apt in­stall lib­pam­p­wqual­ity com­mand from the ter­mi­nal.


The pass­word tricks dis­cussed here, cou­pled with us­ing a fire­wall and reg­u­lar sys­tem up­dates, are a good start to pro­tect­ing your sys­tem, but hack­ers of­ten em­ploy other means to do you harm. A com­mon at­tack strat­egy used by at­tack­ers is priv­i­lege es­ca­la­tion, wherein af­ter gain­ing ac­cess to the ma­chine by com­pro­mis­ing your pass­word or in­stal­la­tion of ma­li­cious script, an at­tempt is made to gain root ac­cess such that more harm­ful op­er­a­tions can be car­ried out. A rootkit is a script or pro­gram de­signed to gain un­law­ful root ac­cess for ne­far­i­ous pur­poses.

One of the most pop­u­lar rootkit scan­ners is chk­rootkit. You can eas­ily in­stall it from the ter­mi­nal with the sudo apt in­stall chk­rootkit com­mand. Once in­stalled, you can in­voke it with the sudo chk­rootkit com­mand. The tool is de­signed to scan your ma­chine for a host of known rootkits and mal­ware. Run the

chk­rootkit -l com­mand for a list of all the tests the util­ity runs by de­fault. Keep in mind that the process can take some time, de­pend­ing on your sys­tem con­fig­u­ra­tion and avail­able re­sources.

A com­mon trick adopted by rootkits is open­ing ports, which would al­low an at­tacker en­try into your sys­tem. You can scan your sys­tem for open ports us­ing the Nmap util­ity. You can scan for ports by spec­i­fy­ing a range or scan all of them with nmap -p 1-65535 lo­cal­host . The full range of Nmap’s ca­pa­bil­i­ties are too vast for us to list here. Re­fer to the man­ual (use man nmap ) for de­tails on get­ting the most out of it.

As a fur­ther pre­cau­tion, you must also in­stall the ClamAV app, which can de­tect tro­jans and viruses. If your setup in­volves Win­dows and Linux ma­chines, it’s also rec­om­mended to in­stall Linux Mal­ware De­tect, a mal­ware scan­ner for Linux which even al­lows users to sub­mit sus­pected mal­ware for re­view.

“It’s one thing to lock all the win­dows in your house, but you must still make sure no one got in be­fore you closed them.”

The se­cu­rity of a Linux ma­chine in­volves more than mere in­stal­la­tion of soft­ware. It re­quires ac­tive par­tic­i­pa­tion to mon­i­tor the log files and other re­ports gen­er­ated by the host of tools and apps de­ployed. You must also in­ter­pret the re­ports and, where nec­es­sary, take fur­ther steps to de­ter at­tack­ers. Un­less you’re will­ing to do all this, you’ll quickly end up with a ma­chine that’s host to all man­ner of sus­pect ac­tiv­ity.

But don’t panic. You can help your­self by au­tomat­ing a num­ber of th­ese tasks.


A net­work anal­yser, of­ten re­ferred to as a snif­fer, is a pro­gram that col­lects and gath­ers all net­work traf­fic. You can use it to de­ter­mine if a ma­li­cious en­tity is at­tack­ing or has at­tacked your net­work. When your ma­chine is set in pro­mis­cu­ous mode, the net­work in­ter­face will col­lect all net­work traf­fic pass­ing through that in­ter­face.

You can use the ‘ngrep’ tool to watch your net­work in real time. It even en­ables you to sep­a­rate pack­ets based on spe­cific pa­ram­e­ters. The sim­plest way to use it is to run the ngrep com­mand in the ter­mi­nal to watch all traf­fic pass­ing through the net­work. If you’ve never used the tool be­fore, it’s best to study the out­put of ngrep, ini­tially. Later on, you can be­gin play­ing around with dif­fer­ent fil­ters, which al­low you to fo­cus on pack­ets based on host, type, pro­to­col or di­rec­tion (of traf­fic). You can use: ngrep port num­ber > /tmp/ ngrep-logile to dump the traf­fic de­tails to a log file and study it later.


Cron is a time-based sched­uler which you can use to run de­fined op­er­a­tions at a spe­cific time and date. It is com­monly used to per­form rou­tine tasks such as back­ups. Ev­ery sched­uled op­er­a­tion is re­ferred to as a cron job. You can cre­ate such cron jobs to en­sure your sys­tem isn’t com­pro­mised by sched­ul­ing ly­nis and chk­rootkit to be run daily. You can cre­ate cron jobs us­ing: crontab -e . This opens a the crontab file in a text ed­i­tor and you can then add tasks. The syn­tax of a cron job is: min­utes hours day month day_of_ week. That is, you can de­fine the minute, hour, day, month, day of the week when each task should be run.

It’s best to sched­ule chk­rootkit to run daily. You can con­fig­ure it to run at 1am every­day by adding the fol­low­ing to the crontab file: 0 1 * * * /usr/sbin/ chk­rootkit 2>&1 >ch­rootk­it_log


Your Linux sys­tem, the myr­iad ap­pli­ca­tions and tools, and many every­day op­er­a­tions such as soft­ware man­age­ment all gen­er­ate log files. Th­ese are use­ful for three main rea­sons. They can help you trou­bleshoot sys­tem prob­lems, such as the rea­son why a soft­ware in­stal­la­tion failed. Next, logs can serve as an early warn­ing sys­tem for se­cu­rity events. From a se­cu­rity point of view, if you are con­vinced your sys­tem has been com­pro­mised, logs can help you with per­form­ing foren­sic in­ves­ti­ga­tion.

You can only rely on the logs to de­ter­mine some­thing is wrong if you’re fa­mil­iar with what the log reads like dur­ing nor­mal sys­tem op­er­a­tion. It is im­per­a­tive to be able to dis­tin­guish nor­mal ac­tiv­ity as op­posed to some­one try­ing to at­tack the sys­tem. You can only do this if you don’t just col­lect logs, but reg­u­larly study them too!

When deal­ing with logs, you must also have a thor­ough pol­icy in place with re­gards to var­i­ous fac­tors such as fre­quency of log­ging. You should also rou­tinely back up log files,

as com­par­ing cur­rent logs with the ar­chive can help you de­tect ne­far­i­ous ac­tiv­ity. At the same time, you can’t re­tain log files in­def­i­nitely, as they can take a large amount of space over a pe­riod of time.


You can use logro­tate for easy man­age­ment of log files. It sup­ports au­to­matic ro­ta­tion, com­pres­sion and mail­ing of log files and can be con­fig­ured by edit­ing the /etc/logro­tate.conf file. The logro­rate util­ity en­ables you to de­fine the fre­quency of ro­ta­tion, whether weekly or monthly, and the num­ber of log files to be used for each log. You can also set dif­fer­ent pa­ram­e­ters for dif­fer­ent log files and de­fine whether a log is to be ro­tated based on its size, and the pe­riod for which a ro­tated log file is to be stored.

For ex­am­ple, if the ro­ta­tion is set to 10 for the out­put.log file, the logro­tate util­ity will au­to­mat­i­cally cre­ate out­put1.log, out­put2.log and so on un­til out­put10.log, while the lat­est logs will be stored in out­put.log. The man page has more de­tails and you can find de­tailed in­struc­tions and ex­am­ples eas­ily on the in­ter­net as the util­ity has been around for ages.

An­other pop­u­lar tool is logcheck. It is de­signed to pe­ri­od­i­cally scan all the logs — it starts the scan where it left off last time, sav­ing cru­cial time. The highly con­fig­urable tool lets you de­fine the fre­quency of checks, the log files to be checked, what is con­sid­ered nor­mal and not, and where to email the alerts. You must de­fine the nor­mal be­hav­iour which the tool can ig­nore, oth­er­wise you’ll be in­un­dated with alerts.


An­other im­por­tant tool in the arse­nal of log watch­ers is swatch. It works by look­ing for the spec­i­fied reg­u­lar ex­pres­sions and promptly in­forms you when a match is found.

The user in­vok­ing swatch must cre­ate a ~/.swatchrc file which de­scribes the ig­nore and ‘watch­for’ di­rec­tives as well as the no­ti­fi­ca­tion email ad­dress. The watch­for en­try is a list of key­words that you want to be alerted about as soon as a match is found. You must be fa­mil­iar with reg­u­lar ex­pres­sions to get the most out of swatch. Also your sys­tem must be con­fig­ured to send mails to lo­cal users, as well as to an in­ter­net do­main, if you want emails sent to ex­ter­nal ser­vices such as Gmail.

Once con­fig­ured, you can use swatch to mon­i­tor a num­ber of logs for es­sen­tial key­words.

So far, we have dis­cussed a num­ber of tools and prac­tices that you can adopt to se­cure your sys­tem and pre­vent at­tacks, but there’s still plenty more that you can do, de­pend­ing on whether you’re in­ter­ested in pro­tect­ing your server or your net­work, or even a home work­sta­tion.

The en­tire gamut of avail­able so­lu­tions can very well lead to a trou­bling case of paral­y­sis from anal­y­sis, which is why we listed some of the best pro­tec­tive tools. But there’s still more that var­i­ous other projects and en­ti­ties are work­ing on to pro­tect your ma­chine from harm.

The Linux Se­cu­rity Mod­ules (LSM) frame­work al­lows the Linux ker­nel to sup­port a va­ri­ety of se­cu­rity mod­els to im­ple­ment manda­tory ac­cess con­trol (MAC). SELinux and Ap­pAr­mor are two of the most pop­u­lar LSMs on Linux. While the for­mer al­lows you to de­fine the ac­tiv­i­ties which can be per­formed by each user, process or dae­mon, Ap­pAr­mor can be used to re­strict each in­stalled pro­gram us­ing ap­pli­ca­tion­spe­cific pro­files. Con­tainer ven­dor Docker is also work­ing on an­other LSM called Land­lock, al­though it’s still at the nascent stage.

Apart from th­ese, there are a large num­ber of up­dates that ship with each new Linux ker­nel which fix many iden­ti­fied is­sues to keep you safe. On top of that, the Ker­nel Self Pro­tec­tion Project was started to pro­vide ad­di­tional lay­ers of se­cu­rity to the Linux ker­nel.

You can also tweak a num­ber of pa­ram­e­ters on your ker­nel to bol­ster the se­cu­rity. Run sysctl -a for a list of cur­rent ker­nel set­tings. You can save th­ese to a file with: sysctl -a > ~/sysctl.set­tings , which will en­able you to use the file for ref­er­ence or com­par­isons if you make any changes.

You can change th­ese set­tings on your run­ning ker­nel by edit­ing the /etc/sysctl.conf file. On Linux Mint, the file al­ready ex­ists and con­tains a num­ber of th­ese set­tings, but they are dis­abled by de­fault.

One of the biggest risks to sys­tem se­cu­rity is from untested and un­known ap­pli­ca­tions and you must take pre­cau­tions to pro­tect your sys­tem from such pro­grams. One way to do that is through sand­box­ing. This in­volves pro­vid­ing a com­part­men­talised en­vi­ron­ment to a script or app, so that the larger part of your in­stal­la­tion re­mains pro­tected.


The old­est sand­box­ing tool in Linux, chroot can be used to change the root direc­tory for a process. This pre­vents apps in­side a chroot jail from ac­cess­ing other di­rec­to­ries or files. Con­tain­ers such as Docker can sim­i­larly be used to run iso­lated ap­pli­ca­tion in­stances. If you’re spooked by the prospect of per­form­ing too many tasks to feel se­cure while con­nect­ing to the in­ter­net, con­sider us­ing Sub­graph OS. Based on De­bian, the dis­tro has been de­signed from the ground up, with a fo­cus on se­cu­rity and pri­vacy. It ships with a hard­ened Linux ker­nel, along with out-of-the-box sand­box­ing for ap­pli­ca­tions, fire­wall and proxy.

De­spite all th­ese tools, you must un­der­stand that at­tain­ing a com­pletely se­cure sys­tem is an un­achiev­able goal. This is be­cause the process would re­quire you to, in the words of Li­nus Tor­valds: “Un­plug the net­work ca­ble and in­stan­ti­ate dra­co­nian mea­sures for phys­i­cal se­cu­rity.” There’s no golden rule for se­cu­rity that ap­plies in ev­ery case, and even if there were, it would have been cracked al­ready. Se­cu­rity is some­thing that needs to be worked on and per­son­alised. With the com­bined weight of all the tools dis­cussed, you’ll get the three es­sen­tial in­gre­di­ents for good sys­tem se­cu­rity — pre­ven­tion, pro­tec­tion and de­tec­tion — and that’s the best any­one can hope for.

Your sys­tem log files can be clas­si­fied into four broad cat­e­gories: ap­pli­ca­tion logs, event logs, sys­tem logs and ser­vice logs.

Af­ter com­plet­ing the scans, ly­nis will pro­vide a num­ber of sug­ges­tions that you can in­cor­po­rate to im­prove sys­tem se­cu­rity.

Nmap Front End (NmapFE) is a well de­signed and sta­ble GUI that al­lows you to con­trol al­most ev­ery as­pect of Nmap.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.