From: Jos C. <ssh...@cl...> - 2016-05-03 15:36:57
|
Is there a way of blocking port scanners and treat them as false login? From my FreeBSD all.log May 3 17:24:18 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 x.x.x.x:28997 in via re0 May 3 17:24:26 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 x.x.x.x:11505 in via re0 May 3 17:24:31 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 x.x.x.x:21643 in via re0 May 3 17:24:33 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 x.x.x.x:28800 in via re0 Best regards, Jos Chrispijn |
From: Jos C. <ssh...@cl...> - 2018-10-07 14:58:31
|
Would it be possible to put this behaviour as being abusive and put on the blacklist as well? Oct 7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from [221.225.107.228]:56134 to [x.x.x.x]:25 Oct 7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT [221.225.107.228]:56134 Oct 7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from [221.225.107.228]:56149 to [x.x.x.x]:25 Oct 7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT [221.225.107.228]:56149 Oct 7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from [221.225.107.228]:56168 to [1x.x.x.x]:25 Oct 7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT [221.225.107.228]:56168 thanks, Jos -- With both feed on the ground you will never make a step forward |
From: Jos C. <ssh...@cl...> - 2018-10-13 18:21:09
|
Was this a stupid question or is there a way to solve this? On 7-10-2018 16:41, Jos Chrispijn wrote: > > Would it be possible to put this behaviour as being abusive and put on > the blacklist as well? > > Oct 7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from > [221.225.107.228]:56134 to [x.x.x.x]:25 > Oct 7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT > [221.225.107.228]:56134 > Oct 7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from > [221.225.107.228]:56149 to [x.x.x.x]:25 > Oct 7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT > [221.225.107.228]:56149 > Oct 7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from > [221.225.107.228]:56168 to [1x.x.x.x]:25 > Oct 7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT > [221.225.107.228]:56168 > > thanks, Jos > |
From: Kevin Z. <kev...@gm...> - 2018-10-13 18:38:21
|
Not a stupid question; I (or someone else) just needs to sit down and write the rules for this new attack signature. On 10/13/18 11:20 AM, Jos Chrispijn wrote: > Was this a stupid question or is there a way to solve this? > > On 7-10-2018 16:41, Jos Chrispijn wrote: >> >> Would it be possible to put this behaviour as being abusive and put on >> the blacklist as well? >> >> Oct 7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from >> [221.225.107.228]:56134 to [x.x.x.x]:25 >> Oct 7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT >> [221.225.107.228]:56134 >> Oct 7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from >> [221.225.107.228]:56149 to [x.x.x.x]:25 >> Oct 7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT >> [221.225.107.228]:56149 >> Oct 7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from >> [221.225.107.228]:56168 to [1x.x.x.x]:25 >> Oct 7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT >> [221.225.107.228]:56168 >> >> thanks, Jos >> > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Jim S. <jse...@Li...> - 2018-10-14 13:43:25
|
On Sat, 13 Oct 2018 11:38:20 -0700 Kevin Zheng <kev...@gm...> wrote: > On 10/13/18 11:20 AM, Jos Chrispijn wrote: > > Was this a stupid question or is there a way to solve this? > > > > On 7-10-2018 16:41, Jos Chrispijn wrote: > >> > >> Would it be possible to put this behaviour as being abusive and > >> put on the blacklist as well? > >> > >> Oct 7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from > >> [221.225.107.228]:56134 to [x.x.x.x]:25 > >> Oct 7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT > >> [221.225.107.228]:56134 > >> Oct 7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from > >> [221.225.107.228]:56149 to [x.x.x.x]:25 > >> Oct 7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT > >> [221.225.107.228]:56149 > >> Oct 7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from > >> [221.225.107.228]:56168 to [1x.x.x.x]:25 > >> Oct 7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT > >> [221.225.107.228]:56168 > >> > >> thanks, Jos > > Not a stupid question; I (or someone else) just needs to sit down > and write the rules for this new attack signature. > CONNECT and DISCONNECT messages are normal. They do not indicate an authentication failure of any type. To write a rule for this, sshguard would have to be able to understand that "X number of repeated CONNECT/DISCONNECT messages w/in one second of each other is bad." Can sshguard do that? That would be pretty sophisticated rule interpretation. Besides which, a CONNECT, followed by an immediate DISCONNECT, is not a *security* threat, per se. In fact it might well be no more than TCP stack or firewall brain-damage: http://postfix.1071664.n5.nabble.com/meaning-of-connect-immediately-followed-by-disconnect-in-mail-log-td32773.html Personally, I wouldn't worry about it. Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>. |
From: Jos C. <ssh...@cl...> - 2018-10-14 16:27:39
|
On 14-10-2018 15:43, Jim Seymour wrote: > Can sshguard do that? That would be pretty sophisticated rule > interpretation. If the same IP address tries to connect 60 times in a minute there is definitely more going on than just a trial on error. CONNECT and DISCONNECT is a logic response to such 'initiatives'. In this case it is all about the number of tries per minute rather than the log display this causes. > Personally, I wouldn't worry about it. -- With both feed on the ground you will never make a step forward |
From: Gary <li...@la...> - 2018-10-14 20:10:45
|
<html><head><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;"><style id="outgoing-font-settings">#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;}</style></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;" dir="auto" contenteditable="false"> <div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"> The "anvil" feature of Postfix works well in throttling pesky servers. </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">I don't use the email features of SSHGuard at all. Less is more. All I want are those useless ssh attempts throttled. </div> <div name="BB10" id="response_div_spacer_BBPPID" dir="auto" style="width:100%;"> <br style="display:initial"></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto"> <div id="_signaturePlaceholder_BBPPID" name="BB10" dir="auto"></div> </div></div><div id="_original_msg_header_BBPPID" dir="auto"> <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false"><tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, "BB Alpha Sans", "Slate Pro"; font-size: 10pt;"> <div id="from"><b>From:</b> ssh...@cl...</div><div id="sent"><b>Sent:</b> October 14, 2018 9:27 AM</div><div id="to"><b>To:</b> ssh...@li...; jse...@Li...</div><div id="subject"><b>Subject:</b> Re: [SSHGuard-users] Portscanners</div></div></td></tr></tbody></table> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div><div class="moz-cite-prefix">On 14-10-2018 15:43, Jim Seymour wrote:<br> </div><blockquote type="cite">Can sshguard do that? That would be pretty sophisticated rule <pre class="moz-quote-pre">interpretation.</pre> </blockquote><p>If the same IP address tries to connect 60 times in a minute there is definitely more going on than just a trial on error.<br> </p><p>CONNECT and DISCONNECT is a logic response to such 'initiatives'. In this case it is all about the number of tries per minute rather than the log display this causes.</p><p>> Personally, I wouldn't worry about it.</p><p><br> </p><p>-- With both feed on the ground you will never make a step forward </p></div> <!--end of _originalContent --></div></body></html> |
From: Kevin Z. <kev...@gm...> - 2016-05-04 04:16:25
|
On 05/03/2016 08:36, Jos Chrispijn wrote: > Is there a way of blocking port scanners and treat them as false login? Yes, by adding these signatures and monitoring 'all.log'. But this wouldn't stop these log messages from showing up, because the attackers would still hit the firewall. It doesn't make sense to have a firewall protecting the firewall. > May 3 17:24:18 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 > x.x.x.x:28997 in via re0 > May 3 17:24:26 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 > x.x.x.x:11505 in via re0 > May 3 17:24:31 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 > x.x.x.x:21643 in via re0 > May 3 17:24:33 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 > x.x.x.x:28800 in via re0 I think this is beyond the scope of SSHGuard. SSHGuard protects against service attacks, not port scans. The intent of SSHGuard is to use a firewall to prevent rapid attacks against services (that takes up CPU and memory resources). -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Willem J. W. <wj...@di...> - 2016-05-04 08:15:21
|
On 4-5-2016 06:16, Kevin Zheng wrote: > On 05/03/2016 08:36, Jos Chrispijn wrote: >> Is there a way of blocking port scanners and treat them as false login? > > Yes, by adding these signatures and monitoring 'all.log'. But this > wouldn't stop these log messages from showing up, because the attackers > would still hit the firewall. It doesn't make sense to have a firewall > protecting the firewall. > >> May 3 17:24:18 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 >> x.x.x.x:28997 in via re0 >> May 3 17:24:26 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 >> x.x.x.x:11505 in via re0 >> May 3 17:24:31 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 >> x.x.x.x:21643 in via re0 >> May 3 17:24:33 ceto kernel: ipfw: 7300 Deny TCP 163.172.31.102:41712 >> x.x.x.x:28800 in via re0 > > I think this is beyond the scope of SSHGuard. SSHGuard protects against > service attacks, not port scans. The intent of SSHGuard is to use a > firewall to prevent rapid attacks against services (that takes up CPU > and memory resources). As a blunt tools I use portsentry. If you hit any of the ports normlly used with backdoors, p2p, ... all kinds of things I do not serve and do not want to be accessed. I'm using it in the same way as sshguard: ipfw table <nr of choice> add <ipnr> And then build a list of tables that are being blocked.... 01050 deny ip from table(10) to any 01060 deny ip from table(21) to any 01070 deny ip from table(22) to any 01080 deny ip from table(25) to any 01090 deny ip from table(26) to any 01100 deny ip from table(40) to any 01110 deny ip from table(41) to any 01120 deny ip from table(42) to any 01130 deny ip from table(43) to any 01140 deny ip from table(50) to any 01150 deny ip from table(53) to any 01160 deny ip from table(54) to any 01170 deny ip from table(55) to any 01180 deny ip from table(56) to any 01190 deny ip from table(57) to any 01200 deny ip from table(58) to any 01210 deny ip from table(59) to any 01220 deny ip from table(60) to any 01230 deny ip from table(70) to any 01240 deny ip from table(75) to any 01250 deny ip from table(80) to any 01260 deny ip from table(81) to any 01270 deny ip from table(86) to any --WjW |