[tarballed]

Hello everyone. Well, I started thinking about a few things once I saw bsdjunkie post some IDS logs. I figured, I mine as well post some of my firewall logs to get some feedback and see what may be going on with my firewall. :)

First, some background. The firewall will be from my work. The firewall is called a WatchGuard and to the best of my knowledge, it is running off of a Linux Kernel. (Believe me, I am trying to convince them to let me put up a OpenBSD firewall with a few added extras...suits like to do their own thing. :) )
Here is a recent entry that caught my attention:

03/18/03 12:19 deny in eth0 1500 udp 20 113 24.130.29.27 209.xxx.xxx.xxx 44661 2591 (default)

Explanation, from left to right:

Disposition - deny
Direction - in,
Interface - eth0
Total Packet length - 1500
Protocol - UDP
IP Header length - 20
TTL - 113
Source Address - 24.130.29.27
Destination Address - 209.xxx.xxx.xxx
Source Port - 44661
Destination port - 2591
Description - (default)

The one thing that stands out in my mind is the total sice of the packet. Seems quite bit and it being UDP.

Post logs I see, the total packet is 60.

Anyone wanna take a gander on what this bloke may be doing?

Tarballed

[bsdjunkie]

Well, port 2591 is reserved for the following:

maytagshuffle 2591/tcp Maytag Shuffle
maytagshuffle 2591/udp Maytag Shuffle
# Maytag Corporation <hbuck@maytag.com>

I doubt your attacker was looking to exploit that service in particular. After a quick search there are not any "well known" trojans that use that port. It is possible someone has changed the default listening ports on some other trojan and is scanning for it running on port 2591.

As far as the size being 1500, thats the MTU on ethernet. That should leave about 1472 bytes for data. If it will be larger than this, then the fragmanet bit must be set. If its to big and set to not fragment, it wil generate a error of "fragmentation needed, but dont fragment bit set"
The actual max size for UDP packets is 65507 bytes. 65535 - 20byte ip - 8 byte UDP header = 65507.


20 bytes is correct for a normal IP header attached to the UDP header.



It looks like your "attacker" is an ATT cable modem user.

24.130.29.27 (IP Address)

OrgName: AT&T Broadband West
OrgID: ATBW
Address: 27 Industrial Ave
City: Chelmsford
StateProv: MA
PostalCode: 01824
Country: US

NetRange: 24.130.0.0 - 24.130.127.255
CIDR: 24.130.0.0/17
NetName: ATTB-WEST-2
NetHandle: NET-24-130-0-0-1
Parent: NET-24-0-0-0-0
NetType: Direct Allocation
NameServer: NS4.ATTBB.NET
NameServer: NS5.ATTBB.NET
NameServer: NS6.ATTBB.NET
Comment: For abuse contact abuse@attbi.com
RegDate:
Updated: 2001-11-16

TechHandle: ZM117-ARIN
TechName: ATT Broadband
TechPhone: +1-978-244-4020
TechEmail: ipadmin@attbb.net

OrgTechHandle: ZM117-ARIN
OrgTechName: ATT Broadband
OrgTechPhone: +1-978-244-4020
OrgTechEmail: ipadmin@attbb.net

[tarballed]

hey bsdjunkie,

Thanks for the reply. After I had reviewed the log, I did the same thing you did. Find out what port he is going do and where this guy is from.

I really scratched my head when I saw port 2591 maytagshuffle port. I thought it was a little comical. :)

Any idea on what this may be, or is it just some random scan/probe/yada yada type thing?

I did notice that this guy did have 7 more packets blocked by our firewall. They were all coming from and going to the same port. The Total packet length was different though.

I'm curious as to what is going on. At the same time, it is a education as well. :)

Tarballed

[bsdjunkie]

I dont think i could give any more information without actually seeing a dump of the packets in question.

[tarballed]

That is the problem with this particular firewall. I cannot get into the nitty gritty part of the logs to pick out information. What I posted is the most I can get.

Of course, it does have a nice little tool to generate pretty logs. :)

hehe


tarballed

[elmore]

Hey I moved this thread.

[bsdjunkie]

tarballed: if it does run on a linux box, maybe you can convince the powers that be to allow you to install Snort on it as well. That will capture all the data that really means something and would help. I have the same trouble with the Cisco IDS we use. It only grabs the portion of packet that sets off the signature. I have no other packets to view in what context its coming in...

[elmore]

I don't know why I moved this into the OBSD section, I guess I wasn't paying too much attention. I'm guessing this should go into other software but, I'm not going to move it again. :oops: