Juniper screen OS debug transaction flow

Capturing Debug flow basic:

Cl db

Set ff src-ip x.x.x.x dst-ip y.y.y.y

Set ff src-ip y.y.y.y dst-ip x.x.x.x

(where

x.x.x.x== client ip which is accessing the server y.y.y.y==public ip of server i.e VIP ip of the server)

debug flow basic

(Then initiate the concerned traffic from source x.x.x.x to y.y.y.y)

Get db str

Undebug all

Cl db

Capturing snoop detail

Cl db

Snoop filter ip src-ip x.x.x.x dst-ip y.y.y.y direction both Snoop detail len 1514 Snoop (and then press `y?)

(Then initiate the concerned traffic from source x.x.x.x to y.y.y.y)

Get db str

Snoop off

Samba join domain win2008 + squid authentication with ntlm_auth

Step:

1. upgrade samba to 3.5 (for win2008)
2. edit /etc/samba/smb.conf
3. edit /etc/krb5.conf
4. edit /etc/pam.d/system-auth
5. add winbind option in /etc/nsswitch.conf
6. config iptables to allow 139,445,389 port, or allow all for testing
7. change selinux to permissive or disable just for testing
8. setup time, ensure no more than 5 min different with your DC 
9. startup smb, winbind, oddjobd
10. join domain
11. test with wbinfo, kinit, ntlm_auth, check if your linux host appear in AD\computer ou
12. edit /etc/squid/squid.conf
13. make sure squid group have permission to access /var/lib/samba/winbindd_privilege folder
14. Startup squid
15. client pc proxy config
16. client pc edit group policy, change Network security: LAN Manager authentication level:Send LM & NTLM - use NTLMv2 
17. client pc test to access internet with user authentication

For detail please check here:

Using Local Group Policy Editor for security issue

ref.: http://www.techrepublic.com/blog/10things/10-ways-to-tweak-windows-7-using-the-local-group-policy-editor/1014

ICMP Security Failures Messages

Error Procedures

   As is usual with ICMP messages, upon receipt of one of these error
   messages that is uninterpretable or otherwise contains an error, no
   ICMP error message is sent in response.  Instead, the message is
   silently discarded.  However, for diagnosis of problems, a node
   SHOULD provide the capability of logging the error, including the
   contents of the silently discarded datagram, and SHOULD record the
   event in a statistics counter.

   On receipt, special care MUST be taken that the ICMP message actually
   includes information that matches a previously sent IP datagram.
   Otherwise, this might provide an opportunity for a denial of service
   attack.

IDS vs. IPS Explained

Layered security is the key to protecting any size network, and for most companies, that means deploying both intrusion detection systems (IDS) and intrusion prevention systems (IPS). When it comes to IPS and IDS, it?s not a question of which technology to add to your security infrastructure ? both are required for maximum protection against malicious traffic. In fact, vendors are increasingly combining the two technologies into a single box.

IDS
At its most basic, an IDS device is passive, watching packets of data traverse the network from a monitoring port, comparing the traffic to configured rules, and setting off an alarm if it detects anything suspicious. An IDS can detect several types of malicious traffic that would slip by a typical firewall, including network attacks against services, data-driven attacks on applications, host-based attacks like unauthorized logins, and malware like viruses, Trojan horses, and worms. Most IDS products use several methods to detect threats, usually signature-based detection, anomaly-based detection, and stateful protocol analysis.

IPS
At its most basic, an IPS has all the features of a good IDS, but can also stop malicious traffic from invading the enterprise. Unlike an IDS, an IPS sits inline with traffic flows on a network, actively shutting down attempted attacks as they?re sent over the wire. It can stop the attack by terminating the network connection or user session originating the attack, by blocking access to the target from the user account, IP address, or other attribute associated with that attacker, or by blocking all access to the targeted host, service, or application.

In addition, an IPS can respond to a detected threat in two other ways. It can reconfigure other security controls, such as a firewall or router, to block an attack. Some IPS devices can even apply patches if the host has particular vulnerabilities. In addition, some IPS can remove the malicious contents of an attack to mitigate the packets, perhaps deleting an infected attachment from an email before forwarding the email to the user.

RADIUS Issues

Response authenticator based Shared Secret Attack
Attacker observes a valid access request packet and the associated return packet(access-accept/access-reject packet), then launch offline exhaustive attack on the shared secret.
They can guess shared secret by pre-compute MD5(Code+ID+length+RequestAuth+Attributes) and resume the hash once.

User-Password Attribute Based Shared Secret Attack

Attacker observes the traffic and try to authenticate to client with a known password, and capture the resulting Access-Request packet and XOR the User-password attribute with the password they provided to client. This results in the value of MD5(S+RA). RA is known in the client request packet, so attacker can launch offline exhaustive attack to get shared secret.

User-Password Based Password Attack
As the previous attack method, attacker can get the value of MD5(S+RA), and replay the modified access request packet as pretending a client. If server dosen't impose user based rate limits, this will allow the attacker to get the correct password.

Request Authenticator Based Attacks
The security of RADIUS depends on the generation of the RA(Request Authenticator)  field, but a lot of implementations using poor PRNG(pseudo random number generation) to generate the RA. If the client uses a PRNG that repeats values (or has a short cycle), the protocol ceases to provide the intended level of protection.

These attacks require the attacker to cause client to produce a particular identifier value. An attacker can insert a series of extra requests to the client, forcing the desired identifier. Even if the identifier were not generated in a readily attackable way, it would still only increase the work factor by 256 times.

Passive User-Password Compromise Through Repeated Request Authenticator
Build dictionary RA--User Password Attribure
If the attacker can sniff the traffic between the RADIUS client and the RADIUS server, they can passively produce a dictionary of Request Authenticators, and the associated (protected) User-Password attributes. If the attacker observes a repeated Request Authenticator, they can remove any influence of the Shared Secret from the first 16 octets of the passwords by XORing the first 16 octets of the protected passwords together. This yields the first 16 octets of the two (now unprotected) user passwords XORed together.

Active User-Password Compromise through Repeated Request Authenticators
Build dictionary RA--MD(S+RA)
Attacker authenticate many times using known passwords and intercept the generated Access-Request packets, extracting the RA and user-password attribute. Then XOR the known password with user-password attribute and be left with the MD5(S+RA) value. Finally, the attacker generates a dictionary of RA and associated MD5(S+RA) value.
Attacker can use this dictionary(RA--MD(S+RA)) to recover the first 16 octets from the protected region of the user password, since c1=p1 XOR MD5(S+RA).

Replay of Server Responses through Repeated Request Authenticators

Using dictionary RA--ID--associate server response

Attacker observe the client request, check RA and ID from the dictionary, then pretend as server the return the associate response to client.

DOS arising from the prediction of the Request Authenticators
Build dictionary predict RA values and associated server response, then response the client's valid request with access-reject packets, implement DOS.

RADIUS authentication procedure

RADIUS packet is below (from the RFC):

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Authenticator                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

• The code establishes the type of RADIUS packet. The codes are:
  

Value	Description
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server (experimental)
13	Status-Client (experimental)
255	Reserved

•  The identifier is a one octet value that allows the RADIUS client to match a RADIUS response with the correct outstanding request. it is usually implemented as a simple counter that is incremented for each request.
• The attributes section is where an arbitrary number of attribute fields are stored. The only pertinent attributes for this discussion are the User-Name and User-Password attributes. 
  

Initial client processing

The client creates an Access-Request RADIUS packet, including at least the User-Name and User-Password attributes.

The Access-Request packet's identifier field is generated by the client.

The Access-Request packet contains a 16 octet Request Authenticator in the authenticator field. This Request authenticator is a randomly chosen 16 octet string. 

This packet is completely unprotected, except for the User-Password attribute, which is protected as follows:

c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
.
.
.
cn = pn XOR MD5(S + cn-1)

The User-Password attribute contains c1+c2+...+cn, Where + denotes concatenation.

Here S is shared secret in server or client, RA is psuedo-random 128bit request authenticator, p1,p2 and so on is 16 octet block by breaking the password

Server processing

• Extract the username and password using the same shared secret
• Validate the account
• Compute response authenticator which is MD5(code+ID+Length+RequestAuth+Attribute+secret), and send back the response packet to client
  

The server receives the RADIUS Access-Request packet and verifies the packet with shared secret first, it can go through a slightly modified version of the client's protection process on the User-Password attribute and obtain the unprotected password. It then uses its authentication database to validate the username and password. If the password is valid, the server creates an Access-Accept packet to send back to the client, otherwise, send back with Access-Reject packet. Both the Access-Accept packet and the Access-Reject packet use the same identifier value from the client's Access-Request packet, and put a Response Authenticator in the Authenticator field. The response authenticator = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

Client post processing

• Match ID
• Compute the Response Authenticator as the server performed
• Check the code field for the result
  

When the client receives a response packet, it attempts to match it with an outstanding request using the identifier field, then verifies the Response Authenticator by performing the same Response Authenticator calculation the server performed, and then comparing the result with the Authenticator field.

If the client received a verified Access-Accept packet, the username and password are considered to be correct, and the user is authenticated.