krypted.com

Tiny Deathstars of Foulness

OS X Server 5 (El Capitan 10.11 or Yosemite 10.10) has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -r 192.168.210.88

To add an IP to the blacklist, use the -a option, also followed by the IP:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -a 192.168.210.88

To permanently add a machine to the whitelist, use -w with the IP:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -w 192.168.210.88

And to remove a machine, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/com.apple.afctl.plist, meaning to stop the service outright, use launchctl:

launchctl unload

/Applications/Server.app/Contents/ServerRoot/usr/libexec/com.apple.afctl.plist

The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:

/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS/hb_summary

The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

September 22nd, 2015

Posted In: Mac OS X Server

Tags: , , , , , , ,

The tools to automate OS X firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.

Some tricks I’ve picked up with the Mac Firewall/alf scripting:

  • Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper, FileWave, Munki, or Absolute Manage where you might kick yourself out of your session otherwise).
  • Whatever you do, you can always reset things back to defaults by removing the com.apple.alf.plist file from /Library/Preferences replacing it with the default plist from /usr/libexec/ApplicationFirewall/com.apple.alf.plist.
  • Configure global settings, then per-application settings, then enable the firewall. If a remote system, do ;wait; and then enable the first time to make sure everything works before enabling the firewall for good.
  • To debug, use the following command: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”

In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:

/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

To see if block all is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall

The output would be as follows, if successful:

Firewall is set to block all non-essential incoming connections

A couple of global options that can be set. Stealth Mode:

/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

To check if stealth mode is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode

Firewall logging:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on

You can also control the verbosity of logs, using throttled, brief or detail. For example, if you need to troubleshoot some issues, you might set the logging to detail using the following command:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingopt: detail

To start the firewall:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:

/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on

To check if you allow signed apps:

/usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned

This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

To check if an app is blocked:

/usr/libexec/ApplicationFirewall/socketfilterfw –getappblocked /Applications/MyApp.app/Contents/MacOS/myapp

This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):

/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, verify the signature:

/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, trust the application using the –add option:

/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp

To see a list of trusted applications. You can do so by using the -l option as follows (the output is pretty ugly and needs to be parsed better):

/usr/libexec/ApplicationFirewall/socketfilterfw -l

If, in the course of your testing, you determine the firewall just isn’t for you, disable it:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off

To sanity check whether it’s started:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Or to manually stop it using launchctl (should start again with a reboot):

launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist

If you disable the firewalll using launchctl, you may need to restart services for them to work again.

July 16th, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

OS X Server (Yosemite 10.10 running Server 3.5 has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

afctl -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

afctl -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

afctl -r 192.168.210.69

To add an IP to the blacklist, use the -a option, also followed by the IP:

afctl -a 192.168.210.69

To permanently add a machine to the whitelist, use -w with the IP:

afctl -w 192.168.210.69

To remove an IP from that whitelist, use -x:

afctl -x 192.168.210.69

To straight up disable afctl, use -X:

afctl -X

To turn it back on, use -f:

afctl -f

You can also set the number of bad attempts before a host gets automatically added to the blacklist using -T:

afctl -T 5

To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/com.apple.afctl.plist, meaning to stop the service outright, use launchctl:

launchctl unload com.apple.afctl.plist

The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:

/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS/hb_summary

The output provides the following information (helpful if plugging this information into a tool like Splunk):
• Date
• Date statistics start
• Number of hosts blocked
• Addresses blocked
• Number of times each address was blocked
• Last time a host was blocked
• Total number of times a block was issued

In the past 23 hours 59 minutes the following hosts were blocked by the Adaptive Firewall
from 2014-09-13 06:10:54 +0000
to 2014-09-14 06:10:53 +0000

Address Count(Total) Last Block Time

0 unique hosts 0 total blocks 0 overall
Count indicates the number of times a host was blocked during this
reporting period. Total indicates the total number of times this host
was blocked in the last week
See the “Security:Firewall Service” section of http://help.apple.com/advancedserveradmin/
for more information about the Adaptive Firewall.

You can also use the -v argument in order to run commands verbosely.

October 16th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

The Windows Firewall is controlled using the netsh command along with the advfirewall option. This command is pretty easy to use, although knowing the syntax helps. The most basic thing you do is enable the firewall, done by issuing a set verb along with a profile (in this case we’ll use current profile) and then setting the state to on, as follows:

netsh advfirewall set currentprofile state on

Or if you were controlling the domain profile:

netsh advfirewall set domainprofile state on

You can also choose to set other options within a profile. So to set the firewall policy to always block inbound traffic and allow outgoing traffic, use the set currentprofile followed by firewallpolicy as the option to set and then blockinboundalways and allowoutbound delimited with a comma:

netsh advfirewall set currentprofile firewallpolicy blockinboundalways,allowoutbound

To restore information back to defaults, use the reset verb:

netsh advfirewall reset

To open incoming access to just the file and printer sharing services:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

Or remote desktop connections:

netsh advfirewall firewall set rule group="remote desktop" new enable=Yes profile=domain

Because the Windows Firewall can be stageful, you can also allow a program to have access (in or out), as with the following app called SecureApp.exe:

netsh advfirewall firewall add rule name="Secure App" dir=in action=allow program="C:\Program Files\SecureApp.exe" enable=yes

Or to restrict that app:

netsh advfirewall firewall add rule name="Secure App" dir=in action=deny program="C:\Program Files\SecureApp.exe" enable=yes

You can also allow based on IP or range of IP by adding the remoteip variable:

netsh advfirewall firewall add rule name="Secure App" dir=in action=allow program="C:\Program Files\SecureApp.exe" enable=yes remoteip=206.13.28.12,LocalSubnet profile=domain

Or to open a specific port:

netsh advfirewall firewall add rule name="Open SSL" dir=in action=allow protocol=TCP localport=443

Overall, the netsh advfirewall command is pretty easy to use and allows for a lot of programatic control of the Windows Firewall without having to learn a lot of complex scripting. And of course, to disable, feel free to just turn that on to an off from the initial command:

netsh advfirewall set currentprofile state off

November 1st, 2013

Posted In: Windows Server, Windows XP

Tags: , , , , , , ,

OS X Server (Mavericks 10.9 running Server 3) has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

afctl -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

afctl -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

afctl -r 192.168.210.88

To add an IP to the blacklist, use the -a option, also followed by the IP:

afctl -a 192.168.210.88

To permanently add a machine to the whitelist, use -w with the IP:

afctl -w 192.168.210.88

And to remove a machine from the whittles, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/com.apple.afctl.plist, meaning to stop the service outright, use launchctl:

launchctl unload com.apple.afctl.plist

The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:

/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS/hb_summary

The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

October 23rd, 2013

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , , ,

I wrote up afctl (the command line tool to manage the OS X Server Adaptive Firewall) awhile back here http://krypted.com/mac-security/a-little-more-about-afctl-in-os-x-server. One thing I didn’t touch on is statistics. There’s a nice little command called hb_summary located in /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:

/Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle/Contents/MacOS/hb_summary

The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

October 5th, 2013

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , ,

Previously, I had done an article on using the adaptive firewall in Mac OS x Server. But I hadn’t looked at controlling it from the command line yet. In Lion Server, the firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

afctl -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

afctl -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

afctl -r 192.168.210.88

To add an IP to the blacklist, use the -a option, also followed by the IP:

afctl -a 192.168.210.88

To permanently add a machine to the whitelist, use -w with the IP:

afctl -w 192.168.210.88

And to remove a machine from the whittles, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/com.apple.afctl.plist, meaning to stop the service outright, use launchctl:

launchctl unload com.apple.afctl.plist

Finally, the configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

November 9th, 2011

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , , , ,

In a couple of previous articles I looked at automating the Application Layer Firewall in OS X. These are pretty common articles that get back-linked to the site, so I decided to update them earlier, rather than later, in the Lion release. The tools to automate firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.

Some tricks I’ve picked up with alf scripting:

  • Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper or Absolute Manage where you might kick yourself out of your session otherwise).
  • Whatever you do, you can always reset things back to defaults by removing com.apple.alf.plist file from /Library/Preferences replacing it /usr/libexec/ApplicationFirewall/com.apple.alf.plist.
  • Configure global settings, then per-application settings
  • To debug: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”

In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:

/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

A couple of global options that can be set. Stealth Mode:

/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

Firewall logging:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on

To start the firewall:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:

/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on

This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):

/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, verify the signature:

/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, trust the application using the –add option:

/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp

To see a list of trusted applications. You can do so by using the -l option as follows:

/usr/libexec/ApplicationFirewall/socketfilterfw -l

If, in the course of your testing, you determine the firewall just isn’t for you, disable it:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off

Or to manually stop it using launchctl (should start again with a reboot):

launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist

If you disable the firewalll using launchctl, you may need to restart services for them to work again.

July 20th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , ,

Using the firewall in Ubuntu can be as easy or as hard as you want to make it. BSD variants all basically use the ipfw command whereas most of the rest of the *nix world will use netfilter. Netfilter has a number of front ends; the one that comes pre-installed in Ubuntu is ufw, short for ‘uncomplicated firewall’. Ufw is good for basic port management: allow and deny type of stuff. It’s not going to have the divert or throttling options. So let’s look at some basic incantations of ufw (you need to have elevated privileges to do all of this btw).

Initial Configuration

First you need to enable ufw, which is done using the ufw command (no need to apt-get this to install it or build it from source) followed by the enable option:

ufw enable

You can also use the disable option to turn the firewall back off:

ufw disable

And to see rules and the status of the firewall, use the status option:

ufw status

The ufw Configuration File

The ufw configuration file is /etc/default/ufw. Here, you can manage some basic options of ufw. These include:

  • IPV6 – Set to YES to enable
  • DEFAULT_INPUT_POLICY – Policy for how to handle incoming traffic not otherwise defined by a rule. Defaults at DROP but can be changed to ACCEPT or REJECT
  • DEFAULT_OUTPUT_POLICY – Same as above but for handling outgoing traffic not otherwise defined by a rule.
  • DEFAULT_FORWARD_POLICY – Same as above but for forwarding packets (routing).
  • DEFAULT_APPLICATION_POLICY – I’d just leave this as the default, SKIP.
  • MANAGE_BUILTINS – when set to yes, allows ufw to manage default iptables chains as well.
  • IPT_MODULES – An array of iptables modules that can be added

To restart ufw after you make changes to the configuration file, use the services command:

service ufw reload

Or:

service ufw restart

Creating Rules

The first thing most people will want to do is enable a port. And of the ports, 22 is going to be pretty common, since without it you can’t ssh back into the box. For this, you’ll use the allow option followed by the name of the service (application profile):

ufw allow ssh

You can use numbers instead (since ufw isn’t going to know every possible combination and you might be running some on custom ports):

ufw allow 22

You can also deny traffic using the same structure, just swapping allow with deny:

ufw deny http

Beyond a basic allow and deny, you can also specify what IP addresses are able to access each port. This is done using ufw followed by the proto option, which is the followed by the actual protocol (tcp vs udp, etc) which is then followed by the from option and then the source then the to option then the IP to accept traffic (or the any option for all IPs on your box) and finally the port option followed by the actual port. Sounds like a lot until you see it in action. Let’s say you actually want to allow traffic for port 10000 but only from 192.168.210.2. In that case, your rule would be:

ufw allow proto tcp from 192.168.210.2 to any port 10000

Or if you only wanted 10000 to be accessible on one IP of your system (theoretically you have two in this scenario) that has an address of 192.168.210.254:

ufw allow proto tcp from 192.168.210.2 to 192.168.210.254 port 10000

Using ufw

Once you have your rules configured, you are invariably going to have to troubleshoot issues with the service. Obviously, start with log review to perform a hypothesis of what the problem is. To enable logging use the logging option and specify the on parameter for it:

ufw logging on

Once enabled I usually like to view both /var/log/messages and /var/log/syslog for entries:

cat /var/log/syslog | grep UFW ; cat /var/log/messages | grep UFW

One of the best troubleshooting tools to prove any hypothesis that has to do with a rule is to simply delete the rule. To delete the deny http rule that we made earlier, just use the ufw command along with the delete option specifying the deny 22 rule as the rule to remove:

ufw delete deny http

Additionally, just disabling ufw will usually tell you definitively whether you are looking at a problem with a rule, allowing you to later look into disabling each rule until you find the offending rule.

iptables

Ubuntu also comes with iptables by default. iptables is the ipchains replacement introduced a number of years ago and is much more complicated and therefore flexible than ufw, although using one does not mean you cannot use the other. To get started, let’s look at the rules:

iptables -L

You will then see all of the rules on your host. If you have been enabling rules with ufw these will be listed here. You can then configure practically anything for how each chain (a chain is a series of rules for handling packets) functions. You can still do basic tasks, such as enabling ssh, but iptables will need much more information about what specifically you are trying to do. For example, to accept incoming traffic you would need to define that the chain will add an input (by appending it to the chain using -A INPUT) for tcp packets (-p tcp) on port 22 (–dport ssh) and accepting those packets (-j ACCEPT):

iptables -A INPUT -p tcp –dport ssh -j ACCEPT

That is about as simple as iptables get. I’ll try and write up more on dealing with it later but for now you should have enough information to get a little wacky with some basic firewall functionality on Linux. Enjoy.

November 24th, 2010

Posted In: Ubuntu, Unix

Tags: , , , , , , , , , ,

The term Adaptive Firewall can mean a lot of things to a lot of people. In Mac OS X Server it means that if you attempt to logon with an inappropriate password 10 times that a dynamic rule will be created blocking access for the computer that access was attempted from for 15 minutes. After 15 minutes the dynamic rule will be removed from the server. To see the number of Dynamic Rules running on a server, look at the Firewall services Overview tab, or Active Rules. There’s not a timer but it’s pretty easy to see which IPs are blocked. I’ve found it doesn’t always clear out after 15 minutes. If not, then create a new rule and let ipfw flush the rules and any Dynamic Rules should disappear.

September 27th, 2009

Posted In: Mac OS X Server, Mac Security

Tags: , , , ,

Next Page »