Pages

Thursday, July 24, 2014

Understanding TCPDUMP Output



These examples in this post bases on Checkpoint Firewalls. In other platform, the output and

command options may have a difference.

Basic TCPDUMP Commands:


  • tcpdump port 257   , <– on the firewall, this will allow you to see if the logs are passing from the firewall to the manager, and what address they are heading to.
  • tcpdump -i WAN.15  <- data-blogger-escaped-capture="" data-blogger-escaped-everything="" data-blogger-escaped-interface="" data-blogger-escaped-li="" data-blogger-escaped-on="" data-blogger-escaped-this="" data-blogger-escaped-to="">
  • tcpdump -i eth1.16 icmp  <– to capture just PINGs on this interface
  • tcpdump -i  Mgmt -vvv -s0 -w tcpdumpfile.log   <– this captures the FULL packets to a file usefull for wireshark the -s0 stops the files being shortened
  • tcpdump -i INT port 67   <– view dhcp requests
  • tcpdump -eP -nni any host 10.9.4.30 
  • tcpdump -i any  
  • tcpdump -nn


    Flags:
    • S – SYN (Start Connection)
    . – No Flag Set
    P – PSH (Push Data)
    F – FIN (Finish Connection)
    R – RST (Reset Connection)
    “ack” means acknowledge, “win” means “sliding windows”, “mss” means “maximum segment size”, “nop” means “no operation”.
    Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo),
    or a single ’.’ (no flags)
    Selective Acknowledgment Permitted (SackOK): This option simply says that selective acknowledgments are permitted for this connection. SackOK must be included in the TCP options in both the SYN and SYN/ACK packets during the TCP three-way handshake, or it cannot be used. SackOK should not appear in any other packets.
    more explanation can be found from Steven’s post – `Masterclass – Tcpdump – Interpreting Output’

    Three-way Handshake:

    The three-way handshake is simply the source host and the destination host requesting a connection, and then confirming to each other that a connection has been made. As mentioned above, to open a session a client determines a local source port and an Initial Sequence Number (ISN). The ISN is
    a randomly determined integer between 0 and 4,294,967,295. Communicating hosts exchange ISNs during connection initialization. Each host sets two counters: sequence and acknowledgement. In the context of a single TCP packet, the sequence number is set by the sending host, and the acknowledgement number is set by the receiving host.
    Host A sends a TCP SYNchronize packet to Host B
    Host B receives A’s SYN
    Host B sends a SYNchronize-ACKnowledgement
    Host A receives B’s SYN-ACK
    Host A sends ACKnowledge
    Host B receives ACK.
    TCP socket connection is ESTABLISHED.
    tcp three-way handshake,syn,syn-ack,ack
    TCP Three Way Handshake (SYN,SYN-ACK,ACK) – See more at this URL:

    Commands and Outputs Examples:

    1. ICMP Example



    [Expert@ CP1:0]#tcpdump -i Mgmt host 172.16.1.53
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:37:38.370763 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 3, length 40
    09:37:38.372210 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 3, length 40
    09:37:39.365648 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 4, length 40
    09:37:39.366558 IP 172.16.1.53 > 10.94.200.14: ICMP echo reply, id 1, seq 4, length 40
    09:37:40.363506 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 5, length 40
    09:37:40.364318 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 5, length 40
    09:37:41.361947 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 6, length 40
    09:37:41.362771 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 6, length 40

    [Expert@CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:38:29.232691 IP (tos 0x0, ttl 126, id 5783, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 7, length 40
    09:38:29.233395 IP (tos 0x0, ttl 127, id 4146, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 7, length 40
    09:38:30.222653 IP (tos 0x0, ttl 126, id 5788, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 8, length 40
    09:38:30.223565 IP (tos 0x0, ttl 127, id 4147, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 8, length 40
    09:38:31.220764 IP (tos 0x0, ttl 126, id 5791, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 9, length 40
    09:38:31.221607 IP (tos 0x0, ttl 127, id 4149, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 9, length 40
    09:38:32.235355 IP (tos 0x0, ttl 126, id 5795, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 10, length 40
    09:38:32.236151 IP (tos 0x0, ttl 127, id 4152, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 10, length 40



    2. HTTPS Example



    [Expert@Pub-cp2:0]# tcpdump -vvv -nn -i eth1-01 host 19.26.16.19
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    11:39:04.822700 IP (tos 0x0, ttl 126, id 7241, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.19.10747 > 19.26.16.24.443: S, cksum 0xea51 (correct), 2579834556:2579834556(0) win 8192   //SYN
    11:39:04.826136 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.24.443 > 19.26.16.19.10747: S, cksum 0x99db (correct), 487537799:487537799(0) ack 2579834557 win 5840  // SYN ACK
    11:39:04.826153 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.24.443 > 19.26.16.19.10747: S, cksum 0x99db (correct), 487537799:487537799(0) ack 2579834557 win 5840  // This packet is repeated SYN ACK
    11:39:04.826926 IP (tos 0x0, ttl 125, id 7242, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.19.10747 > 10.9.1.25.443: ., cksum 0xd4d0 (correct), 2579834557:2579834557(0) ack 487537800 win 256  //ACK
    11:39:06.883076 IP (tos 0x0, ttl 125, id 7243, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb101 (correct), 0:2(2) ack 1 win 256
    11:39:06.883285 IP (tos 0x0, ttl  63, id 16050, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf14d (correct), 1:1(0) ack 3 win 46
    11:39:07.048713 IP (tos 0x0, ttl 125, id 7244, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0ff (correct), 2:4(2) ack 1 win 256
    11:39:07.048905 IP (tos 0x0, ttl  63, id 16051, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf14b (correct), 1:1(0) ack 5 win 46
    11:39:07.199352 IP (tos 0x0, ttl 125, id 7245, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0fd (correct), 4:6(2) ack 1 win 256
    11:39:07.199883 IP (tos 0x0, ttl  63, id 16052, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf149 (correct), 1:1(0) ack 7 win 46
    11:39:07.342045 IP (tos 0x0, ttl 125, id 7246, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0fb (correct), 6:8(2) ack 1 win 256
    11:39:07.342228 IP (tos 0x0, ttl  63, id 16053, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf147 (correct), 1:1(0) ack 9 win 46
    11:39:07.492210 IP (tos 0x0, ttl 125, id 7247, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0f9 (correct), 8:10(2) ack 1 win 256
    11:39:07.492407 IP (tos 0x0, ttl  63, id 16054, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf145 (correct), 1:1(0) ack 11 win 46
    11:39:07.634867 IP (tos 0x0, ttl 125, id 7248, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0f7 (correct), 10:12(2) ack 1 win 256
    11:39:07.635119 IP (tos 0x0, ttl  63, id 16055, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf143 (correct), 1:1(0) ack 13 win 46
    11:39:07.635269 IP (tos 0x0, ttl  63, id 16056, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: F, cksum 0xf142 (correct), 1:1(0) ack 13 win 46
    11:39:07.635864 IP (tos 0x0, ttl 125, id 7249, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.19.10747 > 10.9.1.25.443: ., cksum 0xbe08 (correct), 12:12(0) ack 2 win 256
    11:39:07.635927 IP (tos 0x0, ttl 125, id 7250, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.19.10747 > 10.9.1.25.443: F, cksum 0xbe07 (correct), 12:12(0) ack 2 win 256
    11:39:07.636058 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf141 (correct), 2:2(0) ack 14 win 46


    3. SSH Example





    [Expert@Pub-CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:46:34.443382 IP (tos 0x0, ttl 126, id 7173, offset 0, flags [DF], proto: TCP (6), length: 52) 10.9.2.14.50831 > 172.16.1.53.22: S, cksum 0xac58 (correct), 3232602545:3232602545(0) win 8192
    09:46:34.444081 IP (tos 0x0, ttl 127, id 6889, offset 0, flags [DF], proto: TCP (6), length: 52) 172.16.1.53.22 > 10.9.2.14.50831: S, cksum 0xb937 (correct), 41283738:41283738(0) ack 3232602546 win 8192
    09:46:34.444916 IP (tos 0x0, ttl 126, id 7175, offset 0, flags [DF], proto: TCP (6), length: 40) 10.9.2.14.50831 > 172.16.1.53.22: ., cksum 0x190b (correct), ack 1 win 256
    09:46:34.452567 IP (tos 0x0, ttl 127, id 6893, offset 0, flags [DF], proto: TCP (6), length: 73) 172.16.1.53.22 > 10.9.2.14.50831: P, cksum 0x1960 (correct), 1:34(33) ack 1 win 256
    09:46:34.647359 IP (tos 0x0, ttl 126, id 7180, offset 0, flags [DF], proto: TCP (6), length: 40) 10.9.2.14.50831 > 172.16.1.53.22: ., cksum 0x18ea (correct), ack 34 win 256
    09:46:35.764373 IP (tos 0x0, ttl 126, id 7184, offset 0, flags [DF], proto: TCP (6), length: 41) 10.9.2.14.50831 > 172.16.1.53.22: P, cksum 0x15e1 (correct), 1:2(1) ack 34 win 256
    09:46:35.764610 IP (tos 0x0, ttl 128, id 9109, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.22 > 10.9.2.14.50831: R, cksum 0x19f6 (correct), 41283772:41283772(0) win 0


    4. FTP Example



    [Expert@Pub-CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:47:11.477696 IP (tos 0x0, ttl 126, id 30923, offset 0, flags [none], proto: TCP (6), length: 44) 10.9.2.14.50864 > 172.16.1.53.21: S, cksum 0xebe1 (correct), 2535345973:2535345973(0) win 32120
    09:47:11.479045 IP (tos 0x0, ttl 127, id 6954, offset 0, flags [DF], proto: TCP (6), length: 44) 172.16.1.53.21 > 10.9.2.14.50864: S, cksum 0x31a2 (correct), 3764401990:3764401990(0) ack 2535345974 win 8192
    09:47:11.480173 IP (tos 0x0, ttl 126, id 30925, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xebe6 (correct), ack 1 win 32120
    09:47:11.480858 IP (tos 0x0, ttl 127, id 6955, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: ., cksum 0x695f (correct), ack 1 win 65535
    09:47:11.690070 IP (tos 0x0, ttl 127, id 6959, offset 0, flags [DF], proto: TCP (6), length: 334) 172.16.1.53.21 > 10.9.2.14.50864: P 1:295(294) ack 1 win 65535
    09:47:11.690579 IP (tos 0x0, ttl 126, id 30926, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xebe6 (correct), ack 295 win 31826
    09:47:13.470582 IP (tos 0x0, ttl 126, id 30933, offset 0, flags [none], proto: TCP (6), length: 46) 10.9.2.14.50864 > 172.16.1.53.21: P, cksum 0x02bf (correct), 1:7(6) ack 295 win 32120
    09:47:13.472164 IP (tos 0x0, ttl 127, id 6963, offset 0, flags [DF], proto: TCP (6), length: 81) 172.16.1.53.21 > 10.9.2.14.50864: P, cksum 0xc94d (correct), 295:336(41) ack 7 win 65529
    09:47:13.472557 IP (tos 0x0, ttl 126, id 30934, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xeaba (correct), ack 336 win 32079
    09:47:13.473093 IP (tos 0x0, ttl 127, id 6965, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: F, cksum 0x680f (correct), 336:336(0) ack 7 win 65529
    09:47:13.473336 IP (tos 0x0, ttl 126, id 30936, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xea90 (correct), ack 337 win 32120
    09:47:13.489842 IP (tos 0x0, ttl 126, id 30939, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: F, cksum 0xea8f (correct), 7:7(0) ack 337 win 32120
    09:47:13.490369 IP (tos 0x0, ttl 127, id 6967, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: ., cksum 0x680e (correct), ack 8 win 65529
    09:47:14.836964 IP (tos 0x0, ttl 126, id 19859, offset 0, flags [DF], proto: TCP (6), length: 112) 10.94.16.48.58884 > 172.16.1.53.445: P 1912308033:1912308105(72) ack 3052976289 win 258
    09:47:14.836979 IP (tos 0x0, ttl 126, id 19860, offset 0, flags [DF], proto: TCP (6), length: 112) 10.94.16.48.58884 > 172.16.1.53.445: P 72:144(72) ack 1 win 258
    09:47:14.837677 IP (tos 0x0, ttl 127, id 6970, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.445 > 10.94.16.48.58884: ., cksum 0x9ad5 (correct), ack 144 win 258
    09:47:14.837693 IP (tos 0x0, ttl 127, id 6971, offset 0, flags [DF], proto: TCP (6), length: 112) 172.16.1.53.445 > 10.94.16.48.58884: P 1:73(72) ack 144 win 258
    09:47:14.837700 IP (tos 0x0, ttl 127, id 6972, offset 0, flags [DF], proto: TCP (6), length: 112) 172.16.1.53.445 > 10.94.16.48.58884: P 73:145(72) ack 144 win 258
    09:47:14.838389 IP (tos 0x0, ttl 126, id 19870, offset 0, flags [DF], proto: TCP (6), length: 40) 10.94.16.48.58884 > 172.16.1.53.445: ., cksum 0x9a46 (correct), ack 145 win 257
    09:47:14.838843 IP (tos 0x0, ttl 126, id 19872, offset 0, flags [DF], proto: TCP (6), length: 40) 10.94.16.48.58884 > 172.16.1.53.445: R, cksum 0x9b43 (correct), 144:144(0) ack 145 win 0



    5. FTPS example



    [Expert@Pub:0]# tcpdump -v -n -i eth1-01 host 12.25.20.4
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    10:59:02.525754 IP (tos 0x0, ttl  39, id 26220, offset 0, flags [none], proto: TCP (6), length: 60) 12.25.20.4.62712 > 19.26.16.5.ftps: S, cksum 0xd8cb (correct), 1970824717:1970824717(0) win 65535
    10:59:02.526420 IP (tos 0x0, ttl 127, id 32480, offset 0, flags [DF], proto: TCP (6), length: 60) 19.26.16.5.ftps > 12.25.20.4.62712: S, cksum 0xdbb7 (correct), 2713847003:2713847003(0) ack 1970824718 win 8192
    10:59:02.570606 IP (tos 0x0, ttl  38, id 26433, offset 0, flags [none], proto: TCP (6), length: 52) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xa43c (correct), ack 2713847004 win 4096
    10:59:02.906868 IP (tos 0x0, ttl  46, id 22227, offset 0, flags [none], proto: TCP (6), length: 98) 12.25.20.4.62712 > 12.17.3.59.ftps: P 0:58(58) ack 1 win 2047
    10:59:02.908200 IP (tos 0x0, ttl 127, id 32486, offset 0, flags [DF], proto: TCP (6), length: 1476) 19.26.16.5.ftps > 12.25.20.4.62712: . 1:1425(1424) ack 59 win 261
    10:59:02.908216 IP (tos 0x0, ttl 127, id 32487, offset 0, flags [DF], proto: TCP (6), length: 245) 19.26.16.5.ftps > 12.25.20.4.62712: P 1425:1618(193) ack 59 win 261
    10:59:02.949626 IP (tos 0x0, ttl  47, id 2661, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xfe5b (correct), ack 1 win 2047
    10:59:02.968018 IP (tos 0x0, ttl  46, id 63635, offset 0, flags [none], proto: TCP (6), length: 366) 12.25.20.4.62712 > 12.17.3.59.ftps: P 58:384(326) ack 1618 win 2047
    10:59:02.972322 IP (tos 0x0, ttl  46, id 41339, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: F, cksum 0xf6c3 (correct), 384:384(0) ack 1618 win 2047
    10:59:02.972387 IP (tos 0x0, ttl  46, id 33795, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xf6c3 (correct), ack 1618 win 2047
    10:59:02.972523 IP (tos 0x0, ttl 127, id 32489, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.5.ftps > 12.25.20.4.62712: ., cksum 0x1e55 (correct), ack 386 win 260
    10:59:02.972737 IP (tos 0x0, ttl 127, id 32490, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.5.ftps > 12.25.20.4.62712: F, cksum 0x1e54 (correct), 1618:1618(0) ack 386 win 260
    10:59:03.015360 IP (tos 0x0, ttl  46, id 24500, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xf6c2 (correct), ack 1619 win 2047



    6. SQL Example 




    [Expert@Pub-CP1:0]# tcpdump -i eth1-02.104 host 172.16.1.2
    10:39:52.671997 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: S 3761967874:3761967874(0) win 8192
    10:39:52.673393 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: S 4159880273:4159880273(0) ack 3761967875 win 8192
    10:39:52.673743 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    10:39:52.673970 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    10:39:52.674791 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 1:44(43) ack 48 win 256
    10:39:52.675230 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 48:151(103) ack 44 win 256
    10:39:52.675570 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 44:661(617) ack 151 win 256
    10:39:52.676104 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 151:357(206) ack 661 win 254
    10:39:52.676980 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 661:728(67) ack 357 win 255
    10:39:52.677889 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 357:714(357) ack 728 win 253
    10:39:52.680064 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 728:1141(413) ack 714 win 254
    10:39:52.681073 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 714:866(152) ack 1141 win 252
    10:39:52.681402 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 1141:1510(369) ack 866 win 253



    A problem SQL session :




    [Expert@Pub-CP1:0]# tcpdump -i eth1-02.104 host 172.16.1.2
    11:03:28.691563 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: S 3948339855:3948339855(0) win 8192
    11:03:28.692264 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 8192
    11:03:28.692795 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:28.693041 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:28.998541 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:29.606984 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:30.808145 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:31.692318 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 8192
    11:03:31.692610 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:32.025035 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:33.226224 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:35.628622 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:37.690075 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 65535
    11:03:37.690422 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:40.449096 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:43.681010 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: F 48:48(0) ack 1 win 256                      //Finish packets
    11:03:49.690374 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: R 909862135:909862135(0) win 0     // Reset Packets




    7. A Problem Telnet Session




    [Expert@Pub:0]# tcpdump -v -n -i eth1-01 host 19.26.16.129
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    11:17:59.759390 IP (tos 0x0, ttl 126, id 360, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x8b11 (correct), 4098502333:4098502333(0) win 8192
    11:18:02.756485 IP (tos 0x0, ttl 126, id 469, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x8b11 (correct), 4098502333:4098502333(0) win 8192
    11:18:08.760662 IP (tos 0x0, ttl 126, id 658, offset 0, flags [DF], proto: TCP (6), length: 48) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x9f20 (correct), 4098502333:4098502333(0) win 8192


    Notes: 19.26.16.24 sent three Sync packets to 19.26.16.129, but received nothing back.

    4098502333:4098502333(0) means the sending TCP stack is setting 4098502333 as the initial synchronization number (ISN), and “0” (no) data is being passed in this packet.

    Generic TCP

    Here’s a line of output related to an SSH session. Note the -v parameter has been used, without it, the IP header information and some of the TCP information is not displayed.
    22:24:18.910372 IP (tos 0×10, ttl 64, id 9792, offset 0, flags [DF], proto TCP (6), length 88)
    78.47.105.76.ssh > 82.132.219.219.55495: Flags [P.], cksum 0xcb29 (correct), seq497880562:497880610, ack 1593322765, win 379, length 48
    So, let’s break down the components (bits and octets related to the IP header);
    • 22:24:18.910372 – the datagram’s timestamp
    • IP (tos 0×10, ttl 64, id 9792, offset 0, flags [DF], proto TCP (6), length 88) – the layer three datagram’s header fields and values;
      • tos 0×10 – the IP TOS value (more correctly in the present context, the DS and ECN fields (8bit, 2nd octet)
      • ttl 64 – the IP TTL value (8bit, 9th octet)
      • id 9792 – mostly used for identifying the parts of a fragmented datagram; incremented by one with every packet sent (16bit, 5th and 6th octets)
      • offset 0 – the fragment offset, used with fragmented packets (13bits of the 7th and 8th octets)
      • flags [DF] – any IP flags set; [DF] for Don’t Fragment and [MR] for More Fragments (3bits of the 7th octet)
      • proto TCP (6) – the higher layer (four) protocol and it’s number (8bits, 10th octet)
      • length 88 – the entire IP packet length, including headers (16bits, 3rd and 4th octets)
    • 78.47.105.76.ssh – the source IP address and port
    • 82.132.219.219.55495 – the destination IP address and port
    • Flags [P.] – any TCP flags; a period ‘.‘ indicates an ACK
    • cksum 0xcb29 (correct) – the packet’s TCP checksum value
    • seq 497880562:497880610 – the TCP packet’s sequence number
    • ack 1593322765 – the TCP packet’s acknowledgement number
    • win 379 – the source host’s TCP window
    • length 48 – the TCP packet length, including headers

    Generic UDP

    It’s odd how often people don’t think they even use UDP but we all do for Voice, Video, DNS, DHCP, NTP, VXLAN and the like.
    Here’s some output related to DNS. Request without -v;
    22:54:40.769351 IP 78.47.105.76.6891 > 213.133.100.100.domain: 28642+ AAAA? vps.allenz.eu. (31)
    Response with -v, as you can see, without it the IP header information and the UDP information is not displayed;
    22:47:08.352707 IP (tos 0×0, ttl 60, id 1457, offset 0, flags [none], proto UDP (17), length 72)
    213.133.99.99.domain > 78.47.105.76.16165: [udp sum ok] 11711 ServFail q: A? 40.1.255.158.bl.tiopan.com. 0/0/0 (44)
    So, let’s break down the components of that last one;
    • 22:47:08.352707 – the datagram’s timestamp
    • IP (tos 0×0, ttl 60, id 1457, offset 0, flags [none], proto UDP (17), length 72) – the layer three datagram’s header fields and values;
      • tos 0×0 – the IP TOS value (more correctly in the present context, the DS and ECN fields (8bit, 2nd octet)
      • ttl 60 – the IP TTL value (8bit, 9th octet)
      • id 1457 – mostly used for identifying the parts of a fragmented datagram; incremented by one with every packet sent (16bit, 5th and 6th octets)
      • offset 0 – the fragment offset, used with fragmented packets (13bits of the 7th and 8th octets)
      • flags [none] – any IP flags set; [DF] for Don’t Fragment and [MR] for More Fragments (3bits of the 7th octet)
      • proto UDP (17) – the higher layer (four) protocol and it’s number (8bits, 10th octet)
      • length 72– the entire IP packet length, including headers (16bits, 3rd and 4th octets)
    • 213.133.99.99.domain – the source IP address and port
    • 78.47.105.76.16165 – the destination IP address and port
    • [udp sum ok] – the datagram’s checksum status
    • Everything else relates to the DNS application response.

    Notes on the proto(col) Field

    You can find a full list of protocol number assignments here. Here’s a few more you might know;
    • ICMP (1)
    • IGMP (2)
    • GRE (47)
    • ESP (50)
    • VINES (83) 
    • EIGRP (88)
    • ETHERIP (97)
    • OSPF (89)
    • VRRP (112)
    • L2TP (115)
    • SCTP (132) 

    Notes on Service Ports

    I’m sure you all know this but anyway, valid port numbers are 0 through to 65535. If you want to live by IANA assignments (and we all should right?);
    • 0 to 1023 are reserved for well known applications
    • 1024 to 49151 are registered (with IANA) ports
    • 49152 to 65535 are user and dynamic ports (aka ephemeral or temporary)

    Protocol Formatting

    tcpdump provides data formatting for the following protocols amongst others (see Jens comments below for more information);
    • ICMP
    • ISAKMP
    • ARP
    • NTP
    • DNS
    • STP
    • HSRP
    • SNMP
    • RADIUS
    Thanks again to Jens for this: If you see ‘[|proto]‘ at the end of the verbose output, e.g. ‘[|radius]‘ the snap length is too small for the application data to be captured;. just increase it (using the -s0 parameter) to see the complete application data information.
    Here’s a few examples;
    ARP: 22:45:47.220050 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 78.47.108.52 tell 78.47.108.49, length 46
    NTP (with -v);
    78.47.105.76.ntp > 213.239.239.166.ntp: NTPv4, length 48
    Client, Leap indicator:  (0), Stratum 3 (secondary reference), poll 10s, precision -22
    Root Delay: 0.020477, Root dispersion: 0.056991, Reference-ID: 83.137.98.96
    …
    DNS: 213.133.99.99.domain > 78.47.105.76.16165: [udp sum ok] 11711 ServFail q: A? 40.1.255.158.bl.tiopan.com. 0/0/0 (44)

    Here are some Tcpdump Scenarios from Making a Connection with tcpdump, Part II

    Scenario 1: Established Telnet Connection

    Using tcpdump we can analyze the PDUs that establish and terminate a TCP/IP connection. TCP uses a special mechanism to open and close connections. The tcpdump output below display data from different connection scenarios between host 192.168.2.10 and 192.168.2.165. The following tcpdump command and options were used to generate output:
    #tcpdump -nn host 192.168.2.165 and port 23
    Before examining the output, let’s take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:
    • The requesting Host sends a synchronization flag (SYN) in a TCP segment to create a connection.
    • The receiving Host 192.168.2.165 receives the SYN flag and returns an acknowledgment flag (ACK).
    • The requesting Host 192.168.2.10 receives the SYN flag and returns it’s own ACK flag.
    A similar handshake process is used to close a connection using a finish flag (FIN).
    To establish a connection, the sending host creates a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number. Data is segmented before it is sent. The sequence numbers allow the segments to be assembled in the correct order.
    20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23:
    S 3263977215:3263977215(0) win 16384  (DF)
    The receiving hosts responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending host’s SYN (segment 3263977215 +1). This type of acknowledgment is called expectational acknowledgment, because the receiver acknowledges the sequence number of the next segment it expects to receive.
    20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: S
    48495364:48495364(0) ack 3263977216 win 32120 
    (DF)
    The sending host acknowledges the SYN flag from the receiving host by sending another segment containing the . and ACK flags.
    20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520
    (DF)
    So far two flags, S and ., have been seen. There are five in total.
    • S: SYN (Synchronize sequence numbers – Connection establishment)
    • F: FIN (Ending of sending by sender – Connection termination)
    • R: RST (Reset connection)
    • P: PSH (Push data)
    • .: (No flag is set)

    Scenario 2: Closed Telnet Connection

    To terminate a connection, a segment containing a FIN flag is sent from host 192.168.2.165 back to the host with the open session.
    20:07:32.916410 192.168.2.165.23 > 192.168.2.10.1249: F 147:147(0) ack
    56 win 32120 (DF)
    This may appear backwards, but trust me, it’s not. Think of where the session is open–this is the point that is asking to close the connection. Host 192.168.2.10 acknowledges the FIN segment.
    20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 win
    17374 (DF)
    Then host 192.168.2.10 terminates it connection by sending a segment containing a FIN flag.
    20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148
    win 17374 (DF)
    Host 192.168.2.165 acknowledges the segment.
    20:07:32.929121 192.168.2.165.23 > 192.168.2.10.1249: . ack 57 win 32120
    (DF)
    Scenario 3: Telnet Connection Refused (no service offered at the host)
    To establish a connection, host 192.168.2.10 sends a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number.
    05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23:
    S 3034008467:3034008467(0) win 16384  (DF)
    Host 192.168.2.165 acknowledges the SYN from host 192.168.2.10 by sending another segment containing the R (connection reset) and ACK flags.
    05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0)
    ack 3034008468 win 0
    Host doesn’t take no for answer and tries again.
    05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S
    3034008467:3034008467(0) win 16384  (DF)
    But it receives the same result from receiving host.
    05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
    0
    A final attempt is made to establish a connection.
    05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S
    3034008467:3034008467(0) win 16384  (DF)
    Only three strikes in this ball game. Sending host gives up.
    05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
    0
    Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal scenario. The outputs from the receiving host are different. For the Telnet Connection Refusal scenario, the Telnet service was turned off at the receiving host using the /etc/inetd.conf file. If the service is not available, no connection can be established. Note to self: simple security measures turn off services not being used.

    Scenario 3: Telnet Connection Refused (tcp wrappers security used at host)

    The same opening as before is used to establish a connection.
    05:40:39.838710 192.168.2.10.1064 > 192.168.2.165.23: S
    3223709294:3223709294(0) win 16384  (DF)
    The receiving host responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending hosts SYN (segment 3223709294 +1).
    05:40:39.839045 192.168.2.165.23 > 192.168.2.10.1064: S
    063202536:2063202536(0) ack 3223709295 win 32120 1460,nop,nop,sackOK> (DF)
    Host 192.168.2.10 acknowledges the SYN from host 192.168.2.165 by sending another segment, which contains the . and ACK flags.
    05:40:39.839295 192.168.2.10.1064 > 192.168.2.165.23: . ack 1 win 17520
    (DF)
    Host 192.168.2.165 responds with a segment containing a FIN flag–connection terminated. Something has told the receiving host no connection is allowed.
    05:40:44.852844 192.168.2.165.23 > 192.168.2.10.1064:
    F 1:1(0) ack 1 win 32120 (DF)
    Host 192.168.2.10 has a no-flag-set second acknowledgment.
    05:40:44.853137 192.168.2.10.1064 > 192.168.2.165.23: . ack 2 win 17520
    (DF)
    Because a FIN flag segment was received, the connection must be terminated. So host 192.168.2.10 sends a FIN flag to terminate the connection.
    05:40:44.855050 192.168.2.10.1064 > 192.168.2.165.23: F 1:1(0) ack 2 win
    17520 (DF)
    Host 192.168.2.165 responds with a segment acknowledgment.
    05:40:44.855176 192.168.2.165.23 > 192.168.2.10.1064: . ack 2 win 32120
    (DF)
    Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal (tcp wrappers) scenario. The outputs from the receiving host are different. In the Telnet Connection Refusal (tcp wrappers) scenario, tcp wrappers is enabled by adding the following line to the /etc/hosts.deny file: ALL:192.168.2.10. This means “deny all services to this host with address 192.168.2.10”. A similar connection test was done using a rule in iptables firewall. The resulting output was the same.
    The reader may gain some insight into how systems are at risk from the trappings of tcpdump. Before a system hack is possible, some effort is expended to engineer the hack. An examination of the data from a system can provide the hacker with some insight into where efforts might provide the greatest chance of success.

    Scenario 4: No Telnet Connection (host removed from the network)

    Same opening, different scenario.
    05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)
    There’s no response, so the sending host tries the same request again.
    05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)
    With still no response on the third try, the three-strike rule comes into effect. The sending host abandons the connection attempt.
    05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)

    Reference:

    Posted by at No comments:
    Labels:

    Sunday, June 22, 2014

    Cisco L2 L3 IOU Rack V5 (newer version from Cisco L2 L3 IOU Rack V3)

    I was using Cisco L2 L3 IOU Rack V3 from flyxj for quite a while. Recently found Cisco L2 L3 IOU Rack V5. Not much difference except more devices in it for more complicated topology.

    1. Vmware 10 workstation Configuration:

    a. Create a custom linux vm with an existing virtual disk in your download file.
     b. Remove other unused hardware such as sounds, printer and usb. Add two more network cards.


    2. After vm created, launch this vm. Here are some screenshots:

    root / rsj.net

    /etc/issue and /etc/motd can be modified for the banner. 

    Cisco L2/L3 I-O-U RackV5
    Cisco L2/L3 I-O-U RackV5

    3. Change eth0 IP address at /etc/network/interfaces

    4. Change Login Banner at /etc/issue and /etc/motd

    5. Change SSH Terminal to make it colorful



    Posted by at 3 comments:
    Labels:

    Cisco VPN LAB 4 : EZ VPN Between ASA 8.4.2, IOS Router and EZVPN Client Software

    Cisco VPN Lab Series:

    Cisco VPN LAB 1 : Simple Easy VPN Example between Routers and Comparison with DMVPN
    Cisco VPN LAB 2 : IPSec VPN Example Between Two ASA 8.4.2
    Cisco VPN LAB 3 : EZ VPN Between ASA 8.4.2, IOS Router and EZVPN Client Software


    1. Topology:


    2. Configurations:

    !=== start from a clean default configuration on ASA===
    configure factory-default 10.1.1.1 255.255.255.0

    2.1 EZ VPN Server configuration

    asa242-1(config)# sh run

    ASA Version 8.4(2)
    !
    hostname asa242-1
    enable password 8Ry2YjIyt7RRXU24 encrypted
    passwd 2KFQnbNIdI.2KYOU encrypted
    names
    !
    interface GigabitEthernet0
     nameif Internet
     security-level 0
     ip address 1.1.1.1 255.255.255.0
    !
    interface GigabitEthernet1
     nameif Internal
     security-level 100
     ip address 10.1.1.1 255.255.255.0
    !
    ftp mode passive

    !Setup a split tunnel access-list in order to define traffic that will be routed over from the client side. This access-list will be pushed out to the client upon establishment of the VPN tunnel.
    access-list EZVPN_SPLIT_TUNNEL standard permit 10.0.0.0 255.0.0.0
    pager lines 24
    mtu Internet 1500
    mtu Internal 1500

    ! for VPN Software Clients to get an ip address
    ip local pool remoteuserspool 10.10.230.5-10.10.230.254 mask 255.255.255.0

    icmp unreachable rate-limit 1 burst-size 1
    no asdm history enable
    arp timeout 14400
    route Internet 22.22.22.0 255.255.255.0 1.1.1.2 1
    timeout xlate 3:00:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
    timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
    timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
    timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
    timeout tcp-proxy-reassembly 0:01:00
    timeout floating-conn 0:00:00
    dynamic-access-policy-record DfltAccessPolicy
    user-identity default-domain LOCAL
    no snmp-server location
    no snmp-server contact
    snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

    !setup your Phase 2 parameters and apply it to the interface.
    crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac 

    !by default xp vpn client will use following ipsec parameters

    crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac  

    crypto dynamic-map OUTDIDE_CRYPTO 65500 set ikev1 transform-set ESP-3DES-SHA

    crypto dynamic-map OUTDIDE_CRYPTO 65535 set ikev1 transform-set ESP-DES-SHA
    crypto map OUTSIDE_MAP 65535 ipsec-isakmp dynamic OUTDIDE_CRYPTO
    crypto map OUTSIDE_MAP interface Internet
     
    !setup the PHASE 1 encryption parameters.
    crypto ikev1 enable Internet
    crypto ikev1 policy 9
     authentication pre-share
     encryption des
     hash sha
     group 2
     lifetime 86400
    !by default xp vpn client will use following ikev1 isakmp parameters
    crypto ikev1 policy 10
     authentication pre-share
     encryption 3des
     hash sha
     group 2
     lifetime 86400

    telnet timeout 5
    ssh timeout 5
    console timeout 0
    threat-detection basic-threat
    threat-detection statistics access-list
    no threat-detection statistics tcp-intercept

    !Next you will need to define a group policy for the client. All these settings will be pushed out to the client upon connectivity to the VPN. Make note of the NEM enable option on the last line, as this will enable the Network Extension mode option. Also, you will need the password-storage enable option to allow the client username to be stored on the device. Otherwise you will be prompted to enter the username and password each time you establish the tunnel. 
    group-policy EZVPN1 internal
    group-policy EZVPN1 attributes
     dns-server value 10.3.128.7 10.1.0.92
     vpn-tunnel-protocol ikev1 ikev2
     password-storage enable
     split-tunnel-policy tunnelspecified
     split-tunnel-network-list value EZVPN_SPLIT_TUNNEL
     default-domain value domain.local
     secure-unit-authentication disable
     user-authentication disable
     nem enable

    !Create a username that you will be using on the client to connect to the server. Like the software VPN, this is the user credentials supplied for additional authentication.
    username cisco password 3USUcOPFUiMCO4Jk encrypted
    username EZVPN_USER password k.2ZLTNcTBoL6bHt encrypted
    !
    !Apply the group policy settings in a tunnel-group. This is where you enter the preshared key for your phase 1 authentication. 
    tunnel-group EZVPN1 type remote-access
    tunnel-group EZVPN1 general-attributes
     default-group-policy EZVPN1
    tunnel-group EZVPN1 ipsec-attributes
     ikev1 pre-shared-key *****
    !
    ! tunnel group remoteusers  will be used for remote xp vpn clients configuration
    tunnel-group remoteusers type remote-access
    tunnel-group remoteusers general-attributes
     address-pool remoteuserspool
    tunnel-group remoteusers ipsec-attributes
     ikev1 pre-shared-key *****
    !
    !
    prompt hostname context
    no call-home reporting anonymous
    call-home    
     profile CiscoTAC-1
      no active
      destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
      destination address email callhome@cisco.com
      destination transport-method http
      subscribe-to-alert-group diagnostic
      subscribe-to-alert-group environment
      subscribe-to-alert-group inventory periodic monthly
      subscribe-to-alert-group configuration periodic monthly
      subscribe-to-alert-group telemetry periodic daily
    crashinfo save disable
    Cryptochecksum:f02ff90081d91a0971999b5ce038c737
    : end
    asa242-1(config)#  


    2.2 EZ VPN Client IOS Router:

    R10#sh run
    Building configuration...

    Current configuration : 1609 bytes
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname R10
    !
    boot-start-marker
    boot-end-marker
    !
    security passwords min-length 1
    !
    no aaa new-model
    clock timezone CET 1
    mmi polling-interval 60
    no mmi auto-configure
    no mmi pvc
    mmi snmp-timeout 180
    ip source-route
    !
    ip cef
    no ipv6 traffic interface-statistics
    no ipv6 cef
    !
    multilink bundle-name authenticated
    !
    username cisco password 0 cisco
    !
    redundancy
    !
    crypto isakmp key cisco123 hostname asa242-1

    !--- Set the parameters to connect to the 
    !--- appropriate Easy VPN group on the Easy VPN server.
    crypto ipsec client ezvpn ez
     connect auto
     group EZVPN1 key cisco123
     mode network-extension
     peer 1.1.1.1
     username cisco password cisco
     xauth userid mode local

    !--- Use the crypto ipsec client ezvpn <name> command on the
    !--- interface that connects to the Easy VPN server
    !--- in order to complete the Easy VPN.
    interface Ethernet0/0
     ip address 1.1.1.3 255.255.255.0
     crypto ipsec client ezvpn ez
    !

    !--- Define the inside interfaces that will access 
    !--- and can be accessed via Easy VPN.
    interface Ethernet0/1
     description inside
     ip address 10.10.10.10 255.255.255.0
     crypto ipsec client ezvpn ez inside
    !
    !
    ip forward-protocol nd
    !
    no ip http server
    no ip http secure-server
    !        
    control-plane
    !
    line con 0
     logging synchronous
    line aux 0
    line vty 0 4
     login
    !
    exception data-corruption buffer truncate
    end

    2.3 XP VPN Client Configuration:


    2.4 Test

    2.4.1 Ping test between hub and Spokes are working fine

    2.4.2 Ping test between spokes failed. Solution is in the Notes 3.3


    3. Notes:

    3.1. The vpnclient command (Easy VPN client) only works on 5505 model; since ASA VM emulates a 5520 or generic F1, that feature isn't available.

    3.2. ESXi vSwitch Configuration. Promiscuous mode was used in my ESXi ASA vm network card to communicate with other VMs.

    3.3. Enable Communication between Remote Sites.

    By default with this configuration, the traffic between spokes are dropped by firewalls, although the traffic between hub and spokes are working well. On ASA, enter following command:

    same-security-traffic permit intra-interface

    This command will make traffic between spokes working.    

     
    Posted by at No comments:
    Labels:

    Wednesday, June 18, 2014

    ASA 9.21 in Vmware Workstation 10

    There is old post "ASA 8.02 in Vmware Workstation " in this blog posted on Dec 2011. Anothe post "How to Make your own ASA 8.42 in VMware".  Here are all related posts in this blog:


    This time I got ASA 9.21 tested.

    There are some ASA 9.21 vmware packages from Internet by google-ing:
    Downloaded one and hooked it up in the Vmware. It uses 2G memory but little CPU power. Bridge to real network is working perfectly as well. CPU must be 64bit and supporting VT.

    My host system info is showing at following screenshot for your information :
    If CPU having problem to support VT-x, you may get a error message just like the one shows on my laptop.

    Virtual Machine Settings:


    Some booting screenshots:








    1. ciscoasa# sh ver

    Cisco Adaptive Security Appliance Software Version 9.2(1)
    Device Manager Version 7.2(1)

    Compiled on Thu 24-Apr-14 12:14 PDT by builders
    System image file is "boot:/asa921-smp-k8.bin"
    Config file at boot was "startup-config"

    ciscoasa up 11 mins 56 secs

    Hardware:   ASAv, 2048 MB RAM, CPU Pentium II 2992 MHz,
    Internal ATA Compact Flash, 256MB
    Slot 1: ATA Compact Flash, 8192MB
    BIOS Flash Firmware Hub @ 0x0, 0KB


     0: Ext: Management0/0       : address is 000c.292e.2a14, irq 10
     1: Ext: GigabitEthernet0/0  : address is 000c.292e.2a1e, irq 5
     2: Ext: GigabitEthernet0/1  : address is 000c.292e.2a28, irq 9
     3: Ext: GigabitEthernet0/2  : address is 000c.292e.2a32, irq 10

    ASAv Platform License State: Unlicensed
    *Install -588553824 vCPU ASAv platform license for full functionality.
    The Running Activation Key is not valid, using default settings:
                 
    Licensed features for this platform:
    Virtual CPUs                      : 0              perpetual
    Maximum Physical Interfaces       : 10             perpetual
    Maximum VLANs                     : 50             perpetual
    Inside Hosts                      : Unlimited      perpetual
    Failover                          : Active/Standby perpetual
    Encryption-DES                    : Enabled        perpetual
    Encryption-3DES-AES               : Enabled        perpetual
    Security Contexts                 : 0              perpetual
    GTP/GPRS                          : Disabled       perpetual
    AnyConnect Premium Peers          : 2              perpetual
    AnyConnect Essentials             : Disabled       perpetual
    Other VPN Peers                   : 250            perpetual
    Total VPN Peers                   : 250            perpetual
    Shared License                    : Disabled       perpetual
    AnyConnect for Mobile             : Disabled       perpetual
    AnyConnect for Cisco VPN Phone    : Disabled       perpetual
    Advanced Endpoint Assessment      : Disabled       perpetual
    UC Phone Proxy Sessions           : 2              perpetual
    Total UC Proxy Sessions           : 2              perpetual
    Botnet Traffic Filter             : Enabled        perpetual
    Intercompany Media Engine         : Disabled       perpetual
    Cluster                           : Disabled       perpetual

    This platform has an ASAv VPN Premium license.

    Serial Number: 9AGRB5FHKDK
    Running Permanent Activation Key: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

    Image type          : Release
    Key version         : A

    Configuration last modified by enable_15 at 04:28:04.639 UTC Thu Jun 19 2014
    ciscoasa#

    2. ciscoasa# sh run

    : Saved
    :
    : Serial Number: 9AGRB5FHKDK
    : Hardware:   ASAv, 2048 MB RAM, CPU Pentium II 2992 MHz
    :
    ASA Version 9.2(1)
    !
    hostname ciscoasa
    enable password 8Ry2YjIyt7RRXU24 encrypted
    xlate per-session deny tcp any4 any4
    xlate per-session deny tcp any4 any6
    xlate per-session deny tcp any6 any4
    xlate per-session deny tcp any6 any6
    xlate per-session deny udp any4 any4 eq domain
    xlate per-session deny udp any4 any6 eq domain
    xlate per-session deny udp any6 any4 eq domain
    xlate per-session deny udp any6 any6 eq domain
    names
    !
    interface GigabitEthernet0/0
     nameif EXT
     security-level 0
     ip address 10.94.200.33 255.255.255.128
    !
    interface GigabitEthernet0/1
     shutdown
     no nameif
     no security-level
     no ip address
    !
    interface GigabitEthernet0/2
     shutdown
     no nameif
     no security-level
     no ip address
    !
    interface Management0/0
     management-only
     shutdown
     no nameif
     no security-level
     no ip address
    !
    ftp mode passive
    pager lines 23
    logging buffered debugging
    mtu EXT 1500
    no failover  
    icmp unreachable rate-limit 1 burst-size 1
    no asdm history enable
    arp timeout 14400
    no arp permit-nonconnected
    timeout xlate 3:00:00
    timeout pat-xlate 0:00:30
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
    timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
    timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
    timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
    timeout tcp-proxy-reassembly 0:01:00
    timeout floating-conn 0:00:00
    dynamic-access-policy-record DfltAccessPolicy
    user-identity default-domain LOCAL
    aaa authentication ssh console LOCAL
    no snmp-server location
    no snmp-server contact
    crypto ipsec security-association pmtu-aging infinite
    crypto ca trustpool policy
    telnet timeout 5
    ssh stricthostkeycheck
    ssh 10.94.200.0 255.255.255.0 EXT
    ssh timeout 5
    ssh key-exchange group dh-group1-sha1
    console timeout 0
    threat-detection basic-threat
    threat-detection statistics access-list
    no threat-detection statistics tcp-intercept
    username test password P4ttSyrm33SV8TYp encrypted privilege 15
    !
    class-map inspection_default
     match default-inspection-traffic
    !
    !
    policy-map type inspect dns preset_dns_map
     parameters
      message-length maximum client auto
      message-length maximum 512
    policy-map global_policy
     class inspection_default
      inspect dns preset_dns_map
      inspect ftp
      inspect h323 h225
      inspect h323 ras
      inspect rsh
      inspect rtsp
      inspect esmtp
      inspect sqlnet
      inspect skinny 
      inspect sunrpc
      inspect xdmcp
      inspect sip 
      inspect netbios
      inspect tftp
      inspect ip-options
    !
    service-policy global_policy global
    prompt hostname context
    call-home reporting anonymous prompt 2
    call-home
     profile CiscoTAC-1
      no active
      destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
      destination address email callhome@cisco.com
      destination transport-method http
      subscribe-to-alert-group diagnostic
      subscribe-to-alert-group environment
      subscribe-to-alert-group inventory periodic monthly 27
      subscribe-to-alert-group configuration periodic monthly 27
      subscribe-to-alert-group telemetry periodic daily
    Cryptochecksum:903b71e022141e178ba0c0e00a9e3758
    : end


    Verified bridging to host network works by ping from ASA  to host network:

    3. License

    With "cisco ASA keygen"'s help , you could get all license such as following screenshot shows:



    Now you can have fun with ASA 9.21 in your own virtual rack.
    Posted by at 10 comments:
    Labels: ,

    Tuesday, June 17, 2014

    Forward Logs from Checkpoint SmartCenter Management Server and Juniper NSM / IDP to Syslog Server


    Two KBs regarding how to collect log from Checkpoint and Juniper:

    1. Configuring SmartCenter to send logs to syslog server

    Solution ID: sk33423

    Proceed as follows:

    a. On the SmartCenter server edit the /etc/syslog.conf file and add the following line:

    local4.info <TAB> @IP_OF_REMOTE_BOX

    b. Add the following line to the end bottom of /etc/rc.d/init.d/cpboot file, to be executed on boot up:

    fw log -ftnl 2> /dev/null | awk 'NF' | logger -p local4.info -t Firewall &

    Notes:

    The '&' in the command syntax ensures that this command runs in the background. If the '&' is not included in the command, the OS stops at loading the syslogd service and you never get a login prompt at the console.
    For more information about the fw log command, refer to the R75 Command Line Interface (CLI) Reference Guide.

    c. Reboot.
    Note: cpstop/cpstart is insufficient to make this work.

    2.NSM can forward NSM logs as well as device traffic logs via syslog, SNMP, e-mail or even a custom script.


    You need to define this in "Action Manager" from the NSM GUI client.

    Check this KB article:
    http://kb.juniper.net/KB11810

    NSM Administration Guide the chapter "Forwarding Logs":
    http://www.juniper.net/techpubs/software/management/security-manager/


    Forward logs from NSM to a Syslog server


    1. Login to NSM GUI

    2. Go to "Action Manager" and click  "Action Parameters"

    3. Fill in the Syslog server IP address and the Syslog facility that NSM will categorize the logs as.

    4. Click "OK"

    This informs NSM that an external Syslog server is available for use.  Two mode are available to forward logs to Syslog.

    Device Log Action Criteria Mode:   Located under the "action manager", this mode allows defining a global logging criteria for all devices in a domain.
    The criteria can be based on category, sub-category and severity and will apply to all logs received.

    Policy Manager Mode:  Allows finer control on which traffic log will be forwarded to Syslog by adding the "Log action" to the desired rule options.   This allows forwarding of traffic logs to Syslog only for the desired rules.    Enable "Syslog" under "Log/Count" rule options for each rule.


    3. IDP Appliance 

    To configure Juniper IDP Appliance to send syslogs to STRM (IP Adress of STRM is assumed to be 172.19.47.201)

    Login to the NSM system that is managing the IDP
    1. Edit the IDP device and go to Report Settings
    2. Configure the Syslog server as shown below and update the device 

      IDP Syslog

    Posted by at No comments:
    Labels:
    Subscribe to: Posts (Atom)