IPFW Logs - is this normal?

T

tomsdongle

Hi everyone,

Forgive me if this is too obvious a question, but I enabled logging on IPFW. My FreeBSD is open to the internet (web/minecraft server).

Here is an extract from my log:

Code: 
Jan  2 06:14:25 FreeBSD sshd[39748]: error: PAM: authentication error for illegal user festival from 60.28.42.205
Jan  2 06:14:29 FreeBSD sshd[39751]: error: PAM: authentication error for illegal user files from 60.28.42.205
Jan  2 06:14:43 FreeBSD sshd[39754]: error: PAM: authentication error for illegal user frei from 60.28.42.205
Jan  2 06:14:46 FreeBSD sshd[39757]: error: PAM: authentication error for illegal user je from 60.28.42.205
Jan  2 06:14:50 FreeBSD sshd[39760]: error: PAM: authentication error for illegal user jean from 60.28.42.205
Jan  2 06:14:54 FreeBSD sshd[39763]: error: PAM: authentication error for illegal user juan from 60.28.42.205
Jan  2 06:14:58 FreeBSD sshd[39766]: error: PAM: authentication error for illegal user first from 60.28.42.205
Jan  2 06:15:10 FreeBSD sshd[39771]: error: PAM: authentication error for illegal user dank from 60.28.42.205
Jan  2 06:15:14 FreeBSD sshd[39774]: error: PAM: authentication error for illegal user farrell from 60.28.42.205
Jan  2 06:15:27 FreeBSD sshd[39777]: error: PAM: authentication error for illegal user genoveva from 60.28.42.205
Jan  2 06:15:40 FreeBSD sshd[39780]: error: PAM: authentication error for illegal user amanda from 60.28.42.205

I assume this is rogue machines attempting to connect to my machine, is this something I should worry about?

Tom
 
I've installed and configured sshguard and I've moved from 22 to a nonstandard port.

Thank you very much for your help. :)
 
As pointed out in the excellent SSH Mastery by Michael Lucas, moving to a nonstandard port really just quiets the logs without making it any more secure. You might want to tighten the parameters used by sshguard(8), and consider only allowing SSH connections from expected networks.
 
Yep, and expect anything you open up to the internet to be hit by spammers, bots and other digital vermin. Don't think that just because nobody knows about your services you won't get hit, you will. Most of the stuff you'll see is automated. They're just scanning entire IP ranges looking for that one vulnerable system they can abuse.
 
Moving to another port also worked out for us very well. Besides we have added following sshd rule in ipfwd :

Code: 
# SSH
${fwcmd} add 00800 allow tcp from any to any ${ssh-port} out via ${oif} setup keep-state
${fwcmd} add 00801 allow tcp from any to me ${ssh-port} in via ${oif} setup limit src-addr 2

By ipfwd the amount of source addresses are limited to only two.
 
ericmacmini said:
Moving to another port also worked out for us very well. Besides we have added following sshd rule in ipfwd :

Code: 
# SSH
${fwcmd} add 00800 allow tcp from any to any ${ssh-port} out via ${oif} setup keep-state
${fwcmd} add 00801 allow tcp from any to me ${ssh-port} in via ${oif} setup limit src-addr 2

By ipfwd the amount of source addresses are limited to only two.
Click to expand...

That looks silly to me.. Why limit the number of connections? Why not firewall SSH just for a couple of IP addresses? A webserver/minecraft server doesn't need to open SSH to everyone.

You could also use /etc/hosts.allow, something like this (on top of the file):

sshd : 1.1.1.1 2.2.2.2 3.3.3.3 : allow
sshd : ALL : deny

This will only allow SSH connections from the 3 IP addresses.
 
The purpose of limiting the amount of connections by limit src-addr 2 in the ipfwd conf is only added to reduce bot scan loads, and not for security reasons of course.

In my case restricting IP-range is not an option, because in case of emergency I must be able to access the server. Sometimes I am at locations whith dynamic IP-addresses.
 
on a seperate note regarding IPFW on BSD, in OS X you have the option for stealth mode "dont respont to or acknowledge attempts to access this computer using ICMP such as ping"

Does the feature existing when running IPFW on BSD?
 
Windows does that by default. Of course, it breaks ping and path MTU and who knows what else, but Windows was frightened as a child by some wild ICMP packets.
 
True, back in the good old days ICMP was used for malicious attacks and during the Windows95 era the famous PingOfDeath was used quite often to crash a win box.

But unfortunately even today ICMP can be used for malicious reasons and it has not been used properly for MTU discovery path as it should.

That's where ICMP6(4)() comes to hopefully correct all those bugs. If you ever plan to use IPv6 you will discover that certain ICMP6(4)() traffic must pass from your firewalls.
 
ericmacmini said:
The purpose of limiting the amount of connections by limit src-addr 2 in the ipfwd conf is only added to reduce bot scan loads, and not for security reasons of course.

In my case restricting IP-range is not an option, because in case of emergency I must be able to access the server. Sometimes I am at locations whith dynamic IP-addresses.
Click to expand...

If scanning causes a load, then I wonder what's going on.

If you need to access your SSH from anywhere, consider using something like OpenVPN, or knockd, or configure sshd to accept only key-authentication and disable password authentication.
 
FYI, those log entries have nothing to do with IPFW. It's sshd's own logging.

I find that just changing sshd's listen port away from the standard 22 is sufficient to stop unauthorised attempts to log in. Attackers probably don't have the time or resources to scan all 65536 ports to find out where you've moved your sshd to, as well as running their brute force script.
 
on a seperate note regarding IPFW on BSD, in OS X you have the option for stealth mode "dont respont to or acknowledge attempts to access this computer using ICMP such as ping"

Does the feature existing when running IPFW on BSD?
Click to expand...

Any thoughts on this guys?
 
All three firewalls that are available on FreeBSD support that feature. It's in fact just a simple block on the external interface that drops all incoming ICMP packets without reply. It can be achieved with a policy to drop everything or with an explicit rule that drops the ICMP packets.
 
Dropping all ICMP packets is the really, really bad idea. As an ISP Engineer, that driving me crazy.
It didn't protect your services at all! It's just a slightly increase time of bot scanning, in the best case. Not in the real life.
So use sshguard(), and allow such ICMP types as echo request (8), echo reply (0), destination unreachable (3), invalid ip header (12) and traceroute (30). More information in the icmp().
 
From https://en.wikipedia.org/wiki/Path_MTU_Discovery

For IPv4 packets, Path MTU Discovery works by setting the Don't Fragment (DF) option bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.

[snip]

Many network security devices block all ICMP messages for perceived security benefits,[6] including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.[7]
Click to expand...

So blocking ICMP completely, as stated by RusDyr in the previous post is very bad.
 
Learn how to use key-auth on sshd, mandate use of keys (disallow password login), and if possible only allow ssh from known administrative IP ranges. Don't rely on password authentication for internet facing SSH!

RusDyr said:
Dropping all ICMP packets is the really, really bad idea. As an ISP Engineer, that driving me crazy.
It didn't protect your services at all! It's just a slightly increase time of bot scanning, in the best case. Not in the real life.
So use sshguard(), and allow such ICMP types as echo request (8), echo reply (0), destination unreachable (3), invalid ip header (12) and traceroute (30). More information in the icmp().
Click to expand...



As above, dropping all ICMP is bad. Not only will you break PMTU as above, you will also break various other services, cause hung connections/timeouts rather than getting a host-unreachable response from an upstream router, etc.
 
You must log in or register to reply here.
Back
Top