Unruh wrote:
Marty <net at (no spam) comcast.martyamodeo> writes:

Some clown (on my subnet, I would guess) thinks he's exceedingly clever
and is sending repeated SSH login attempts to my machine using spoofed
IP addresses (making the consolidated attack appear to be coming from
all over the world). I'm scrutinizing his packets, but I'm not sure how
to find the "fingerprints" I need to filter them out.

I thought that the MAC address might be a good place to start looking,
but all of the packets I see are coming from the MAC address of my cable
modem. I'm not concerned about him getting in because he's attempting
root logins and I disabled root logins through ssh, but I want to drop
his nonsense traffic if I can, and also avoid any other attacks that
might be coming from him which may have escaped my notice.

Any ideas how I can dig deeper to find a common thread that I can use to
filter his traffic?

It is not a "he" it is many many "hes". ssh attacks have become a fact
of life. They AR launched from many machines around the world ( remember
that something like 1% of all windows boxes are broken and owned by
spammers, etc. -- that is a lot of IP addresses. )
You can put ssh on a different port -- almost all attacks are on the
standard port. You could disable ssh entirely.

If I do anything, I like the suggestion of blanket-banning ssh, and then
setting up a web page to authorize an IP. At least that way, a human
would have to do it, not a zombie winxx machine. SSH is too useful for
me to disable completely. Saved my bacon quite a lot of times when I
was out of town.

And you cannot "drop his traffic". His traffic has to be read by your
filtering software to drop it.

iptables terminology, not mine.

You can also put in a script to read the logs and if there is more than
say 5 unsucessful login attempts, put the address into /etc/hosts.allow
with a deny tag.

I'm doing this, but instead driving iptables filter rules with this.
This way the packets never get to reach the protocol level. They're
sending a lot of malformed SSH packets too, no doubt trying to exploit
various bugs of the past.

(but remember to keep the lines shorter than about 1000
bytes-- there is a bug in the hosts.allow software which crashes the
system if a line is longer, and Venema refuses to fix it).

Great thing about open source, "anyone" can fix it.

On Thu, 01 Oct 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <aog8c5t75j6fnr4ksb5v81ick5cqi0j4ul at (no spam) 4ax.com>, Grant wrote:

....
Sometimes I do a 'whois' on what looks like related IPs and ban entire
CIDR blocks at the firewall (a linux box with bridged modem). Just
checked, only 38 banned blocks collected over the last couple years,
so it's not a big ask for iptables to do that.

Two thoughts - what are you "offering" to the world, and what are you
trying to defend against.

... You speak of 38
banned blocks, which would be the "mostly open" situation, while I
accept connections from 3 blocks (blocking all else by default) which
would be the "mostly closed" situation.

Oh, and the port-knocking may run
into those same 'blocked by the corporate firewall' rules that made
it impractical to move your server to an obscure port.

You're yanking my chain, right?  I do have it set to do a reverse
lookup on any names that it gets to see that they map to the same IP,
and it logs failures (which I instantly ban).

ibuprofin at (no spam) painkiller.example.tld (Moe Trin) wrote:

Two thoughts - what are you "offering" to the world, and what are
you trying to defend against.

Anonymous ftp + hhtp. Defending against too much traffic

Banned blocks mostly from annoying web crawlers that don't honour
the web 'robots.txt' file -- like the recently new Chinese crawler.

Or web site rippers. Once it was some script kiddies from NL playing
with a web form -- after I used their crap traffic to refine a quota
system I blocked the IP, then the IP block when the traffic changed IPs.

Oh, and the port-knocking may run into those same 'blocked by the
corporate firewall' rules that made it impractical to move your
server to an obscure port.

Maybe one could knock the http (or 8000 port area) port? A custom
.cgi could do anything one wanted, no?

Haven't done port knocking yet as I've not yet needed to offer
'random' access for ssh

Some clown (on my subnet, I would guess) thinks he's exceedingly clever
and is sending repeated SSH login attempts to my machine using spoofed
IP addresses (making the consolidated attack appear to be coming from
all over the world).

Yup. I'm not so naive that I didn't expect this. I was just concerned
that this seemed to be on a grander scale than I had seen before and I
was wondering if there was a way if I could link all of the attacks
together or if they were operating independently.

Be careful about banning IP addresses. That is often a good way to
cause a _Self_ Denial Of Service attack.

On Thu, 01 Oct 2009, in the Usenet newsgroup comp.os.linux.networking,
in article <aog8c5t75j6fnr4ksb5v81ick5cqi0j4ul at (no spam) 4ax.com>, Grant wrote:

Marty <net at (no spam) comcast.martyamodeo> wrote:

Allen Kistler wrote:

I suggest using only public key authentication. Disable password
authentication. Some of the ssh attacks are distributed. It's
harder to guess an asymmetric key than any password you can dream up,
no matter how cool you think it is.

Sometimes I do a 'whois' on what looks like related IPs and ban entire
CIDR blocks at the firewall (a linux box with bridged modem). Just
checked, only 38 banned blocks collected over the last couple years, so
it's not a big ask for iptables to do that.

Two thoughts - what are you "offering" to the world, and what are you
trying to defend against. Most residential situations should not be
offering much (if anything) in the line of services, and this may be a
little as SSH based access (meaning no web or ftp or similar server for
example). Who are you offering these services to? The _concepts_ of
"mostly open" verses "mostly closed" as discussed in the manual page for
tcp_wrappers (man 5 hosts_access) apply. You speak of 38 banned blocks,
which would be the "mostly open" situation, while I accept connections
from 3 blocks (blocking all else by default) which would be the "mostly
closed" situation. On those occasions when my authorized users may be
traveling (and thus away from those three acceptable blocks), I usually
set up a port-knocking scheme, where one must first make a connection
attempt to some non-standard (but closed) port, with the firewall
recognizing the attempt and opening access to my systems from that
address only for a limited (one minute) period. This isn't "security by
obscurity" because once you are allowed to _connect_ you still have to
use the "normal" authentication mechanism to actually get "in". Oh,
and the port-knocking may run into those same 'blocked by the corporate
firewall' rules that made it impractical to move your server to an
obscure port.

(Moe Trin) wrote:

I hesitate to ask, but what IP[s]? Some time ago, I looked at the
logs of someone else's system, and noted a lot of consistent hits
from a handful of IP ranges registered in China. DNS lookups were
useless, as most addresses there don't have PTR records, but the
'whois' queries provide some hints.

From my block drop list:

Only caught one oddness, that:
"
# dunno, something is calling home to 38.97.225.166:6667
38.97.225.128/25
"
after a web page hijacking.

I'd possibly use https here as I don't offer that, or a web .cgi as
that server is always running (no php here

I've noticed telnet hits are more frequent last couple years, but
the firewall here bans the IP for some time after first hit to 22
or 23.

Just don't make the procedure[s] so complex that you are sure to
make a typ0 or other fumble-finger and lock yourself out.

Think I'd go for the KISS method -- after all it's only about
reducing exposure to the system scanners out there discovering an
open port to try logins on.

Be careful about banning IP addresses. That is often a good way to
cause a _Self_ Denial Of Service attack.

I usually look at log files.
They can't spoof a SSH session that inputs a username.

I also have a list of exceptions - never blacklist addresses from
certain blocks.

ibuprofin at (no spam) painkiller.example.tld (Moe Trin) wrote:

You're way ahead of me ;-)

Too much free time I'm retired.

As mentioned else-thread, my firewall doesn't have spare horse-power
to handle much of this, so the rules are pretty simple

Dunno, it's not much work, uses the iptables -recent based rules
like you use for port knocking along with external data files and
a script to get persistence when (if) the firewall is reloaded.

Downside is the timing depends on the kernel and is obscure,
also changed -- I have to rewrite this stuff to move forward from
2.6.27.$latest-stable (linux-2.6.27 is an extended maintenance
release)

Fancy stuff like ip to country or host lookups are done on the
presentation side, not in the firewall -- there it's all IP based.

Not after seeing how big the lists are -- and this form joins up
contiguous allocation blocks to reduce list IP block count.

On 3 Oct 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <7iovs0F32s5vaU1 at (no spam) mid.individual.net>, Günther Schwarz wrote:

I once asked around for a list of scientific and educational networks.
Such a list does not exist, and I'm far to lazy to collect the addresses
myself.

Depends on what you mean by scientific and educational networks. Does
the latter mean all those domains with a .edu TLD (or the national
equivalent)?

Moe Trin wrote:

Günther Schwarz wrote:

I once asked around for a list of scientific and educational
networks. Such a list does not exist, and I'm far to lazy to
collect the addresses myself.

Depends on what you mean by scientific and educational networks.
Does the latter mean all those domains with a .edu TLD (or the
national equivalent)?

On an international level there is no equivalent for the .edu TLD.

The list I had in mind should cover should cover places where people
travel to or where they have collaborations with: universities, but
also research labs like the ones from IBM or former Xerox, national
labs, hpc facilities etc.

Individual adjustments ("I travel to such and such next week - could
you adjust the ssh server for me?") are no option.