Configuration Management By Saltstack | Understanding SaltStack | Part 1

SaltStack is a remote execution tool and configuration management system like ansible, puppet or chef. Designed to work with any number of servers, from local network systems to other deployments across different data centers. 

                                                          SaltStack Architecture

Master: 
Master is the main server/machine that controls the infrastructure and dictates policies for the servers/machines that it manages. Master operates both as a repository for the configuration data AND as the control center that initiates remote command and ensures the state of your other machines. A daemon called salt-master runs on the Master to provide this functionality.

Minion:
Servers that Salt Master manages. A daemon salt-minion runs on EACH of the managed machines and is configured to communicate with the Master. The Minion is responsible for executing the instructions sent by the master, and reports back on the success (or failure). Communications between a master and minions occurs over the ZeroMQ message bus.

State/States-
The states are the heart and soul of Salt allows an administrator to describe the state that a system should be placed in. States are stored in text files on the master and transferred to the minions on demand via the master's File Server. The collection of state files make up the State Tree.

Formula-
Salt formulae are pre-written sets of state calls, arranged with the aim of producing a specific result.These are the configuration management files that describe how athe target system should look once the formula has been applied.By default, these are written in the YAML data serialization format, which provides a very good middle ground between high-readability and machine-friendliness. 

A good collection of Salt formulas created by the SaltStack organization and community can by found in this GitHub account.

Grains-
The grains are stored on each minion in YAML and hold OS and hardware specific information like the FQDN of the minion, its minion ID, the CPU flags, IPs of the different interfaces, kernel information, total memory, OS family, the salt version of the minion among other pieces of information; all of this is automatically gathered by Salt. it is fairly common to use grains to assign a "role" to a server. This can then be used to target a subset of nodes similar to the operating system example above.

Pillar- 
Pillar is used to store data, and it can store any kind of data; it is a very versatile system. It usually holds:

    Sensitive data: Passwords, usernames, etc.
    Minion configuration: ie. The name of the Apache package (RedHat based is httpd, Debian based is Apache2)
    Variables: ie. The list of the company DNS servers, or a variable that indicates towhich deparment/subnet/category the minion belongs.

Execution Modules
Salt offers a variety of functions to manage the package system, run tests on the minion, manage files, manage web servers among other things. These functions are called Execution Modules. Salt even allow to write own execution modules

Top File
Matches formulas and Salt pillar data to Salt minions. for further details read this

Runners
Modules that execute on the Salt master to perform supporting tasks. Salt runners report job status, connection status, read data from external APIs, query connected Salt minions, and more.

For example, the Orchestrate runner coordinates configuration deployments across many systems.

Returners
Send data returned by Salt minions to another system, such as a database. Salt returners can run on the Salt minion or on the Salt master.

Reactor
Trigger reactions when events occur in your SaltStack environment.

Salt Cloud/Salt Virt
Provision systems on cloud providers / hypervisors and immediately bring them under management.

Salt SSH
Run Salt commands over SSH on systems that do not have a Salt minion

Ref:
1. https://docs.saltstack.com/en/latest/contents.html
2. https://www.tutorialspoint.com/saltstack/saltstack_architecture.htm
3. https://www.digitalocean.com/community/tutorials/an-introduction-to-saltstack-terminology-and-concepts
4. https://blog.talpor.com/2014/07/saltstack-beginners-tutorial/

OWASP Top 10 Vulnerabilitie

1. SQL Injection Attacks

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data Insert/ Update/ Delete

    
  Defenses:
      1: Use of Prepared Statements (with Parameterized Queries)
      2: Use of Stored Procedures
      3: White List Input Validation
      4: Escaping All User Supplied Input

2. Broken Authentication & Session Management
  Authentication is a critical part of any application, even solid authentication
  mechanisms can be undermined by flawed credential management functions, including
  password policy, password change, forgot my password, remember my password, account
  update, and other related functions.

  Web applications must establish sessions to keep track of the stream of requests
  from each user. HTTP does not provide this capability, so web applications must
  create it themselves. If session identifiers are not properly protected,
  an attacker can hijack an active session and assume the identity of a user.

  Defenses:
    1. Password Strength
    2. Password Use
    3. Password Change Controls
    4. Password Storage
    5. Protecting Credentials in Transit
    6. Session ID Protection

3. Cross-Site Scripting (XSS) Attacks
  Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious
  scripts are injected into trusted web sites generally in the form of a browser
  side script, to a different end user.The end user’s browser has no way to know
  that the script should not be trusted, and will execute the script. Because it
  thinks the script came from a trusted source, the malicious script can access
  any cookies, session tokens, or other sensitive information retained by the
  browser and used with that site.

  Defense:
    1.Never accept actual JavaScript code from an untrusted source and then run it
    2. HTML Escape Before Inserting Untrusted Data into HTML Element Content
    3. JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
    4. CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML
       Style Property Values
    5. URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
    6. Use HTTPOnly cookie flag

4. Insecure Direct Object References
  Insecure Direct Object References occur when an application provides direct access
  to objects based on user-supplied input. As a result of this vulnerability attackers
  can bypass authorization and access resources in the system directly, for example
  database records or files.

  Defense:
    1. Use per user or session indirect object references
    2. Check access

5.Security Misconfiguration
  Security Misconfiguration arises when Security settings are defined, implemented,
  and maintained as defaults. Good security requires a secure configuration defined
  and deployed for the application, web server, database server, and platform. It is
  equally important to have the software up to date.


  1. If Directory listing is not disabled on the server
  2. App server configuration allows stack traces to be returned to users
  3. App servers usually come with sample apps that are not well secured. If not
     removed from production server would result in compromising your server

6.Sensitive Data Exposure
  Sensitive data exposure vulnerabilities can occur when an application does not
  adequately protect sensitive information from being disclosed to attackers.

  Defense
    1. Encrypt the data and define accessibility
    2. Use SSL or TSL to ensure transport layer security
    3. Disable caching for pages that contain sensitive data.

Scenario #1: An application encrypts credit card numbers in a database using automatic
             database encryption. However, this means it also decrypts this data
             automatically when retrieved, allowing an SQL injection flaw to retrieve
             credit card numbers in clear text. The system should have encrypted the credit card
             numbers using a public key, and only allowed back-end applications to
             decrypt them with the private key.
Scenario #2: A site simply doesn’t use SSL for all authenticated pages. Attacker simply
             monitors network traffic (like an open wireless network), and steals the user’s
             session cookie. Attacker then replays this cookie and hijacks the user’s session,
             accessing the user’s private data.
Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file
             upload flaw allows an attacker to retrieve the password file. All of the unsalted
            hashes can be exposed with a rainbow table of pre-calculated hashes.

7. Missing Function Level Access Control
  Most of the web applications verify function level access rights before making
  that functionality accessible to the user. However, if the same access control
  checks are not performed on the server, hackers are able to penetrate into the
  application without proper authorization.

  Defense: The best way to find out if an application has failed to properly restrict
           function level access is to verify every application function:

           1. Does the UI show navigation to unauthorized functions?
           2. Are server side authentication or authorization checks missing?
           3. Are server side checks done that solely rely on information provided by the attacker?

8. Cross Site Request Forgery Attacks
  A CSRF attack forces an authenticated user (victim) to send a forged HTTP request,
  including session cookie, which allows the attacker to force the victim's browser
  to generate request such that the vulnerable app perceives as legitimate requests
  from the victim

  Defense
    1. CSRF can be avoided by using unique token
    2. CAPTCHA can be used to revalidate user.
    3. Only except Post request for the execution of business logic
   

9. Using Components with Known Vulnerabilities Components
  When known vulnerabilities in the code exist, components, such as libraries and
  frameworks delivered from the open source community, shouldn’t be used

  Defense:
    1. Identify all components and the versions that are being used in the webapps
    2. Keep all the components such as public databases, project mailing lists etc. up to date.
    3. Add security wrappers around components that are vulnerable in nature

10. Unvalidated Redirects and Forwards
  Web applications on the internet frequently redirect and forward users to other
  pages or  external websites. Without validating the credibility hackers can redirect
  victims to phishing or malware sites, or use forwards to access unauthorized pages.

  Defense:
    1. Simply avoid using redirects and forwards.
    2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
    3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.



Ref: https://www.owasp.org