Firewall detection technology based on error CRC
Creation Time: 2002-12-31 Article Properties: Translation Article Source: China Safety Network Article Submit: TOO2Y (TOO2Y_AT_SAFECHINA.NET)
== phrack inc. ==
Volume 0x0b, Issue 0x3c, PHILE # 0x0c of 0x10
| = ---- = [FireWall Spotting and NetWorks AnaliSys with a broken crc] = ---- = || = ----------------------- ------------------------------------------------ = | | = ----------------------------- = [ED3F] = -------------- ------------------ = || = -------------- = [Translation: TOO2Y
--[ table of Contents
0 - study
1 - Some obstacles
2 - technical analysis
3 - You know you are right
4 - Reference
- [0 - Learning the configuration of the firing firewall is more and more people feel the "firewall" and the unprotected sense of unprotective technicians. We can see that they are working at Level 3 in operating systems for commercial software, embedded devices, or open source. However, support for Level 4 is not complete: they filter specific port numbers, TCP tags, SEQ serial numbers, fragments, but ...
What is the checksum of the 4th level?
Do they account for TCP checks before analyzing tag or port numbers? Do not!
Many developers may think that this is much more, others believe that these data reports are simple to discard by the stack of purpose operating systems. It is indeed right, but how can we use this "character" well?
1) Firewall Return Probe Data 2) Destroying 31337 Port Pseudo Pseudo Psychocomy 3) Inserting Damaged Data Reports in the Network
- [1 - Some obstacles
A complete network stack will discard the damaged datagram and will not return any information. Regardless of the target port is closed, open or anything ... but the bag filter firewall is not so smart, they will answer this.
If we want to determine if there is a packet filtering device between us and the target host, we must determine that this packet filter is configured to discard the damaged datagram or return an error. Here we send a valid TCP datagna to a target port that should be filtered to:
# Telnet www.oracle.com 31337Trying 148.87.9.44 ... Telnet: Unable to connect to Remote Host: Connection Refused
Ok. The target host or another package filter device returns an RST. The next step is to determine that the RST datagon is from the target host or packet filtering device:
# HPING -S -C 1 -P 31337 -b www.racle.com (rl0 148.87.9.44): s set, 40 headers 0 data byteslen = 46 ip = 148.87.9.44 flags = ra seq = 0 TTL = 23 ID = 52897 WIN = 512 rtt = 459.8 ms
If we get a response message, we know that there is a package filter device. If we don't get a response message, then the datagnet that guess to send is not filtered out before reaching the target host, but is discarded by the TCP stack. Another technique of detecting package filtration devices is to compare RST datagrams and SYN datasets (TTLs directly from target hosts). However, TTL techniques are fails when all packet filtration devices in the bridging network, or filtering devices do not have a TTL value but directly in front of the target host. The previously described CRC technology can detect the presence of packet filtering devices in both cases.
Another example, we use UDP datagram:
# hping -2 -c 1 -p 53 -b www.redhat.com (RL0 66.187.232.56): UDP Mode Set, 28 Headers 0 Dataicmp Packet Filtered from IP = 63.146.1.74 name = unknown
There is a difference between the datagram is a method from a target host or a filter, we can use the operating system fingerprint detection tool to send firewall datagram, no matter the target host or firewall response. Try NMAP -O.
Interested? I added two new scanning technology to NMAP-3.1alpha4: -sz Badtcp SYN Secret Port Scan -SV Badudp Port Scan
Note the -sz option is derived from the wrong -ss option, while the -SV comes from -su. BADTCP scan uses the FIN scan engine because the host's default behavior does not respond to this. Badudp scanning uses the UDP scan engine because the host's default behavior will not respond.
I hope that Fyodor can promise the full definition of the current state of the target port in the future NMAP version 4.00 version:
- Close - Open - The port is filtered out (no answer) - there is a firewall (a firewall to answer) So how to deal with this new scanning method? It still believes that these are valid datagrams, so it does not change the configuration options to accommodate an effective or invalid SYN datagram.
- [2 - technical analysis
Ok, whatever the package filter device in the system of OpenBSD 3.2 will calculate the checksum for each datam. No, in order to avoid answering probes they only need to verify the checksum of the datagram that needs to make a response. However, a datagram discovered and discarding it should be introduced.
Some tools provide you with a function of modifying datagram as a pseudo-datagram, like ettercat, and allowing your computer to send datagrams to the real destination host.
How can we find Banner deception?
# echo "ssh-1.99"> / tmp / banner # HPING -S -C 1 -P 22-E / TMP / BANNER -D 9 -B MyBox
If you receive a SYN ACK datagram, you can start sweat ...
We can find this technique based on this pseudo-attack technology has been developed. For example, DSNIFF accounts TCP checks, because it is working in the delegate mode, but ettercap is useless non-delegate mode, so it does not need to account for checksum.
Is it necessary to account for the verification and? No, this only needs to do this only if you want to modify the dataginary or to the received datagram. So if your program is just a simple sniffing datagram, without sending or modifying them, you will be safe.
Ok, if you want to respond to security or modify the datagram, is there any solution? There are two ways here:
1) Accounting the checksum of each datagram, only if the process is processed; modify or responds, using valid checksum. 2) Use the added update network checksum [RFC1411] for the datagram to be modified. Note that the added update technique will remain in the verification, before it is still wrong, before it is still right, it is faster than the erase.
Curious: It is invalid during the datagram transfer process. Because it is based on the ultimate destination host IP address (when arriving at the destination, the verification is correct).
Most Intrusion Detection Systems (IDs) will modify the wrong checks, but they do not record these datagrams, so the administrator cannot check these data parts.
Another problem will occur in the following cases, if the network address translation system or loading of the balancing system is based on the erase checksum. At this time, if the intrusion detection system is between our hosts and this "silent" system, then it can pass its detection.
Check an interesting example:
Www.roacle.com:80 Evil - [BadSyn] -> Router - [BadSyn] -> Load_balancer - [SYN] -> Web Server | | NIDS1 NIDS2
NIDS1 will receive a TCP SYN invalidate checksum, if it performs a related configuration, NIDS2 will receive a modified effective SYN datagram. So WebServer will return us to a SYN ACK datagram so that we can communicate with WebServer, but have caused a lot of doubts to NIDS1. What do you think when you are a security administrator, when you find that NIDS1 and NIDS2 records are not the same?
This solution is usually added update technology [RFC1411].
- [3 - You know you are right
awgn (31337 H4X0R) raptor & nobody (LSD project) batmaNAGA & ALORobin (ettercap authors) JWK (OpenBSD addicted) Daniel Hartmeier (Mr.Infinite Patience; OpenBSD PF main coder) antirez (Hping author) Fyodor (Nmap author) Ed3f (15b27bed5e11fc0550d7923176dbaf81 )
- [4 - Reference
[1] hping ---> http://www.hping.org [2] nmap ---> http://www.insecure.org/nmap[3] scanlogd ---> http: // www. OpenWall.com/scanlogd[4] openbsd ---> http://www.openbsd.org [5] openbsd pf ---> http://www.benzedrine.cx/pf.html[6] etcap - -> http://ettercap.sourceforge.net [7] dsniff ---> http://monkey.org/~ DUGSONG/DSniff[8] RFC1141 ---> http://www.ietf.org/rfc /RFC1141.txt
