I'm tempted to flag this as a duplicate since there have been several questions like this asked before, but you ask for specific security-centric things. Therefore in the spirit of helping:

There is an active security audit that's ongoing during every release cycle. It also contains good advice about some basic security measures that are already in place specifically to harden and test your system against unwanted external access.

Configuration

No Open Ports
Password hashing
SYN cookies

Subsystems

• Configurable Firewall


• Filesystem Capabilities


• PR_SET_SECCOMP

Mandatory Access Control (MAC)

• AppArmor


• SELinux


• SMACK

Filesystem encryption

• Encrypted LVM


• eCryptfs

Userspace Hardening

• Stack Protector


• Heap Protector


• Pointer Obfuscation


• Address Space Layout Randomisation (ASLR)


• Built as PIE


• Built with Fortify Source


• Built with RELRO


• Built with BIND_NOW


• Non-Executable Memory


• /proc/$pid/maps protection


• Symlink restrictions


• Hardlink restrictions


• ptrace scope

Kernel Hardening

• 0-address protection


• /dev/mem protection


• /dev/kmem disabled


• Block module loading


• Read-only data sections


• Stack protector


• Module RO/NX


• Kernel Address Display Restriction


• Blacklist Rare Protocols


• Syscall Filtering

With the list of existing protections in place, lets examine the rest of your question:

• In relation to Logging connection attempts, this has been covered, and if you want something simpler to configure there is always fail2ban or denyhosts.


• When watching configurations for modifications, there is AppArmor.


• As far as indicating on TCP/IP Stack hardening, you would need data to validate the necessity of performing this, but for the paranoid there is a good post on the advantages of blocking SYN flooding. But as you'll notice from the security audit link above, SYN Cookies is enabled by default, and helps mitigate this out of the box.

So it appears that all you really need to do at this point, is ensure the extra applications you may/may not be installing are undergoing active security audits and that you are current with any patches. Have installed any extra AppArmor profiles required to secure your customizations. (or SELinux additions, respective to your particular configuration)

How to detect a SYN attack

It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.







# netstat -n -p TCP tcp        0      0 10.100.0.200:21            

237.177.154.8:25882     SYN_RECV    - tcp        0      0 10.100.0.200:21            

236.15.133.204:2577     SYN_RECV    - tcp        0      0 10.100.0.200:21            

127.160.6.129:51748     SYN_RECV    - tcp        0      0 10.100.0.200:21            

230.220.13.25:47393     SYN_RECV    - tcp        0      0 10.100.0.200:21            



We can also count how many half-open connections are in the backlog queue at the 

moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state 

are kept in the backlog queue.







 # netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l 769 



The other method for detecting SYN attacks is to print TCP statistics and 

look at the TCP parameters which count dropped connection requests. While under 

attack, the values of these parameters grow rapidly.







 # netstat -s -P tcp | grep tcpHalfOpenDrop         tcpHalfOpenDrop     =   473 



It is important to note that every TCP port has its own backlog queue, but only

one variable of the TCP/IP stack controls the size of backlog queues for all ports.