1.. _VerifyChapter: 2 3Verify File Integrity with Bareos 4================================= 5 6:index:`\ <single: Security; Using Bareos to Improve Computer>`\ :index:`\ <single: Verify; File Integrity>`\ 7 8Since Bareos maintains a catalog of files, their attributes, and either SHA1 or MD5 signatures, it can be an ideal tool for improving computer security. This is done by making a snapshot of your system files with a Verify Job and then checking the current state of your system against the snapshot, on a regular basis (e.g. nightly). 9 10The first step is to set up a Verify Job and to run it with: 11 12 13 14:: 15 16 Level = InitCatalog 17 18 19 20The InitCatalog level tells Bareos simply to get the information on the specified files and to put it into the catalog. That is your database is initialized and no comparison is done. The InitCatalog is normally run one time manually. 21 22Thereafter, you will run a Verify Job on a daily (or whatever) basis with: 23 24 25 26:: 27 28 Level = Catalog 29 30 31 32The Level = Catalog level tells Bareos to compare the current state of the files on the Client to the last InitCatalog that is stored in the catalog and to report any differences. See the example below for the format of the output. 33 34You decide what files you want to form your "snapshot" by specifying them in a FileSet resource, and normally, they will be system files that do not change, or that only certain features change. 35 36Then you decide what attributes of each file you want compared by specifying comparison options on the Include statements that you use in the FileSet resource of your Catalog Jobs. 37 38The Details 39----------- 40 41:index:`\ <single: Verify; Details>`\ 42 43In the discussion that follows, we will make reference to the Verify Configuration Example that is included below in the A Verify Configuration Example section. You might want to look it over now to get an idea of what it does. 44 45The main elements consist of adding a schedule, which will normally be run daily, or perhaps more often. This is provided by the VerifyCycle Schedule, which runs at 5:05 in the morning every day. 46 47Then you must define a Job, much as is done below. We recommend that the Job name contain the name of your machine as well as the word Verify or Check. In our example, we named it MatouVerify. This will permit you to easily identify your job when running it from the Console. 48 49You will notice that most records of the Job are quite standard, but that the FileSet resource contains verify=pins1 option in addition to the standard signature=SHA1 option. If you don’t want SHA1 signature comparison, and we cannot imagine why not, you can drop the signature=SHA1 and none will be computed nor stored in the catalog. Or alternatively, you can use verify=pins5 and signature=MD5, which will use the MD5 hash algorithm. The MD5 hash computes faster than SHA1, but is 50cryptographically less secure. 51 52The verify=pins1 is ignored during the InitCatalog Job, but is used during the subsequent Catalog Jobs to specify what attributes of the files should be compared to those found in the catalog. pins1 is a reasonable set to begin with, but you may want to look at the details of these and other options. They can be found in the :ref:`FileSet Resource <DirectorResourceFileSet>` section of this manual. Briefly, however, the p of the pins1 tells Verify to compare the permissions bits, the i is to 53compare inodes, the n causes comparison of the number of links, the s compares the file size, and the 1 compares the SHA1 checksums (this requires the signature=SHA1 option to have been set also). 54 55You must also specify the Client and the Catalog resources for your Verify job, but you probably already have them created for your client and do not need to recreate them, they are included in the example below for completeness. 56 57As mentioned above, you will need to have a FileSet resource for the Verify job, which will have the additional verify=pins1 option. You will want to take some care in defining the list of files to be included in your FileSet. Basically, you will want to include all system (or other) files that should not change on your system. If you select files, such as log files or mail files, which are constantly changing, your automatic Verify job will be constantly finding differences. The objective in 58forming the FileSet is to choose all unchanging important system files. Then if any of those files has changed, you will be notified, and you can determine if it changed because you loaded a new package, or because someone has broken into your computer and modified your files. The example below shows a list of files that I use on my Red Hat 7.3 system. Since I didn’t spend a lot of time working on it, it probably is missing a few important files (if you find one, please send it to me). On the 59other hand, as long as I don’t load any new packages, none of these files change during normal operation of the system. 60 61Running the Verify 62------------------ 63 64:index:`\ <single: Verify; Running>`\ 65 66The first thing you will want to do is to run an InitCatalog level Verify Job. This will initialize the catalog to contain the file information that will later be used as a basis for comparisons with the actual file system, thus allowing you to detect any changes (and possible intrusions into your system). 67 68The easiest way to run the InitCatalog is manually with the console program by simply entering run. You will be presented with a list of Jobs that can be run, and you will choose the one that corresponds to your Verify Job, MatouVerify in this example. 69 70 71 72:: 73 74 The defined Job resources are: 75 1: MatouVerify 76 2: usersrestore 77 3: Filetest 78 4: usersave 79 Select Job resource (1-4): 1 80 81 82 83Next, the console program will show you the basic parameters of the Job and ask you: 84 85 86 87:: 88 89 Run Verify job 90 JobName: MatouVerify 91 FileSet: Verify Set 92 Level: Catalog 93 Client: MatouVerify 94 Storage: DLTDrive 95 Verify Job: 96 Verify List: /tmp/regress/working/MatouVerify.bsr 97 OK to run? (yes/mod/no): mod 98 99 100 101Here, you want to respond mod to modify the parameters because the Level is by default set to Catalog and we want to run an InitCatalog Job. After responding mod, the console will ask: 102 103 104 105:: 106 107 Parameters to modify: 108 1: Level 109 2: Storage 110 3: Job 111 4: FileSet 112 5: Client 113 6: When 114 7: Priority 115 8: Pool 116 9: Verify Job 117 Select parameter to modify (1-5): 1 118 119 120 121you should select number 2 to modify the Level, and it will display: 122 123 124 125:: 126 127 Levels: 128 1: Initialize Catalog 129 2: Verify Catalog 130 3: Verify Volume to Catalog 131 4: Verify Disk to Catalog 132 5: Verify Volume Data (not yet implemented) 133 Select level (1-4): 1 134 135 136 137Choose item 1, and you will see the final display: 138 139 140 141:: 142 143 Run Verify job 144 JobName: MatouVerify 145 FileSet: Verify Set 146 Level: Initcatalog 147 Client: MatouVerify 148 Storage: DLTDrive 149 Verify Job: 150 Verify List: /tmp/regress/working/MatouVerify.bsr 151 OK to run? (yes/mod/no): yes 152 153 154 155at which point you respond yes, and the Job will begin. 156 157Thereafter the Job will automatically start according to the schedule you have defined. If you wish to immediately verify it, you can simply run a Verify Catalog which will be the default. No differences should be found. 158 159To use a previous job, you can add ``jobid=xxx`` option in run command line. It will run the Verify job against the specified job. 160 161:: 162 163 *run jobid=1 job=MatouVerify 164 Run Verify job 165 JobName: MatouVerify 166 Level: Catalog 167 Client: 127.0.0.1-fd 168 FileSet: Full Set 169 Pool: Default (From Job resource) 170 Storage: File (From Job resource) 171 Verify Job: MatouVerify.2010-09-08_15.33.33_03 172 Verify List: /tmp/regress/working/MatouVerify.bsr 173 When: 2010-09-08 15:35:32 174 Priority: 10 175 OK to run? (yes/mod/no): 176 177What To Do When Differences Are Found 178------------------------------------- 179 180:index:`\ <single: Verify; Differences>`\ 181 182If you have setup your messages correctly, you should be notified if there are any differences and exactly what they are. For example, below is the email received after doing an update of OpenSSH: 183 184 185 186:: 187 188 HeadMan: Start Verify JobId 83 Job=RufusVerify.2002-06-25.21:41:05 189 HeadMan: Verifying against Init JobId 70 run 2002-06-21 18:58:51 190 HeadMan: File: /etc/pam.d/sshd 191 HeadMan: st_ino differ. Cat: 4674b File: 46765 192 HeadMan: File: /etc/rc.d/init.d/sshd 193 HeadMan: st_ino differ. Cat: 56230 File: 56231 194 HeadMan: File: /etc/ssh/ssh_config 195 HeadMan: st_ino differ. Cat: 81317 File: 8131b 196 HeadMan: st_size differ. Cat: 1202 File: 1297 197 HeadMan: SHA1 differs. 198 HeadMan: File: /etc/ssh/sshd_config 199 HeadMan: st_ino differ. Cat: 81398 File: 81325 200 HeadMan: st_size differ. Cat: 1182 File: 1579 201 HeadMan: SHA1 differs. 202 HeadMan: File: /etc/ssh/ssh_config.rpmnew 203 HeadMan: st_ino differ. Cat: 812dd File: 812b3 204 HeadMan: st_size differ. Cat: 1167 File: 1114 205 HeadMan: SHA1 differs. 206 HeadMan: File: /etc/ssh/sshd_config.rpmnew 207 HeadMan: st_ino differ. Cat: 81397 File: 812dd 208 HeadMan: st_size differ. Cat: 2528 File: 2407 209 HeadMan: SHA1 differs. 210 HeadMan: File: /etc/ssh/moduli 211 HeadMan: st_ino differ. Cat: 812b3 File: 812ab 212 HeadMan: File: /usr/bin/scp 213 HeadMan: st_ino differ. Cat: 5e07e File: 5e343 214 HeadMan: st_size differ. Cat: 26728 File: 26952 215 HeadMan: SHA1 differs. 216 HeadMan: File: /usr/bin/ssh-keygen 217 HeadMan: st_ino differ. Cat: 5df1d File: 5e07e 218 HeadMan: st_size differ. Cat: 80488 File: 84648 219 HeadMan: SHA1 differs. 220 HeadMan: File: /usr/bin/sftp 221 HeadMan: st_ino differ. Cat: 5e2e8 File: 5df1d 222 HeadMan: st_size differ. Cat: 46952 File: 46984 223 HeadMan: SHA1 differs. 224 HeadMan: File: /usr/bin/slogin 225 HeadMan: st_ino differ. Cat: 5e359 File: 5e2e8 226 HeadMan: File: /usr/bin/ssh 227 HeadMan: st_mode differ. Cat: 89ed File: 81ed 228 HeadMan: st_ino differ. Cat: 5e35a File: 5e359 229 HeadMan: st_size differ. Cat: 219932 File: 234440 230 HeadMan: SHA1 differs. 231 HeadMan: File: /usr/bin/ssh-add 232 HeadMan: st_ino differ. Cat: 5e35b File: 5e35a 233 HeadMan: st_size differ. Cat: 76328 File: 81448 234 HeadMan: SHA1 differs. 235 HeadMan: File: /usr/bin/ssh-agent 236 HeadMan: st_ino differ. Cat: 5e35c File: 5e35b 237 HeadMan: st_size differ. Cat: 43208 File: 47368 238 HeadMan: SHA1 differs. 239 HeadMan: File: /usr/bin/ssh-keyscan 240 HeadMan: st_ino differ. Cat: 5e35d File: 5e96a 241 HeadMan: st_size differ. Cat: 139272 File: 151560 242 HeadMan: SHA1 differs. 243 HeadMan: 25-Jun-2002 21:41 244 JobId: 83 245 Job: RufusVerify.2002-06-25.21:41:05 246 FileSet: Verify Set 247 Verify Level: Catalog 248 Client: RufusVerify 249 Start time: 25-Jun-2002 21:41 250 End time: 25-Jun-2002 21:41 251 Files Examined: 4,258 252 Termination: Verify Differences 253 254 255 256At this point, it was obvious that these files were modified during installation of the RPMs. If you want to be super safe, you should run a Verify Level=Catalog immediately before installing new software to verify that there are no differences, then run a Verify Level=InitCatalog immediately after the installation. 257 258To keep the above email from being sent every night when the Verify Job runs, we simply re-run the Verify Job setting the level to InitCatalog (as we did above in the very beginning). This will re-establish the current state of the system as your new basis for future comparisons. Take care that you don’t do an InitCatalog after someone has placed a Trojan horse on your system! 259 260If you have included in your FileSet a file that is changed by the normal operation of your system, you will get false matches, and you will need to modify the FileSet to exclude that file (or not to Include it), and then re-run the InitCatalog. 261 262The FileSet that is shown below is what I use on my Red Hat 7.3 system. With a bit more thought, you can probably add quite a number of additional files that should be monitored. 263 264A Verify Configuration Example 265------------------------------ 266 267:index:`\ <single: Verify; Example>`\ 268 269 270 271:: 272 273 Schedule { 274 Name = "VerifyCycle" 275 Run = Level=Catalog sun-sat at 5:05 276 } 277 Job { 278 Name = "MatouVerify" 279 Type = Verify 280 Level = Catalog # default level 281 Client = MatouVerify 282 FileSet = "Verify Set" 283 Messages = Standard 284 Storage = DLTDrive 285 Pool = Default 286 Schedule = "VerifyCycle" 287 } 288 # 289 # The list of files in this FileSet should be carefully 290 # chosen. This is a good starting point. 291 # 292 FileSet { 293 Name = "Verify Set" 294 Include { 295 Options { 296 verify=pins1 297 signature=SHA1 298 } 299 File = /boot 300 File = /bin 301 File = /sbin 302 File = /usr/bin 303 File = /lib 304 File = /root/.ssh 305 File = /home/user/.ssh 306 File = /var/named 307 File = /etc/sysconfig 308 File = /etc/ssh 309 File = /etc/security 310 File = /etc/exports 311 File = /etc/rc.d/init.d 312 File = /etc/sendmail.cf 313 File = /etc/sysctl.conf 314 File = /etc/services 315 File = /etc/xinetd.d 316 File = /etc/hosts.allow 317 File = /etc/hosts.deny 318 File = /etc/hosts 319 File = /etc/modules.conf 320 File = /etc/named.conf 321 File = /etc/pam.d 322 File = /etc/resolv.conf 323 } 324 Exclude = { } 325 } 326 Client { 327 Name = MatouVerify 328 Address = lmatou 329 Catalog = Bareos 330 Password = "" 331 File Retention = 80d # 80 days 332 Job Retention = 1y # one year 333 AutoPrune = yes # Prune expired Jobs/Files 334 } 335 Catalog { 336 Name = Bareos 337 dbname = verify; user = bareos; password = "" 338 } 339 340 341 342 343 344 345