LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-29-2006, 08:48 PM   #1
humbletech99
Member
 
Registered: Jun 2005
Posts: 374

Rep: Reputation: 30
Snort ICMP PATH MTU denial of service from firewalls


I have a host at site B which is connected via Smoothwall firewalls/vpn to site A, the main office. I am getting a steady stream of the following alerts from snort on the host at site B as shown below
Code:
snort[18420]: [1:3626:1] ICMP PATH MTU denial of service [Classification: Attempted Denial of Service] [Priority: 2]: {ICMP} 192.168.x.x -> 192.168.x.x
which occurs every 5 mins so I decided to use tcpdump to isolate the traffic and have a look at it
Code:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:05:36.180774 IP (tos 0xc0, ttl  64, id 12078, offset 0, flags [none], proto: ICMP (1), length: 576) router.mydomain.com > host_siteB.mydomain.com: ICMP host_siteA.mydomain.com unreachable - need to frag (mtu 1443), length 556
        IP (tos 0x0, ttl  63, id 43507, offset 0, flags [DF], proto: TCP (6), length: 1500) host_siteB.mydomain.com.mit-ml-dev > host_siteA.mydomain.com.60268: . 594521442:594522890(1448) ack 3370043923 win 5792 <nop,nop,timestamp 591791251 632888320>[|icmp]
It looks to me that the alert is genuine, the packet is doing the mtu thingy to reduce throughput which looks like a DoS to snort. Can I fix this to actually work normally without having to write a pass for the rule?

Is something not quite right with my network setup? I have seen this on my workstation when sshing into the firewall at siteA and then sshing to my workstation from there. It seems that the firewalls are sending these packets, but I'm not entirely sure why. Perhaps the links in between are limited to 1443 rather than 1500. Would trying to increase to 1500 help?

Is smoothwall being silly or is it just trying to please the upstream connection by limiting mtu to 1443?

Any recommendations?
 
Old 12-30-2006, 01:55 AM   #2
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
If that other IP is host on your local network, then it looks like a legitimate networking issue. Try adjusting the MTU on the interface to match the smallest one on the connection path. (ifconfig eth0 mtu 1442)

Last edited by Capt_Caveman; 12-30-2006 at 02:11 AM.
 
Old 12-30-2006, 03:25 AM   #3
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
I'm no VPN expert, but the MTU difference could come from the encapsulation overhead of tunnling IP through an encapsulating protocol. So if you reduce the MTU on the physical device, the MTU being reported through the VPN will probably correspondingly shrink as well and you'll end up with the same problem (just a guess).
 
Old 12-30-2006, 06:41 AM   #4
humbletech99
Member
 
Registered: Jun 2005
Posts: 374

Original Poster
Rep: Reputation: 30
well rather than go around trying to reduce the networking of all the machines at both sites in case they use the vpn, I think I will just write a pass rule for this traffic if it comes from the gateway ip addresses...

unless anybody can tell me why this icmp traffic would be a problem and I should fix that instead?
 
Old 12-30-2006, 03:45 PM   #5
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
The ICMP error is basically telling you that you tried to send a segment that was too large for the MTU of the network is was traversing, and that you need to resend the segment with a smaller size.

I believe the attack Snort is warning about is a case where a machine attempts to establish a connection with you, then reports impossibly small MTU which causes an exaustion of resources on your side.
I can't remember the exact details of the attack. I'm sure cve.mitre.org will have something about it if you care to search.

What isn't clear is why this Snort alert is triggering for something that doesn't actually seem to fit the DoS situation described. Perhaps it's simply a badly written Snort rule?
 
Old 12-30-2006, 04:13 PM   #6
humbletech99
Member
 
Registered: Jun 2005
Posts: 374

Original Poster
Rep: Reputation: 30
well, the traffic is going through firewalls so it's possible one of the links supports lower mtu size and this is the reason for the requested size reduction. I've written a pass rule for the firewalls so I don't get any more of these.

I did actually have a good look around and found info on the actual exploit, just wanted some opinions if anybody has any good knowledge of this situation.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to stop arp Denial of service/flood? 4mix Linux - Networking 4 06-13-2013 03:14 AM
how to disable TCP/IP Denial of Service mayankh Linux - Security 2 10-14-2006 04:01 AM
Problem of blocking ICMP packets while calculating Path MTU myself_rajat Linux - Networking 3 05-11-2004 12:47 AM
Denial Of Service Attacks Ozzman Mandriva 13 11-13-2003 12:59 AM
ways to protect against denial of service attacks. sundarrnathan Linux - Security 1 06-01-2003 12:58 PM


All times are GMT -5. The time now is 11:52 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration