|
|
||
|
|
|
|
Network Data Application Security
Fighting the Malware and Data Loss
Tuesday, March 18, 2014
Friday, March 14, 2014
Build and Download 64bit Hadoop 2.3.0
https://svn.apache.org/repos/asf/hadoop/common/trunk/BUILDING.txt
mvn compile -Pdist,native -Dskiptests -Dtar
mvn package -Pdist,native -DskipTests -Dtar
Native Libs
hadoop-2.3.0-src/hadoop-dist/target/hadoop-2.3.0/lib/native/
Tarball
hadoop-2.3.0-src/hadoop-dist/target/hadoop-2.3.0.tar.gz
Download
hdfs namenode -format
Start
hadoop-daemon.sh start namenode
hadoop-daemon.sh start datanode
hadoop-daemon.sh start secondarynamenode
yarn-daemon.sh start resourcemanager
yarn-daemon.sh start nodemanager
mr-jobhistory-daemon.sh start historyserver
jps
1410 NameNode
6500 SecondaryNameNode
1460 DataNode
7030 Jps
6635 ResourceManager
2963 JobHistoryServer
6884 NodeManager
Stop
mr-jobhistory-daemon.sh stop historyserver
yarn-daemon.sh stop nodemanager
yarn-daemon.sh stop resourcemanager
hadoop-daemon.sh start secondarynamenode
hadoop-daemon.sh stop datanode
hadoop-daemon.sh stop namenode
Test Run
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar pi 2 5
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar pi -Dmapreduce.clientfactory.class.name=org.apache.hadoop.mapred.YarnClientFactory 16 10000
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar wordcount file:///home/hadoop/txt/Ulysses.txt /output2
mvn compile -Pdist,native -Dskiptests -Dtar
mvn package -Pdist,native -DskipTests -Dtar
Native Libs
hadoop-2.3.0-src/hadoop-dist/target/hadoop-2.3.0/lib/native/
Tarball
hadoop-2.3.0-src/hadoop-dist/target/hadoop-2.3.0.tar.gz
Download
hdfs namenode -format
Start
hadoop-daemon.sh start namenode
hadoop-daemon.sh start datanode
hadoop-daemon.sh start secondarynamenode
yarn-daemon.sh start resourcemanager
yarn-daemon.sh start nodemanager
mr-jobhistory-daemon.sh start historyserver
jps
1410 NameNode
6500 SecondaryNameNode
1460 DataNode
7030 Jps
6635 ResourceManager
2963 JobHistoryServer
6884 NodeManager
Stop
mr-jobhistory-daemon.sh stop historyserver
yarn-daemon.sh stop nodemanager
yarn-daemon.sh stop resourcemanager
hadoop-daemon.sh start secondarynamenode
hadoop-daemon.sh stop datanode
hadoop-daemon.sh stop namenode
Test Run
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar pi 2 5
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar pi -Dmapreduce.clientfactory.class.name=org.apache.hadoop.mapred.YarnClientFactory 16 10000
hadoop jar /data/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.3.0.jar wordcount file:///home/hadoop/txt/Ulysses.txt /output2
Tuesday, September 3, 2013
Algorithm - RC4
The key-scheduling algorithm
RC4′s KSA uses a loop to iterate through the state and perform the following operation, which generates j and swaps State[i] and State[j]:j = 0; for(i=0; i<256; i++) { j = (j + State[i] + key[i%keylen]) % 256; swap(&State[i], &State[j]); }
The pseudo-random number generation algorithm
In a loop, RC4′s PRNGA deterministically selects elements from the state and outputs them as a keystream with the following code:i = j = 0; for(k=0; k<msglength; k++) { i = (i+1) % 256; j = (j+State[i]) % 256; swap(&State[i], &State[j]); keystream[k] = State[(State[i]+State[j]) % 256]; }
Sample Code
unsigned char S[256]; unsigned int i, j; void swap(unsigned char *s, unsigned int i, unsigned int j) { unsigned char temp = s[i]; s[i] = s[j]; s[j] = temp; } /* KSA */ void rc4_init(unsigned char *key, unsigned int key_length) { for (i = 0; i < 256; i++) S[i] = i; for (i = j = 0; i < 256; i++) { j = (j + key[i % key_length] + S[i]) & 255; swap(S, i, j); } i = j = 0; } /* PRGA */ unsigned char rc4_output() { i = (i + 1) & 255; j = (j + S[i]) & 255; swap(S, i, j); return S[(S[i] + S[j]) & 255]; } #include <stdio.h> #include <string.h> #include <stdlib.h> #define ARRAY_SIZE(a) (sizeof(a)/sizeof(a[0])) int main() { unsigned char *test_vectors[][2] = { {"Key", "Plaintext"}, {"Wiki", "pedia"}, {"Secret", "Attack at dawn"}, {"nick", "Rowe"} }; int x; for (x = 0; x < ARRAY_SIZE(test_vectors); x++) { int y; rc4_init(test_vectors[x][0], strlen((char*)test_vectors[x][0])); for (y = 0; y < strlen((char*)test_vectors[x][1]); y++) printf("%02X", test_vectors[x][1][y] ^ rc4_output()); printf("\n"); } return 0; }
http://blog.markloiseau.com/2012/07/rc4-tutorial/
http://blog.dcxn.com/2010/09/14/26/
Monday, July 8, 2013
Friday, June 28, 2013
Thursday, June 27, 2013
Useful Regular Expressions
Credit Card
^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$
^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$
American Express
|
378282246310005
|
American Express
|
371449635398431
|
American Express Corporate
|
|
Australian BankCard
|
5610591081018250
|
Diners Club
|
30569309025904
|
Diners Club
|
38520000023237
|
Discover
|
6011111111111117
|
Discover
|
6011000990139424
|
JCB
|
3530111333300000
|
JCB
|
3566002020360505
|
MasterCard
|
5555555555554444
|
MasterCard
|
5105105105105100
|
Visa
|
4111111111111111
|
Visa
|
4012888888881881
|
Visa
|
4222222222222
|
Processor-specific Cards
|
|
Dankort (PBS)
|
76009244561
|
Dankort (PBS)
|
5019717010103742
|
Switch/Solo (Paymentech)
|
6331101999990016
|
Wednesday, June 26, 2013
TCP Header Format
TCP Header Format
TCP segments are sent as internet datagrams. The Internet Protocol header carries several information fields, including the source and destination host addresses [2]. A TCP header follows the internet header, supplying information specific to the TCP protocol. This division allows for the existence of host level protocols other than TCP.
TCP Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
Note that one tick mark represents one bit position.
Figure 3.
Source Port: 16 bits
The source port number.Destination Port: 16 bits
The destination port number.Sequence Number: 32 bits
The sequence number of the first data octet in this segment (except
when SYN is present). If SYN is present the sequence number is the
initial sequence number (ISN) and the first data octet is ISN+1.
Acknowledgment Number: 32 bits
If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent.
Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates where
the data begins. The TCP header (even one including options) is an
integral number of 32 bits long.
Reserved: 6 bits
Reserved for future use. Must be zero.Control Bits: 6 bits (from left to right):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Window: 16 bits
The number of data octets beginning with the one indicated in the
acknowledgment field which the sender of this segment is willing to
accept.
Checksum: 16 bits
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text. If a
segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes. The pad is not
transmitted as part of the segment. While computing the checksum,
the checksum field itself is replaced with zeros.
The checksum also covers a 96 bit pseudo header conceptually
prefixed to the TCP header. This pseudo header contains the Source
Address, the Destination Address, the Protocol, and TCP length.
This gives the TCP protection against misrouted segments. This
information is carried in the Internet Protocol and is transferred
across the TCP/Network interface in the arguments or results of
calls by the TCP on the IP.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
The TCP Length is the TCP header length plus the data length in
octets (this is not an explicitly transmitted quantity, but is
computed), and it does not count the 12 octets of the pseudo
header.
Urgent Pointer: 16 bits
This field communicates the current value of the urgent pointer as a
positive offset from the sequence number in this segment. The
urgent pointer points to the sequence number of the octet following
the urgent data. This field is only be interpreted in segments with
the URG control bit set.
Options: variable
Options may occupy space at the end of the TCP header and are a
multiple of 8 bits in length. All options are included in the
checksum. An option may begin on any octet boundary. There are two
cases for the format of an option:
Case 1: A single octet of option-kind.
Case 2: An octet of option-kind, an octet of option-length, and
the actual option-data octets.
The option-length counts the two octets of option-kind and
option-length as well as the option-data octets.
Note that the list of options may be shorter than the data offset
field might imply. The content of the header beyond the
End-of-Option option must be header padding (i.e., zero).
A TCP must implement all options.
Currently defined options include (kind indicated in octal):
Kind Length Meaning
---- ------ -------
0 - End of option list.
1 - No-Operation.
2 4 Maximum Segment Size.
Specific Option Definitions
End of Option List
+--------+
|00000000|
+--------+
Kind=0
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to
the Data Offset field. This is used at the end of all options,
not the end of each option, and need only be used if the end of
the options would not otherwise coincide with the end of the TCP
header.
No-Operation
+--------+
|00000001|
+--------+
Kind=1
This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary.
There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do
not begin on a word boundary.
Maximum Segment Size
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
Padding: variable
The TCP header padding is used to ensure that the TCP header ends
and data begins on a 32 bit boundary. The padding is composed of
zeros.
Subscribe to:
Comments (Atom)






