Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security ISSForum
[Top] [All Lists]

[ISSForum] DNS Session traffic - UDP 53

Subject: [ISSForum] DNS Session traffic - UDP 53
Date: Thu, 3 Nov 2005 11:47:42 -0500
Has anyone had this problem or have a suggestion? I have already tried
to get an answer from ISS but they don't know that it is:

I have a Firecell (Server Sensor) rule which allows "ANY" to connect to
UDP 53 on my DNS Servers. (UDP 53 is the official DNS port) It appears
that all DNS traffic is working properly both in and out. My last
Firecell rule is a "catch all" rule ISS suggested I have. This catch-all
is the same method one would use when configuring a router. It basically
says that if a packet has not fit the qualification of any prior rule
then at this point it should be dropped. The Firecell rule says "If not
in range of listed subnet then drop the packet and generate response".
The subnet I have listed is our internal subnet (10.x.x.x). So, to
summarize, a packet comes in and if it does not meet the description of
any rule then it gets dropped and logged by the last Firecell rule. 

My problem is that I get between 100-10,000 events per day referencing
this "catch-all" UDP rule. They all look like this (I added commas to
make it easier to read. If you copy/paste the below data into a .csv
file and open with Excel it will look clean and easy to read):

Tag Name,Source IP,Target IP,Object Name,Source Port,IANAProtocolID
Unauth. UDP,69.25.34.195,10.0.0.111,1076,53,17
Unauth. UDP,38.8.48.2,10.0.0.111,1076,53,17
Unauth. UDP,192.134.0.49,10.0.0.111,1076,53,17
Unauth. UDP,222.88.88.88,10.0.0.111,1076,53,17
Unauth. UDP,69.25.34.195,10.0.0.111,1076,53,17
Unauth. UDP,68.142.226.82,10.0.0.111,1076,53,17
Unauth. UDP,128.8.10.90,10.0.0.111,1076,53,17
Unauth. UDP,205.188.157.232,10.0.0.111,1076,53,17
Unauth. UDP,207.132.116.60,10.0.0.111,1076,53,17

In these examples it is UDP 1076 but that is not always the port
recorded. The strange thing is that these events claim that the source
was UDP 53 coming from the outside. The internal port (which I didn't
think mattered) was UDP 1076. I have a specific Firecell rule which
allows all subnets to talk to my server on UDP 53. My DNS servers work
fine so I know the necessary data is being passed properly. I have had a
few other random (and isolated) situations like this with other ports in
the past. 

ISS (when I called) said this was "return session" traffic and to add
the following parameter to the Server Sensor:
AllowAllAcknowledgementPackets = true

I added that and it made no difference. In the meantime I have created
Firecell rules for each arbitrary "DNS return session" port. Since these
port numbers are dynamic (I think) it is hard to create rules for each
one! It does seem, however, that it is the same UDP port numbers
though...over and over. Ports I see often are: 4610, 1088, 1028, 1027,
and 1076.

Anyone have any thoughts? Did I explain this okay? Does anyone else have
the same issue? I have noticed this happening with HTTP from time to
time ( TCP 80). 

Thanks.



David


_______________________________________________
ISSForum mailing list
ISSForum@iss.net

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to mod-issforum@iss.net

The ISSForum mailing list is hosted and managed by Internet Security Systems, 
6303 Barfield Road, Atlanta, Georgia, USA 30328.

<Prev in Thread] Current Thread [Next in Thread>
  • [ISSForum] DNS Session traffic - UDP 53, CAUSEY, David <=