# IPFW Logs - is this normal?



## tomsdongle (Jan 2, 2013)

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:


```
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


----------



## chatwizrd (Jan 2, 2013)

Yes you should change your sshd to a non standard port.

Also consider installing security/sshguard


----------



## tomsdongle (Jan 2, 2013)

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

Thank you very much for your help.


----------



## wblock@ (Jan 2, 2013)

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.


----------



## SirDice (Jan 3, 2013)

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.


----------



## ericmacmini (Jan 3, 2013)

Moving to another port also worked out for us very well. Besides we have added following sshd rule in ipfwd :


```
# 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.


----------



## frijsdijk (Jan 3, 2013)

ericmacmini said:
			
		

> Moving to another port also worked out for us very well. Besides we have added following sshd rule in ipfwd :
> 
> 
> ```
> ...



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.


----------



## ericmacmini (Jan 3, 2013)

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.


----------



## tomsdongle (Jan 3, 2013)

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?


----------



## wblock@ (Jan 3, 2013)

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.


----------



## gkontos (Jan 3, 2013)

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.


----------



## frijsdijk (Jan 4, 2013)

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.



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.


----------



## jem (Jan 4, 2013)

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.


----------



## tomsdongle (Jan 4, 2013)

> 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?



Any thoughts on this guys?


----------



## jmccue (Jan 5, 2013)

tomsdongle said:
			
		

> Any thoughts on this guys?


I use this to disable pings:

```
ipfw -q add 00510 deny log icmp from any to any in via re0
```
Please note, I used the FreeBSD Manual to generate my firewall script and the command is documented there.

John


----------



## tomsdongle (Jan 5, 2013)

thanks John,

I take it I cant get away with just running this in command line and rebooting IPFW for it to work?


----------



## kpa (Jan 5, 2013)

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.


----------



## jmccue (Jan 6, 2013)

tomsdongle said:
			
		

> I take it I cant get away with just running this in command line and rebooting IPFW for it to work?


Not really, there is some setup involving rc.conf.  This chapter ipfw chapter details what to do far better than I will ever be able to.

John


----------



## RusDyr (Feb 28, 2013)

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().


----------



## J65nko (Feb 28, 2013)

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]



So blocking ICMP completely, as stated by RusDyr in the previous post is very bad.


----------



## throAU (Mar 1, 2013)

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().





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.


----------



## RusDyr (Mar 1, 2013)

*J65nko*, the main problem with PMTU ICMP and other control ICMP message that thus can be easily spoofed and so do interfere with "legal" traffic.

In addition to previous excellent hints for SSH above, I would recommend one more: use two-factor authentication, for example, from Google: http://www.nytechgroup.com/2011/10/05/two-factor-authentication-freebsd/


----------

