Hi Nick
I managed to get it working like this..
I am mainly writing this also if other users might benefit from it :-)
In /etc/pf.conf I added only the following line:
block quick on $ext_if inet proto { tcp udp } from sshdhackers to $ext_if
I then placed the following in /root/swatchrc:
What you could also do is install swatch from ports or packages and have
a table in your pf.conf like this:
table sshdtrolls persist
and a rule
#stop ssh trolls
block in log quick on $EXT_IF inet proto {tcp,udp} from sshdtrolls to
$EXT_IF port ssh label SSHDTrolls
A swatchrc file of:
Dear Nick
I have tried your setup below. I too have the setup and file placement
as you, but I am not using keys.
When I try to log on as an illegal user, the atempt is logged by
authlog, and having swatch runing from the console it says:
1/1 addresses added.
I am using this 'table
Strange. It's working for me - I've just tested my own setup again and
it blocks me. Although the file logging isn't working though - not sure
why that is...
Can you confirm that your pf rules have the block line in before the
permit rule and that it's correct for your firewall rules - ie. no
Rico wrote:
I am using this 'table sshdtrolls persist file /root/pf/sshdhackers'
I don't get any entries in the sshdhackers file and I don't get blocked
from the system.
A table modification is not automatically added to the file the table
was once populated from. Use
# pfctl -t
Alexander Hall wrote:
Rico wrote:
I am using this 'table sshdtrolls persist file /root/pf/sshdhackers'
I don't get any entries in the sshdhackers file and I don't get
blocked from the system.
A table modification is not automatically added to the file the table
was once populated from.
Hi Nick
Nick Ryan wrote:
Strange. It's working for me - I've just tested my own setup again and
it blocks me. Although the file logging isn't working though - not sure
why that is...
This, I think, is the interresting part because I want that very log
file to be the blacklist file and then
Hi Rico,
I'd probably do that the other way - get rid of the log file bit out of
the swatch config and let that update the pf table. Set up a separate
cronjob to dump the table contents to a file every hour or so with a
pfctl -t sshdtrolls -T show LOGFILENAME
This way the pf table is
I second that. Blocking ssh access from Linux hosts removes 95% of these
attacks. Simple and effective.
block drop in log quick on $ext_if proto { tcp, udp } from any os Linux to any
port ssh label Block ssh from Linux hosts
/jkm
* Nick Ryan ([EMAIL PROTECTED]) wrote:
You could use pf to
I use an intruder table within pf
table intruders file /etc/pf.intruders
Then in pf rules:
block drop in log-all from intruders to any
Then I run this script out of cron on a periodic basis (remove the echo
statements for cron use - I like to run it manually, too)
#!/usr/local/bin/bash
#
El vie, 23-09-2005 a las 21:24 -0700, Ray Percival escribis:
[...]
I wonder if it's possible to fingerprint these programs. I actually
have a copy of the ssh-scanner that they use. I got it by looking at
the hack logs on a Linux server and going to the same FTP site they
used (anonymous
On Fri, Sep 23, 2005 at 08:07:35PM -0600, jared r r spiegel wrote:
caveat is that i currently haven't implemented a way to expire entries
out, however until you get something fancier tested/implemented,
some simple pf action like that above might fly
/usr/ports/sysutils/expiretable in
On Fri, 23 Sep 2005 21:24:26 -0700
Ray Percival [EMAIL PROTECTED] wrote:
Yeah. This is only a threat against *really* weak boxes. Having said
that I've seen a lot of posts talking about changing ports. That's a
line that I won't cross. I refuse to hide from the bots and it's not
even a
--On 24 September 2005 13:31 +0100, ed wrote:
What they did was to exploit gzip, I'm fairly certain. I could not
apt-get of course and thus left helpless. I no longer have faith in
user passwords. I do my best to prevent people using common user names
(besides myself who uses 'ed' of course,
just a minor variation (in B dur) for what the others had said:
relevant parts of /etc/pf.conf:
SSH_LIMIT=(max-src-conn-rate 3/30, overload bad_ssh flush global)
table bad_ssh persist
block return-rst log quick proto tcp from bad_ssh label ssh-pirate
block in
pass in on $ext_if proto tcp from
IIRC there are scripts what will automatically add lines to your
hosts.deny file. Sorry, but I can't remember the names. I suggest you
also create some keys for yourself to use and disable password
authentication. With password auth disabled the attacks won't go be
more than an annoyance for the
Have snort or portsentry add those ips to a table in pf.conf.
--Bryan
On 9/23/05, John Marten [EMAIL PROTECTED] wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But
John Marten ([EMAIL PROTECTED]) dixit:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But I
still get a dozen or 2 of the
sshd Invalid user somename from ###.##.##.###
why not use max-connections ? and dump them into a
table with no access. Or if this is a home machine just
move the port to some high port, most scripts wont bother
looking.
cheers
rm
John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess
On Friday 23 September 2005 02:40 pm, John Marten wrote:
There's got to be a better way, and I'm open to suggestions.
Use a non-standard port and/or public key exchange.
Chris
John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But I
still get a dozen or 2 of the
sshd Invalid user somename from ###.##.##.###
input_userauth_request:
You could use connection throttling, it won't eliminate them, but it will
make it take longer. If you don't need ssh on that host (although, you
probably do, I'd be lost without it) disable it. You could bind sshd to a
different port, and disable port 22 (most of these attacks are automated
bots).
-
Original Message:
From: Bryan Irvine [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Friday, September 23 2005 09:55 AM
Subject: Re: is there a way to block sshd trolling?
Have snort or portsentry add those ips to a table in pf.conf.
--Bryan
On 9/23/05, John Marten
On Fri, Sep 23, 2005 at 11:40:36AM -0700, John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
You can change the port number in /etc/ssh/sshd_config . It's 100%
effective against that kind of bots.
Greetings,
Tomasz
My only question is what if I traceroute to you, find out the IP number of your
upstream router? Then I make a bunch of connection attempts to your IP but
forge the packets to make them look like they came from your upstream. Don't
*you* end up blacklisting your default route and you become
You could use pf to block linux ssh access.
block in log quick on $EXT_IF inet proto tcp from any os Linux to port
22 label Blocked Linux ssh access:
That'll reduce it quite a lot.
John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess
On Fri, 23 Sep 2005 11:40:36 -0700
John Marten [EMAIL PROTECTED] wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But I
still get a dozen or 2 of the
sshd Invalid
Use the tarpit patch that I wrote
http://www.linbsd.org/openssh-samepasswd.patch
-Ober
-Ober
On Fri, 23 Sep 2005, Abraham Al-Saleh wrote:
You could use connection throttling, it won't eliminate them, but it will
make it take longer. If you don't need ssh on that host (although, you
Roy Morris wrote:
why not use max-connections ? and dump them into a
table with no access. Or if this is a home machine just
move the port to some high port, most scripts wont bother
looking.
Yup, I forgot to add that you can put another thing in that max-conn...
that handles the
On Friday 23 September 2005 03:15 pm, Mr.Slippery wrote:
That's how I handle this type of annoyance:
http://data.homeip.net/projects/ssh_wall.php
Slick. Er...slippery, that is.
On Fri, 23 Sep 2005 21:55:12 +0200
Tomasz Baranowski [EMAIL PROTECTED] wrote:
You can change the port number in /etc/ssh/sshd_config . It's 100%
effective against that kind of bots.
Some intelligent scripts look at tcp responses to port scans, ssh
responds with SSH-2.0, which isn't too hard to
John Marten wrote:
There's got to be a better way, and I'm open to suggestions.
Use public key authentication to start with. It's very easy to setup and
much more secure than password authentication. With public key
authentication, passwords will never work. You might also want to make
it
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
My only question is what if I traceroute to you, find out the
IP number of your upstream router? Then I make a bunch of
connection attempts to your IP but forge the packets to make
them look like they came from your upstream. Don't *you*
--On 23 September 2005 15:05 -0500, [EMAIL PROTECTED] wrote:
My only question is what if I traceroute to you, find out the IP
number of your upstream router? Then I make a bunch of connection
attempts to your IP but forge the packets to make them look like they
came from your upstream.
The
John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But I
still get a dozen or 2 of the
sshd Invalid user somename from ###.##.##.###
[EMAIL PROTECTED] writes:
My only question is what if I traceroute to you, find out the IP number of
your upstream router? Then I make a bunch of connection attempts to your IP
but forge the packets to make them look like they came from your upstream.
Don't *you* end up blacklisting your
just to add my $0.02. The best they could hope for would be disallowing your
default gateway from connecting to your ssh server... whoop-de-doo.
On 9/23/05, Wolfgang S. Rupprecht
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
My only question is what if I traceroute to you, find out the
From: Wolfgang S. Rupprecht
2) Forging the source IP in a TCP packet and succeeding in negotiating
the 3-way handshake isn't all that simple any more. I wouldn't
worry about it. If someone could forge that reliably, there is
much better game to go after (like breaking into machines
Spruell, Darren-Perot [EMAIL PROTECTED] writes:
From: Wolfgang S. Rupprecht
2) Forging the source IP in a TCP packet and succeeding in negotiating
the 3-way handshake isn't all that simple any more. I wouldn't
worry about it. If someone could forge that reliably, there is
much
On Friday 23 September 2005 14:40, John Marten wrote:
You know what i mean? Every day I get some script kiddie, or adult
trying to guess usernames or passwords.
I've installed the newest version of SSH, so i'm covered there. But I
still get a dozen or 2 of the
sshd Invalid user somename from
Some intelligent scripts look at tcp responses to port scans, ssh
responds with SSH-2.0, which isn't too hard to identify. I don't know if
changing the greeting would break the protocol, but I suspect it might
break certain clients.
I wonder if it's possible to fingerprint these programs. I
On Fri, Sep 23, 2005 at 08:24:15PM -0700, Bryan Irvine wrote:
Some intelligent scripts look at tcp responses to port scans, ssh
responds with SSH-2.0, which isn't too hard to identify. I don't know if
changing the greeting would break the protocol, but I suspect it might
break certain
42 matches
Mail list logo
