ആമുഖം

മിക്കവാറും എല്ലാ ഫാൽക്കോ നിയമങ്ങൾക്കും നിയമം കണ്ടുപിടിച്ച പെരുമാറ്റം അനുവദിക്കണമെന്നുള്ള സാഹചര്യങ്ങളുണ്ട്.ഉദാഹരണത്തിന്, Binary Dir എന്നതിന് താഴെ എഴുതുക എന്ന നിയമത്തിന്, സോഫ്റ്റ്വെയർ ഇൻസ്റ്റാളേഷൻ/മാനേജ്മെൻറിൻറെ ഭാഗമായി ഈ ഡയറക്റ്ററികൾക്ക് താഴെ എഴുതുന്നതിനാൽ അറിയപ്പെടുന്ന പ്രത്യേക പ്രോഗ്രാമുകൾക്കായി എക്സെപ്ഷനുകളുണ്ട്:

- rule: binary dir എന്നതിന് താഴെ എഴുതുക
  desc: ഒരു ബൈനറി ഡയറക്റ്ററിഗണത്തിൻറെ താഴെയുള്ള ഏത് ഫയലിലേക്കും എഴുതാനുള്ള ഒരു ശ്രമം
  condition: >
    bin_dir and evt.dir = < and open_write
    and not package_mgmt_procs
    and not exe_running_docker_save
    and not python_running_get_pip
    and not python_running_ms_oms
    and not user_known_write_below_binary_dir_activities
...

മുൻപ്, ഈ എക്സെപ്ഷനുകൾ യഥാർത്ഥ നിയമത്തിൻറെ വ്യവസ്ഥയിലേക്ക് ശൃംഖലകളായി എക്സ്പ്രസ്സ് ചെയ്തിരുന്നു. ഉദാഹരണത്തിന്, package_mgmt_procs എന്ന മാക്രോയിലേക്ക് നോക്കുമ്പോൾ:

- macro: package_mgmt_procs
  condition: proc.name in (package_mgmt_binaries)

ഫലം നിയമത്തിൻറെ വ്യവസ്ഥയിലേക്ക് and not proc.name in (package_mgmt_binaries) എന്നതിനെ അനുബന്ധിക്കലാണ്.

ഇതിൻറെ കൂടുതൽ തീവ്രമായ ഒരു സാഹചര്യം write_below_etc എന്ന മാക്രോ Write below etc എന്ന നിയമത്താൽ ഉപയോഗിക്കപ്പെടുന്നതാണ്. ഇതിന് പത്തോളം എക്സെപ്ഷനുകളുണ്ടായിരുന്നു:

...
    and not sed_temporary_file
    and not exe_running_docker_save
    and not ansible_running_python
    and not python_running_denyhosts
    and not fluentd_writing_conf_files
    and not user_known_write_etc_conditions
    and not run_by_centrify
    and not run_by_adclient
    and not qualys_writing_conf_files
    and not git_writing_nssdb
...

എക്സെപ്ഷനുകളെല്ലാം സാധാരണയായി ഒരേ ഘടന തന്നെയാണ് പിന്തുടരുന്നത് ഒരു പ്രോഗ്രാമും ഒരു ഡയറക്റ്ററി പ്രീഫിക്സും, /etc എന്നതിന് താഴെ ആ പ്രോഗ്രാമിന് ഫയലുകൾ എഴുതാൻ അനുമതിയുള്ളിടത്ത് നാമകരണം ചെയ്യുന്നത്.

നിയമത്തിലെ എക്സെപ്ഷനുകൾ

0.28.0 മുതൽ, ഫാൽക്കോ നിയമങ്ങൾ ഒരു ഓപ്ഷണൽ exceptions സവിശേഷത പിന്തുണക്കുന്നു. എക്സെപ്ഷനുകൾ കീ എന്നത് ഐഡൻ്റിഫയറിൻറെ ലിസ്റ്റും കൂടാതെ ഫിൽട്ടർചെക്ക് ഫീൽഡുകളുടെ ട്യൂപ്പിളുകളുടെ ലിസ്റ്റും ആണ്. ഇതാ ഒരു ഉദാഹരണം:

- rule: binary dir എന്നതിന് താഴെ എഴുതുക
  desc: ഒരു ബൈനറി ഡയറക്റ്ററിഗണത്തിൻറെ താഴെയുള്ള ഏത് ഫയലിലേക്കും എഴുതാനുള്ള ഒരു ശ്രമം
  condition: >
    bin_dir and evt.dir = < and open_write
    and not package_mgmt_procs
    and not exe_running_docker_save
    and not python_running_get_pip
    and not python_running_ms_oms
    and not user_known_write_below_binary_dir_activities
  exceptions:
   - name: proc_writer
     fields: [proc.name, fd.directory]
   - name: container_writer
     fields: [container.image.repository, fd.directory]
     comps: [=, startswith]
   - name: proc_filenames
     fields: [proc.name, fd.name]
     comps: [=, in]
   - name: filenames
     fields: fd.filename
     comps: in

നാല് തരത്തിലുള്ള എക്സെപ്ഷനുകൾ ഈ നിയമം നിർവചിക്കുന്നു:

• proc_writer: proc.name, fd.directory എന്നിവയുടെ ഒരു സമ്മിശ്രണം ഉപയോഗിക്കുന്നു
• container_writer: container.image.repository, fd.directory എന്നിവയുടെ ഒരു സമ്മിശ്രണം ഉപയോഗിക്കുന്നു
• proc_filenames: പ്രക്രിയ, ഫയൽനാമങ്ങളുടെ ലിസ്റ്റ് എന്നിവയുടെ ഒരു സമ്മിശ്രണം ഉപയോഗിക്കുന്നു.
• filenames: ഫയൽനാമങ്ങളുടെ ഒരു ലിസ്റ്റ് ഉപയോഗിക്കുന്നു

"proc_writer"/"container_writer"/"proc_filenames"/"filenames" എന്നീ പ്രത്യേക സ്ട്രിങ്ങുകൾ ആർബിട്രറി സ്ട്രിങ്ങുകളാണ്, കൂടാതെ അവക്ക് നിയമഫയൽ പാർസറിലേക്ക് പ്രത്യേക അർത്ഥമൊന്നുമില്ല. അവയെ ആകെ ഉപയോഗിക്കുന്നത് എക്സെപ്ഷൻ ഓബ്ജക്റ്റിൽ നിലനിൽക്കുന്ന ഫീൽഡ് മൂല്യങ്ങളുടെ ലിസ്റ്റുമായി ഫീൽഡ് നാമങ്ങളുടെ ലിസ്റ്റിനെ കൂട്ടി ബന്ധിപ്പിക്കുന്നതിനാണ്.

proc_writer എന്നതിന് ഒരു കോംപ്സ് സവിശേഷതയുമില്ല, അതിനാൽ ഫീൽഡുകൾ = എന്ന ഓപ്പറേറ്റർ ഉപയോഗിച്ച് മൂല്യങ്ങളിലേക്ക് നേരിട്ട് താരതമ്യം ചെയ്യപ്പെടുന്നു. container_writer എന്നതിന് ഒരു കോംപ്സ് സവിശേഷതയുമില്ല, അതിനാൽ ഓരോ ഫീൽഡും അനുബന്ധ എക്സെപ്ഷൻ ഇനങ്ങളുമായി അനുബന്ധ താരതമ്യഓപ്പറേറ്റർ ഉപയോഗിച്ച് താരതമ്യം ചെയ്യപ്പെടും.

proc_filenames ഇൻ കംപാരിസൺ ഓപ്പറേറ്ററാണ് ഉപയോഗിക്കുന്നത്, അതിനാൽ അനുബന്ധമൂല്യങ്ങളുടെ എൻട്രി ഫയൽനാമങ്ങളുടെ ലിസ്റ്റ് ആയിരിക്കണം.

ഫയൽനാമങ്ങൾ മറ്റുള്ളവയിൽ നിന്നും വ്യത്യസ്തമാണ്, അത് ഒരൊറ്റ ഫീൽഡിനെയും കോംപ് ഓപ്പറേറ്ററെയും നാമകരണം ചെയ്യുന്നു. ഇത് എക്സെപ്ഷൻ വ്യവസ്ഥാസ്നിപ്പറ്റ് എങ്ങനെ നിർമ്മിക്കുന്നു എന്നതിനെ മാറ്റുന്നു (താഴെ നോക്കുക).

എക്സെപ്ഷനുകൾ നിയമത്തിൻറെ ഭാഗമായാണ് നിർവചിക്കുന്നതെന്ന് ശ്രദ്ധിക്കുക. ഇത് പ്രധാനമാണ്, കാരണം, നിയമത്തിന് സാധുവായ എക്സെപ്ഷൻ എന്താണെന്ന് നിയമനിർമ്മാതാവാണ് നിർവചിക്കുന്നത്. ഈ സാഹചര്യത്തിൽ, ഒരു എക്സെപ്ഷനിൽ ഒരു പ്രക്രിയയും ഫയൽ ഡയറക്റ്ററിയും അടങ്ങിയിരിക്കാൻ കഴിയും( ആക്റ്ററും ലക്ഷ്യവും), പക്ഷേ പ്രക്രിയാനാമം മാത്രമായി കഴിയില്ല (കൂടുതൽ വിസ്തൃതം).

append: true എന്നതിനോടൊപ്പമാണ് എക്സെപ്ഷൻ മൂല്യങ്ങൾ ഏറ്റവും സാധാരണയായി നിയമങ്ങളിൽ നിർവചിക്കപ്പെടുക. ഇതാ ഒരു ഉദാഹരണം:

- list: apt_files
  items: [/bin/ls, /bin/rm]

- rule: Write below binary dir
  exceptions:
  - name: proc_writer
    values:
    - [apk, /usr/lib/alpine]
    - [npm, /usr/node/bin]
  - name: container_writer
    values:
    - [docker.io/alpine, /usr/libexec/alpine]
  - name: proc_filenames
    values:
    - [apt, apt_files]
    - [rpm, [/bin/cp, /bin/pwd]]
  - name: filenames
    values: [python, go]
  append: true

ഒരു നിയമ എക്സെപ്ഷൻ, ഒരു തന്നിരിക്കുന്ന ഇവൻറിനായി exception.item എന്നതിലെ എല്ലാ മൂല്യങ്ങളുമായി rule.exception എന്നതിലെ ഫീൽഡുകൾ പൊരുത്തപ്പെടുന്നുണ്ടെങ്കിലാണ് പ്രയോഗിക്കുന്നത്. ഉദാഹരണത്തിന്, ഒരു പ്രോഗ്രാം apk , /usr/lib/alpine എന്നതിന് താഴെ ഒരു ഫയലിലേക്ക് എഴുതുകയാണെങ്കിൽ, വ്യവസ്ഥ പാലിക്കുന്നുണ്ടെങ്കിൽ പോലും നിയമം ട്രിഗർ ചെയ്യുകയില്ല.

മൂല്യ ലിസ്റ്റിലുള്ള ഒരു ഇനം ഒരു ലിസ്റ്റ് ആകാം എന്ന് ശ്രദ്ധിക്കുക. ഇത് ഇനങ്ങളുടെ ഒരു ലിസ്റ്റിൽ പ്രവർത്തിക്കുന്ന "in", "pmatch" മുതലായവ പോലുള്ള ഓപ്പറേറ്ററുകളോട് കൂടിയ എക്സെപ്ഷനുകൾ നിർമ്മിക്കുന്നത് അനുവദിക്കുന്നു. ഇനം ഒരു നിലവിലുള്ള ലിസ്റ്റിൻറെ പേരും ആകാം. അങ്ങനെയല്ലെങ്കിൽ പ്രെസെൻറ് സറൌണ്ടിങ് പാരെൻതെസിസ് ചേർക്കപ്പെടും.

അവസാനമായി, മൂല്യസവിശേഷതയുടെ ഘടന അതൊരു സിംഗിൾ ഫീൽഡ് ആവുമ്പോഴും (procs_only), ഫീൽഡുകൾ ഒരു ഫീൽഡുകളുടെ ലിസ്റ്റ് ആവുമ്പോഴും (proc_writer/container_writer/proc_filenames) ഇനങ്ങൾക്കിടയിൽ വ്യത്യസ്തമായിരിക്കും എന്നത് ശ്രദ്ധിക്കുക. എങ്ങനെ വ്യവസ്ഥാസ്നിപ്പെറ്റ് നിർമ്മിക്കുന്നു എന്നത് ഇത് മാറ്റുന്നു.

എക്സെപ്ഷൻസ്: വ്യവസ്ഥകൾക്കായുള്ള സിൻടാക്റ്റിക് ഷുഗർ

എക്സെപ്ഷൻ ഇനങ്ങൾക്ക്, ഫീൽഡ്സ് സവിശേഷത ഫീൽഡ് നാമങ്ങളുടെ ഒരു ലിസ്റ്റ് ആകുമ്പോൾ ഓരോ എക്സെപ്ഷനും നിയമത്തിൻറെ വ്യവസ്ഥയിലേക്ക് അനുബന്ധിപ്പിക്കുന്ന സ്പഷ്ടമായ " എന്നത് ആയിട്ടാണ്, അല്ലാതെ (field1 cmp1 val1 and field2 cmp2 val2 and...)" എന്നത് ആയിട്ടല്ല കണക്കാക്കപ്പെടുന്നത്. എക്സെപ്ഷൻ ഇനങ്ങൾക്ക്, ഫീൽഡ്സ് സവിശേഷത ഒരു സിംഗിൾ ഫീൽഡ് നാമം ആകുമ്പോൾ, എക്സെപ്ഷൻ ഒരു സ്പഷ്ടമായ " എന്നത് ആയിട്ടാണ്, അല്ലാതെ field cmp (val1, val2, ...)" എന്നത് ആയിട്ടല്ല കണക്കാക്കപ്പെടുന്നത്. അങ്ങനെയാണ് എക്സെപ്ഷനുകൾ നടപ്പിലാക്കുന്നത്-- നിയമങ്ങൾ പാർസുചെയ്യുമ്പോൾ, വ്യവസ്ഥ സമാഹരിക്കുന്നതിന് മുൻപ് എക്സെപ്ഷനുകൾ മുകളിലുള്ളവ പോലുള്ള ഒരു സ്ട്രിങ്ങിലേക്ക് മാറ്റുകയും വ്യവസ്ഥയിലേക്ക് അനുബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

ഒരു നിയമം പാർസുചെയ്തുകഴിഞ്ഞാൽ, യഥാർത്ഥ വ്യവസ്ഥ പാരെൻതെസെസിൻറെ ഒരു അധിക ലേയറിൽ പൊതിഞ്ഞിരിക്കുകയും എല്ലാ എക്സെപ്ഷൻ മൂല്യങ്ങളും വ്യവസ്ഥയിലേക്ക് അനുബന്ധിപ്പിക്കുകയും ചെയ്തിരിക്കുന്നു. ഉദാഹരണത്തിന്, മുകളിലുള്ള ഉദാഹരണം ഉപയോഗിക്കുമ്പോൾ തത്ഫലമായുണ്ടാകുന്ന വ്യവസ്ഥ ഇതാണ്:

(<Write below binary dir condition>) and not (
    (proc.name = apk and fd.directory = /usr/lib/alpine) or (proc.name = npm and fd.directory = /usr/node/bin) or
	(container.image.repository = docker.io/alpine and fd.directory startswith /usr/libexec/alpine) or
	(proc.name=apt and fd.name in (apt_files))) or
	(fd.filename in (python, go))))

എക്സെപ്ഷനുകൾ ഫലപ്രദമായി, സംക്ഷിപ്തമായ മാർഗ്ഗത്തിൽ എക്സെപ്ഷനുകളുടെ കൂട്ടങ്ങൾ എക്സ്പ്രസ്സ് ചെയ്യുന്നത് അനുവദിക്കുന്ന സിൻടാക്റ്റിക് ഷുഗറാണ്

നിയമങ്ങൾക്ക് എക്സെപ്ഷനുകൾ ചേർക്കുന്നതിൻറെ മാർഗ്ഗനിർദ്ദേശങ്ങൾ

സാധ്യമാകുമ്പോഴെല്ലാം എക്സെപ്ഷനുകൾ ഉപയോഗിക്കുന്നതിന് ഡീഫോൾട്ട് നിയമഫയലുകൾ നവീകരിച്ചിരിക്കുന്നു, കൂടാതെ നിയമങ്ങൾക്കായുള്ള എക്സെപ്ഷനുകൾ നിർവചിക്കുമ്പോൾ മികച്ച പരിശീലനങ്ങക്കുള്ള നല്ല റഫറൻസുകളുമാണ് ഇവ. പിന്തുടരാനുള്ള മറ്റു ചില മാർഗ്ഗനിർദ്ദേശങ്ങൾ ഇതാ:

കൃത്യമാകുക

ഒരു എക്സെപ്ഷൻ നിർവചിക്കുമ്പോൾ, ആക്റ്റർ, പ്രവൃത്തി, ലക്ഷ്യം എന്നിവയെ കുറിച്ച് ചിന്തിക്കാൻ ശ്രമിക്കുക, കൂടാതെ സാധ്യമാകുമ്പോഴെല്ലാം എക്സെപ്ഷനായി എല്ലാ 3 ഇനങ്ങളും ഉപയോഗിക്കുക.ഉദാഹരണത്തിന്, ഒരു ഫയൽ- അടിസ്ഥാന എക്സെപ്ഷനായി എളുപ്പത്തിൽ proc.name അല്ലെങ്കിൽ container.image.repository എന്നിവ ഉപയോഗിക്കുന്നതിന് പകരം, ഫയൽ പ്രവർത്തിപ്പിക്കുന്നത് fd.name, fd.directory മുതലായവ വഴിയാണ് എന്നുകൂടി ഉൾപ്പെടുത്തുക. അതുപോലെ, ഒരു നിയമം കണ്ടെയ്നറിന് പ്രത്യേകമായുള്ളതാണെങ്കിൽ, container.image.repository എന്ന ചിത്രം മാത്രമല്ല, പ്രക്രിയാനാമം proc.name കൂടി ഉൾപ്പെടുത്തുക.

സെറ്റ് ഓപ്പറേറ്ററുകൾ ഉപയോഗിക്കുക

ഒരു എക്സെപ്ഷൻ, പ്രക്രിയാനാമങ്ങൾ, ഫയൽ മാർഗ്ഗങ്ങൾ മുതലായവയുടെ ഒരു സെറ്റ് ഉൾക്കൊള്ളുന്നുവെങ്കിൽ, പ്രക്രിയാനാമങ്ങളെ ഒരു ലിസ്റ്റിലേക്ക് കൂട്ടിച്ചേർക്കുകയും, ഒരു സിംഗിൾ എക്സെപ്ഷനിലെ മൂല്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിന്, in/pmatch ഓപ്പറേറ്റർ ഉപയോഗിക്കുകയും ചെയ്യുക. ഇതാ ഒരു ഉദാഹരണം:

    - name: proc_file
      fields: [proc.name, fd.name]
      comps: [in, in]
      values:
        - [[qualys-cloud-ag], [/etc/qualys/cloud-agent/qagent-log.conf]]
        - [[update-haproxy-,haproxy_reload.], [/etc/openvpn/client.map]]
        - [[start-fluentd], [/etc/fluent/fluent.conf, /etc/td-agent/td-agent.conf]]

ഈ എക്സെപ്ഷൻ പ്രക്രിയാനാമവും മാർഗ്ഗവുമായി പൊരുത്തപ്പെടുന്നു, എന്നാൽ ഏതൊരു ഫയൽസെറ്റിലേക്കും ഒന്നിലധികം പ്രക്രിയാനാമങ്ങൾ എഴുതുന്നതിന് അനുവദിക്കുകയും ചെയ്യുന്നു.

കൂടുതൽ വിവരങ്ങൾ

യഥാർത്ഥ proposal എക്സെപ്ഷനുകളുടെ ഗുണങ്ങളെ കൂടുതൽ വിശദാംശങ്ങളോടെ വിവരിക്കുന്നു.