Curb your paranoia. [
]
What you are seeing there is no port scan, but a mistake that many state based firewalls make quite easily.
Remember, UDP is not a stateful protocol, in other words, the concept that a connection is new, established or closed does not exist in UDP. Instead, UDP is, as the name implies, a user level datagram protocol. This means, any user level application can send a "datagram" inside of a UDP packet to any host and any port. No previous connection state has to exist for an application to be allowed to send a UDP packet.
The protocol is defined as such because UDP transmissions generally consisted of single packets, or broadcasts to which no reply was needed, when the protocol was first specified.
In the mean time, DNS has been created and was designed to operate over UDP exactly for that reason. Had all DNS queries been transferred over TCP, a connection would need to be opened, monitored and closed for each and every DNS query. That would put tremendous stress on the TCP stack on any large DNS server.
The drawback to the UDP approach is that in effect, UDP is being used for something which should be stateful. Furthermore, some firewalls attempt to treat UDP as stateful, even though it is not.
For instance, a state based firewall might see a UDP packet leaving for port 53 of a DNS server and record this. It will then predict that the DNS server is very likely to respond within a certain amount of time with a UDP packet from port 53 to the same port which sent the packet locally.
If the DNS server is bogged down by heavy traffic, has trouble resolving the host name, or a delay occurs at the side of the DNS server or somewhere on the network, for which ever reason, causing the datagram carrying the response to arrive late, the firewall will have elapsed its timeout for the response packet and will have "forgotten" about the "open" UDP connection.
It will then consider the returning packet as a rogue packet attempting to create an illicit connection or a port scan and react incorrectly by acting upon such a packet as if it were an attack.
This is highly likely the problem, as 196.25.1.1 is SAIX's primary DNS server. It is always operating under heavy stress and as such can not respond to DNS queries as quickly as it should. If the delays become excessive, your firewall might easily have forgotten about the UDP packet that was sent though it and will consider the incoming response packet a connection or scan attempt.
Remember, since there are no states in UDP, there is no state information in a UDP packet, thus, the firewall has no way of knowing that the packet is a response and not a connection attempt. In fact, any UDP packet can be absolutely anything.
In TCP, the order of packets is very clearly defined. When connecting to a server, a client will send a packet with the SYN bit set, meaning "synchronize," to which the server will respond with one of two packets.
If the client may establish a connection, the server responds with a packet which has the SYN and ACK bits set, ACK being "acknowledged." If the client may not establish a connection, for example, there is no program listening on the port the client tried to reach, the server will respond with a packet having the RST bit set, meaning "reset."
The client and server then communicate by exchanging datagrams in packets and each side responding to each datagram with an ACK packet, also containing the sequence number of the packet for which the ACK has been generated. In this way, TCP stacks can monitor the state of a connection and even compensate for packet loss by retransmitting packets for which no ACK has been returned.
Incidentally, this is how bandwidth shaping systems work. The bandwidth shaping equipment will monitor the traffic being sent across the link and as soon as the allowed bandwidth has been exceeded, will start simply dropping TCP packets and ACKs, thus, the client and server will realise that they are overstressing the link and attempt to retransmit packets at a lower frequency, lowering the transmission speed.
The bandwidth limiting equipment will gradually decrease the artificial packet loss until the transmitting speed drops to within the allowed parameters. That's why downloads on ADSL lines will some time start out at 200KB/s or more, that maximum capacity of the line, only to drop to 50KB/s or less after about two seconds.
This is not a bug in TCP, in fact, this behaveour is required of any TCP stack, to allow TCP connections to retain a steady packet flow over slow connections, instead of the unstable, high-loss stream you would get with UDP over the same connection.
Bandwidth shaping systems merely exploit this behaveour to make a TCP stack believe that it is transmitting over a slow line, even though it isn't.
As the packet loss and stress compensation is also a part of the stateful aspect of TCP, this further offers an explanation as to why high volume UDP transmissions will often be unreliable or even impossible over slow or bandwidth limited lines.
Since the transmitting side does not wait for an ACK before transmitting the next packet, UDP transmissions will continue at the maximum possible speed that the transmitting side can handle.
Bandwidth shaping technology simply drops all UDP packets that exceed the limit, so unless a way to compensate has been built in to the UDP based application, severe packet loss will always occur on UDP connections that have to traverse slower lines or bandwidth limiting equipment.
Getting back to the topic of TCP, after the TCP connection has served its perpose, the client or the server will send a packet with the FIN bit set, meaning "finished." The other end will then respond with a packet with the FIN and ACK bits set, obviously meaning "finished, acknowledged." At this point, the connection is considered closed by both sides.
In many cases, this is not the perfect approach for heavy load servers that have to send many responses in short bursts. Some clients violate TCP RFCs by not responding with FIN ACK when closing a connection. For these clients, the server has to keep a file descriptor open, in case they still wanted to do something else with the connection, or they don't believe it to be closed.
Eventually, after an inactivity timeout of usually 180 seconds, any TCP connection will be considered closed, regardless of the state it is in. This still creates stress on servers though. It can easily be demonstrated by monitoring a UNIX web server with netstat. It will always show many connections in the CLOSE_WAIT state, which means, the server is waiting for a FIN ACK from the client, which never came.
This would be a disaster for DNS server, so to prevent it, UDP was chosen as the transport protocol for DNS queries.
Unfortunately, since UDP has no order defined in which packets must be sent and received, there is really just no way for your firewall to know exactly why a UDP packet is attempting to cross it.
Stateful firewalls use heuristic algorithms which predict packet flow by calculating the mathematical probability that a packet should arrive at a given point in time. In other words, they "guess" the perpose of a UDP packet, but that is about as much as they can do. If they guess the wrong perpose for the packet, they will react incorrectly, as is happening in this case.
Basically, your client PC is requesting DNS resolution from SAIX's server and the server is innocently sending a response. However, due to network congestion, heavy stress on the server, or what ever has caused the particular slowdown in this case, the firewall does not perceive the returning response packet to be a response, but an attack.
Willie Viljoen
Web Developer
Adaptive Web Development
