No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Too many SSH messages in logbuffer - probably SSH attack. Solution.

Publication Date:  2012-07-27 Views:  31 Downloads:  0
Issue Description
In NE40-4 router logbuffer were found many messages like ' SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch' which repeat very frequently during long time.
NE40-4 software version is VRP3.10-235102patch16.
Customer doesn't use SSH for management (only telnet). 
Alarm Information
In logbuffer repeatedly:
...
%Mar  9 18:26:27 2007 ATC-NE40-4 SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch
%Mar  9 18:26:57 2007 ATC-NE40-4 SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch
%Mar  9 18:27:27 2007 ATC-NE40-4 SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch
%Mar  9 18:27:57 2007 ATC-NE40-4 SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch
%Mar  9 18:28:27 2007 ATC-NE40-4 SSH/5/fsm_move:FSM MOVE FROM SSH_Main_Connect TO SSH_Main_VersionMatch
...
Also possible high CPU load :
<ATC-NE40-4>dis cpu 
CPU Performance:
          0 seconds ago ||===                 ||  15%
         30 seconds ago ||==                  ||  14%
         60 seconds ago ||==                  ||  14%
         90 seconds ago ||========            ||  44%
        120 seconds ago ||=================   ||  88%
        150 seconds ago ||================    ||  83%
        180 seconds ago ||=================   ||  85%
        210 seconds ago ||=================   ||  86%
        240 seconds ago ||==================  ||  92%
        270 seconds ago ||===============     ||  79%
        300 seconds ago ||==================  ||  92%
        330 seconds ago ||==========          ||  51%
        360 seconds ago ||===                 ||  15%
        390 seconds ago ||===                 ||  15%
        420 seconds ago ||===                 ||  15%
Handling Process
1. If customer doesn't use SSH for managing this device then best choice is to restrict SSH protocol on user interface vty 0 4:
[ATC-NE40-4-ui-vty0-4]protocol inbound telnet                                   
2. another way is to use eacl - restrict the user access port 22.
3. If customer uses SSH for managing this device - you can use eacl to permit access port 22 only from known and trusted hosts.
Root Cause
Most probably reason is an SSH attack.
Suggestions
In VRP software should be developed feature of auto-protection from SSH attack.

END