[j-nsp] DOS attack?

[Matthias Gelbhardt]

Hi!

I may open a JTAC case, when I understand for which problem I should  
open one.

The following has happened:

The system (J6350) is running under 9.3R2.8, so we decided to update  
to 9.4R2.8. That was a desaster, and I hope you can help also in this  
matter. After upgrading the systems, both thought they are VRRP  
master. The problem is obvious, two sstems thinking to be the same  
appliance. Was there a change in VRRP configuration?

Because this was not working, we made a rollback. Now we have the same  
memory problems again. Starting the shell, bam Low memory, show bgp  
summary, los memory. Each event has consequences: disabling a BGP  
session.

The system has 1 GB of DRAM. What are the memory intensive processes?  
The BGP sessions? We have a J6350 at the AMS-IX where are a lot more  
BGP sessions. The VRRP processes? The rpd process has a significant  
higher memory consumption than on the AMS-IX router for example.

Before opening a JTAC ticket, you may be saying "get 1 GB of memory,  
your problems will disappear".

Regards,

Matthias

Am 17.05.2009 um 14:54 schrieb Richard A Steenbergen:

> On Sun, May 17, 2009 at 02:19:56AM -0700, Robert Raszuk wrote:
>> Hi Matthias,
>>
>>> I wonder now, which is the event, that triggered this behavious? The
>>> numer of ssh-logins at that time or this zbexpected EOF?
>>
>> I would with good deal of assurance conclude that the cause were
>> ssh-login attack which apparently starved the poor box to it's memory
>> limits.
>>
>> When even your kernel spins a panic message on the low of memory  
>> due to
>> such attack control plane can exhibit quite unexpected behavior. In  
>> my
>> opinion end-of-frame BGP message is just a consequence of this.
>>
>> The advice would be to:
>>
>> * open a case with jtac to find out why subsequent ssh-logins cause a
>> memory leak
>>
>> * reduce to very max rate-limiting for the ssh logins
>
> It's probably more likely that the box was always getting floods of  
> SSH
> connection attempts (because thats what happens to anything you  
> leave on
> the Internet with port 22 open), and the low memory condition was
> coincidental or 99% caused by something else. The openssh people would
> be shitting bricks if there was actually a memory leak from multiple
> connection attempts. Filter thy lo0 (*), but my money is on a leak
> somewhere else (or someone running a 256mb RE :P).
>
> (*) I always found it weird that JUNOS lacks a software filter for
> access to things like SSH, like a line vty access-class on Crisco.
> Obviously a proper lo0 firewall filter is "better", but there have  
> been
> a few occasions where this has been problematic over the years
> (logical-routers pre-firewall split where the integration with policy
> was tricky, EX for the first year of its life where lo0 filters didn't
> work, etc). Something as simple as a prefix-list dumping to  
> hosts.allow
> would probably be sufficient. Also being able to change the listen  
> port
> to something other than 22 might help the people who for whatever  
> reason
> aren't able to do a strict IP based filter (simple option under system
> services ssh to pass to sshd).
>
> -- 
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1  
> 2CBC)