sshd killed due to dos attack

ravindra Chavalam ravindra1103 at gmail.com
Sat Jan 30 00:09:39 EST 2010


Sorry for all the bad observations..Actual problem appears to be in
sshd_exchange_identification function(that also i am not sure). When i
attach the debugger i am getting a SIGPIPE signal sont know the exact
location where the issue is generated because i am not able to set the
source to my gdb

Thanks
Ravindranath

On Thu, Jan 28, 2010 at 4:57 PM, ravindra Chavalam
<ravindra1103 at gmail.com>wrote:

> Sorry for repetitive mails. But here is my one more observation
>
>   -->First i made five successfull ssh connections to the sshd from my
> local host.(It wont allow me to do the 6th one becase 5 are the max limit of
> ssh connections)
>
>  -->Then i ran the same tcpjunk command
>
>  -->Now all the logs are filled with the below logs
>
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
> Jan 28 16:49:17 gateway  user.info sshd: dropping connections
>
> also netstat-an|grep ":22" shows only
>
> tcp        6      0 0.0.0.0:22              0.0.0.0:*               LISTEN
> tcp        0      0 192.168.71.1:22         192.168.71.4:36320
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:36246
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:35994
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:34288
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:60815
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:35582
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:36102
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:35821
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:59029
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:50535
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:33056
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:41566
> SYN_RECV
> tcp        0      0 192.168.71.1:22         192.168.71.4:32920
> SYN_RECV
> tcp      101      0 192.168.71.1:22         192.168.71.4:36455
> ESTABLISHED
> tcp      101      0 192.168.71.1:22         192.168.71.4:36450
> ESTABLISHED
> tcp        0      0 192.168.71.1:22         192.168.71.4:38544
> ESTABLISHED
> tcp        0      0 192.168.71.1:22         192.168.71.4:60814
> FIN_WAIT2
> tcp      101      0 192.168.71.1:22         192.168.71.4:36453
> ESTABLISHED
> tcp      101      0 192.168.71.1:22         192.168.71.4:36452
> ESTABLISHED
> tcp      101      0 192.168.71.1:22         192.168.71.4:36449
> ESTABLISHED
> tcp      101      0 192.168.71.1:22         192.168.71.4:36448
> ESTABLISHED
> tcp        0      0 192.168.71.1:22         192.168.71.4:38546
> ESTABLISHED
> tcp        0      0 192.168.71.1:22         192.168.71.4:33041
> FIN_WAIT2
> tcp      101      0 192.168.71.1:22         192.168.71.4:36451
> ESTABLISHED
> tcp        0      0 192.168.71.1:22         192.168.71.4:45284
> FIN_WAIT2
>
> Note:There are no TIME_WAIT as in previous case where sshd gets killed
> -->Now when i ran multiple tcpjunk sessions also sshd is working properly
> without any issues
>
> Hope this information gives some clues
>
>
> Thanks & Regards,
> Ravindranath
>
>
> On Thu, Jan 28, 2010 at 3:42 PM, ravindra Chavalam <ravindra1103 at gmail.com
> > wrote:
>
>> Hi Ben,
>>              One more interesting observation. I kept this line before
>> drop_connection(..) function call...
>> syslog
>> (LOG_INFO,"startups:%d,rate:%d,begin:%d,full:%d",startups,options.max_startups_rate,options.max_startups_begin,options.max_startups);
>>                 if (drop_connection(startups) == 1) {
>>
>>
>> and my log after running tcpjunk shows below log when the sshd got killed.
>> So based on the parameters shown in the log and the way drop_connection is
>> implemented it seems no way this fucnion is called. Note:startups is 0
>> always and drop_connection always retuns FALSE
>>
>> tail -f /var/log/messages
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>> Jan 28 15:30:24 gateway  user.info sshd:
>> startups:0,rate:100,begin:5,full:5
>>
>>
>> Thanks & Regards,
>> Ravindranath
>>
>>
>> On Thu, Jan 28, 2010 at 3:00 PM, ravindra Chavalam <
>> ravindra1103 at gmail.com> wrote:
>>
>>> Hi Ben,
>>>
>>>  Thanks a lot for the response. I gave MaxStartups 10:30:60 (these are
>>> defaults i suppose for our requirements). Still facing the same issue. Is
>>> sshd getting killed is the expected behaviour?in that case how can i work
>>> around so that instead of killing sshd i just drop extra connections. Also
>>> interesting fact is drop_connections is not getting called?
>>>
>>> Thanks & Regards,
>>> Ravindranath
>>>
>>> On Wed, Jan 27, 2010 at 8:10 PM, Ben Lindstrom <mouring at eviladmin.org>wrote:
>>>
>>>>
>>>> You really need to explain what you are doing as a DOS attack.. If all
>>>> you are doing is filling up the max unauthenticated connections this is a
>>>> known feature and you really should read the sshd_config manpage on
>>>> "MaxStartups" feature.
>>>>
>>>> - Ben
>>>>
>>>>
>>>> On Jan 27, 2010, at 12:51 AM, ravindra Chavalam wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I am not sure to report this as a bug. so mailing to the list.
>>>> >
>>>> >
>>>> > I have sshd(openssh3.5p1) server running on my router and when i run
>>>> tcpjunk
>>>> > to that port, sshd gets killed after some time
>>>> >
>>>> > 192.168.71.1 is my sshd server and 192.168.71.4 is my client from
>>>> where i
>>>> > send my dos attack
>>>> >
>>>> > This is the tcpjunk command i gave to the ssh server
>>>> >
>>>> > #tcpjunk -s 192.168.71.1 -p 22 -c req -i 100
>>>> > req session file contains string <fuzz any 101>
>>>> >
>>>> > below attached is the netstat output. They are lot of these like these
>>>> but i
>>>> > just pasted two lines for reference
>>>> >
>>>> > #netstat -an|grep ":22"
>>>> > tcp 0 0 192.168.71.1:22 192.168.71.4:37757 TIME_WAIT
>>>> > tcp 0 0 192.168.71.1:22 192.168.71.4:55207 TIME_WAIT
>>>> > ...
>>>> > ...
>>>> >
>>>> > ...
>>>> >
>>>> > ...
>>>> >
>>>> >
>>>> > Can any one on tell me where in the openssh code i have to search to
>>>> find
>>>> > out the root cause for this issue
>>>> >
>>>> >
>>>> > Thanks a lot in advance
>>>> > _______________________________________________
>>>> > openssh-unix-dev mailing list
>>>> > openssh-unix-dev at mindrot.org
>>>> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>>
>>>>
>>>
>>
>


More information about the openssh-unix-dev mailing list