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 to $ext_if
I then placed the following in /root/swatchrc:
watchfor /Invali
On 9/28/05, John Marten <[EMAIL PROTECTED]> wrote:
> Thank you to all who replied. (There were several dozen)
> If I had to name everyone, there would not be room on this page! This
> list is great.
>
> Solution #1) Change the port number in sshd_config to something obscure.
>
> Solution #2) Edit t
Thank you to all who replied. (There were several dozen)
If I had to name everyone, there would not be room on this page! This
list is great.
Solution #1) Change the port number in sshd_config to something obscure.
Solution #2) Edit the sshd_config file, and include or create this
entry: MaxAut
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 insta
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
Alexander Hall wrote:
Rico wrote:
I am using this 'table 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
# p
Rico wrote:
I am using this 'table 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 sshdtrolls -T sho
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
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 persis
What you could also do is install swatch from ports or packages and have
a table in your pf.conf like this:
table persist
and a rule
#stop ssh trolls
block in log quick on $EXT_IF inet proto {tcp,udp} from to
$EXT_IF port ssh label "SSHDTrolls"
A swatchrc file of:
watchfor /Failed passw
I use an "intruder" table within pf
table file "/etc/pf.intruders"
Then in pf rules:
block drop in log-all from 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
# This counts the nu
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 b
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
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 flush global)"
table persist
block return-rst log quick proto tcp from label "ssh-pirate"
block in
pass in on $ext_if proto tcp from any to ($ext_if)
--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, but
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 s
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, 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 certa
> 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
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
On Fri, Sep 23, 2005 at 11:40:36AM -0700, John Marten wrote:
> "input_userauth_request: ivalid user somename"
> "Failed password for invalid user somename"
haven't read the entire thread yet, so doubtless this has
come up, but i use:
--
e = sis2
tablepersist
"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
>>
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 machin
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 o
On 9/23/05, John Marten <[EMAIL PROTECTED]> wrote:
> There's got to be a better way, and I'm open to suggestions.
This is really something well dealt with in the archives, so please
search those for other suggestions. I'm sure there are better options.
Personally, I use the following combination
<[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
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_userau
--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 su
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
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 a
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
[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. Don't
*you* end up blacklisting your defa
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.
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 overflow
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
probably
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
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 u
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 's
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 Bar
-
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
>
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).
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_re
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
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 usernam
> 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
I
> > still get a dozen or 2 of the
> > "sshd Invalid user
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 ###.##.##.
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.
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 mo
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: ivalid user somenam
49 matches
Mail list logo
