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

Java Garbage Collection

Garbage collection is the process of looking at heap memory, identifying which objects are in use and which are not, and deleting the unused objects.

unused objects are considered to be any instances that cannot be reached by a live thread or for circularly referenced instances that cannot be reached by any other instances.

The basic process are :

1. Marking : garbage collector identifies which objects are used and which are unused.
2. Deletion: remove unused object and pointer to free space.
3. Compacting : To improve performance move used object together so that there is no gap among them.   

Having to mark, delete and compact all the objects in a JVM is inefficient. empirical analysis of applications has shown that most objects are short lived and fewer objects remain allocated over time hence JVM Heap is broken into smaller parts as Young Generation, Tenured/ Old generation, Permanent Generation(removed in java 8).

Young Generation: This part of the heap is further divided into Eden Space, First survivor space, and Second survivor space.

Old Generation: long survived object are stored after minor GC.  

Permanent Generation: contain metadata of class and methods  required by JVM.

Few Important Terms:

Minor GC: minor GC triggered when JVM unable to allocate memory for new object. Generally when Eden space is full.

Major GC: happens for the Old Generation or aged Objects.

Stop The World : All minor/major garbage collections are "Stop the World" events means that all application threads are stopped until the operation completes.

Generational Garbage Collection Process:

1. New objects are allocated to the eden space.
2. When eden space is full minor GC triggered referenced object moved to first survivor space and eden space is cleared. During each minor GC aged object from first survivor space moved to second survivor space.
3. As minor GCs continued age of the survived objects incremented and at certain threshold they moved to Old generation space. a major GC will be performed on the old generation which cleans up and compacts that space.

Garbage Collectors:

The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

1. Serial Collector : Uses a single thread to perform GC hence it cannot take advantage of multiprocessor useful for application with small data sets. The serial collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseSerialGC.

2. Parallel Collector: known as the throughput collector performs collections in parallel, which can significantly reduce garbage collection overhead and intended for applications with medium-sized to large-sized data sets that are run on multiprocessor or multithreaded hardware. default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseParallelGC.

3. Concurrent collector :  Java Hotspot VM has two mostly concurrent collectors are Concurrent Mark Sweep(CMS Collector) and Garbage-First Garbage Collector(java 8).

Characterize the actual different primary garbage collectors:

Young generation collectors

1. Serial collector (enabled with -XX:+UseSerialGC)
2. PS Scavenge (enabled with -XX:+UseParallelGC)
3. ParNew (enabled with -XX:+UseParNewGC)
4. G1 Young Generation (enabled with -XX:+UseG1GC)

Old generation collectors

1. MarkSweepCompact (enabled with -XX:+UseSerialGC)
2. PS MarkSweep (enabled with -XX:+UseParallelOldGC)
3. ConcurrentMarkSweep (enabled with -XX:+UseConcMarkSweepGC)
4. G1 Mixed Generation (enabled with -XX:+UseG1GC)

All of the garbage collection algorithms except ConcurrentMarkSweep are stop-the-world, it tries to do most of it's work in the background and minimize the pause time, but it also has a stop-the-world phase and can fail into the MarkSweepCompact which is fully stop-the-world.

Reference :

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

Spring Transaction

Transaction comprises of a unit of work against a database. Transaction provides “all or noting” preposition unit of work performed entirely committed or rollback.

Unit of work: consider to transfer account balance from account A to account B we have to debit account A and credit account B and this is a unit of work performed to do transfer.

Acronym ACID describes the nature or properties for transaction.

•   Atomic: All of the operations in a transaction happen or none of them happen.  
•   Consistent: After a successful or failed transaction system is left in a consistent state.
• Isolation: it is about concurrent read write if two or more transaction progressing at time. 
•  Durable: after a successful transaction data is persisted permanently.  

Transaction attributes:

• Propagation

1.     PROPAGATION_REQUIRED: transaction already exists then the code will use it otherwise a new transaction is created. This is the default.

2.     PROPAGATION_SUPPORTS: transaction exists then the code will use it, but the code does not require a new one.

3.     PROPAGATION_MANDATORY: Participates in an existing transaction, however if no transaction context is present then it throws a TransactionRequiredException.

4.     PROPAGATION_REQUIRES_NEW: new transaction and if an existing transaction is present then it is suspended. When the new transaction is complete then the original transaction resumes.

5.     PROPAGATION_NOT_SUPPORTED: operations needs to be performed non-transitionally.

6.     PROPAGATION_NEVER: code cannot be invoked within a transaction. if an existing transaction is present then an exception will be thrown.

7.     PROPAGATION_NESTED: code is executed within a nested transaction if existing transaction is present; if no transaction is present then a new transaction is created.

• Isolation

1.     ISOLATION_DEFAULT: Use the isolation level of the underlying database. This is the default.

2.     ISOLATION_READ_UNCOMMITTED:  dirty reads, phantom reads and non-repeatable reads.

3.     ISOLATION_READ_COMMITTED: prevents dirty reads but allows phantom reads and non-repeatable reads.

4.     ISOLATION_REPEATABLE_READ: prevents dirty reads and non-repeatable reads but allows phantom reads.

5.     ISOLATION_SERIALIZABLE: prevents dirty reads, non repeatable reads and phantom reads.

Dirty Reads- Dirty reads occur when transaction B reads data that has been modified by transaction A but not committed. The problem occurs when transaction A rollbacks the transaction, in which case the data read by transaction B will be invalid.

Non Repeatable Reads- Non-repeatable reads happen when a transaction fires the same query multiple times but receives different data each time for the same query.

Phantom Reads - Phantom reads occur when the collection of rows returned is different when a same query is executed multiple times in a transaction.

• Read only: The read only attribute specifies that the transaction is only going to read data from a database. by default false.
• Rollback rule: specify that transactions roll back on certain exceptions and do not rollback on other exceptions.By default RuntimeException.
• Timeout: Timeout specifies the maximum time allowed for a transaction to run then rolled back.

Spring Transaction supports:

• It offers both programmatic and declarative transaction.
• Declarative transaction can be used in stand-alone application unlike EJB.
• Support wide range of transactional manager,.
• Spring transactions are good at application using single database. I multiple databases access required have to use XA transaction of JTA.

Spring transaction managers: soring does not manage transaction directly rather delegate the responsibility to configured platform specific transaction manager.

JDBC	DataSourceTransactionManager
Hibernate	HibernateTransactionManager
JDO	JdoTransactionManager
JTA	JtaTransactionManager
JPA	JpaTransactionManager

x