Send a stream of packets, unacknowledged, which you hope will mostly be delivered.The application doesn't maintain any state - it just answers your question and waits for the next one. Do a simple one-packet response to a one-packet query - DNS usually works this way, and all the protocols like Echo and Daytime that got turned off due to packet-amplification attacks like smurfing work that way.Most UDP applications do one of three things
The Applications may or may not create Layer 7 connections or maintain state. By contrast, TCP creates a connection between the two endpoints, using the 3-way-handshake mechanism, window size management, acknowledgements, retransmit mechanisms, etc., and the connection has state (SYN sent, SYN-ACK received, N bytes still waiting to go into a window, FIN received, etc.) UDP is a Layer 4 protocol for transmitting packets between (Layer 5,6,or 7) applications - it doesn't have any concept of connection, state, or acknowledgements, either in the packet headers or in the protocol for what to do with those packets. If you allow UDP out, and UDP:Established in, then how can you complain that you end up accepting a bunch of UDP packets? My original point was that it wasn't an exploit at all, in the sense that you are not able to break any existing rule using this method. It also won't allow the destination port to be changed without a second "NEW" packet originating from the new destination port. So unless you just allow all UDP through the firewall, the state table keeps track of how often the destination ip responds, and if it doesn't respond within the timeout set in ip_conntrack_proto_udp.c at compile time, the system will terminate that connection, and require a "new" connection to be set up between those addresses. The state table entry for a UDP packet, however, contains the source IP:port and the destination IP:port, and uses that information to "track" the exchange. Well, no, I suppose if you sent every packet from a UDP session to a different port, there would be no way of telling that they're all part of the same session, because you're right, UDP doesn't contain any tracking info.
0 kommentar(er)
