A couple of our clients sometimes have issues when sending email, with a returned non-delivery report stating the following:
Peer server rejected email:
450 Client host rejected: ‘cannot find your hostname’
It turns out this is a very strict check (usually performed by postfix), that is controlled via the directive reject_unknown_client_hostname in the postfix configuration. The documentation for the directuve can be found here:
As per the link above, the 450 error is returned when:
1) the client IP address to name mapping fails
2) the name to address mapping fails
3) the name to address mapping does not match the client IP address.
the solutions to each of the issues above are all related to the DNS infrastructure:
1) Ensure you have the correct PTR (reverse record) that returns a valid hostname for your outgoing email server’s IP address. Example:
188.8.131.52.in-addr.arpa domain name pointer compunet.com.mt.
2) Ensure that the hostname returned in the SMTP greeting and that returned in step (1) both resolve back to the correct IP address. Example:
compunet.com.mt has address 184.108.40.206
3) Ensure that your public IP for the email server matches that returned in (2)
Even though the article focuses on ruby, it is an excellent all round security article that highlights web application vulnerabilities and countermeasures. All in all, every developer and pentester should read, regardless of the language they develop in:
This article is part of a series which depicts some of the notes I took during several sessions in the Palo Alto Networks Ignite conference in Las Vegas.
IPv6 Security Notes
- Ensure that the IPv6 Firewalling option has been enabled under device > settings otherwise the PaloAlto will just route IPv6 traffic. Post PAN-OS v5 will enable this option by default
- When writing IPv6 security policies targeting ICMP traffic, use the ipv6-icmp application object. Contrast this to IPv4 traffic which uses the icmp and ping address objects
- ICMP plays a much more important role in IPv6 than it did in IPv4, so do not completely block ICMP. This will definitely break some features such as Path MTU discovery and possibly others such as neighbor discovery.
Checklist when buying or migrating to IPv6 capable equipment
- Ensure routers and switches are IPv6 capable. Unless these are very old, they tend to be very feature rich and generally only a software upgrade is needed to obtain IPv6 capabilities
- IPv6 management capability
- IPv6 High Availability features
- IPv6 application and user based policies
- Reporting and visibility into IPv6 traffic
- IPv6 SSL decryption
- IPv6 Holistic threat prevention
- Check for IPv6 ready certification:
The above checks for compliance with several IPv6 features, such as:
- Correct header processing
- Extension header processing
- Fragmentation behavior
- Neighbor discovery and auto configuration
- Router redirects
- ICMPv6 behavior
- However, note that the above do not include any security considerations
Illustration of IPv6 security issues
- Tunneling and other transitional mechanisms can circumvent IPv4 based security policies
- Example: SLAAC [stateless autoconfiguration] attack
The above described attack is easy and normally successfully carried out because:
- IPv6 is now enabled and prefered by default
- Tunneling over IPv6 can provide an easy way out to the internet for an attacker
- Since world IPv6 day, more and more sites are switching on IPv6, meaning most PC prefer to use IPv6 to reach sites such as facebook, google, etc
Mitigation of IPv6 attacks
- Use a static IPv6 host configuration
- Disable IPv6
- Positive enforcement: use policy to shut down tunneling and other known mechanisms that are unneeded and can be used for nefarious purposes
IPv6 PAN-OS notes
Updated support for:
- USER ID
- NAT64 (transition mechanism, NAT IPv6 addresses to IPv4
- OSPFv3 support still lacking
- MP-BGP support still lacking
Scenario: We needed an in-line, transparent traffic shaping solution. The solution we chose was pfsense due to it’s easy to use UI and effective QoS. The PfSense had to be placed in bridge mode, on a link that was carrying tagged traffic. It is important that the PfSense did not touch the vlan tagging, it was only to rate-limit the traffic.
The first step was to bridge the two interfaces. We first created allow rules on the firewall to allow all traffic to pass through the pfsense since filtering was not necessary. We then proceeded to bridge the interface via Interfaces > (assign) > bridges and creating a bridge interface containing the two interface in question. No further configuration was needed. PfSense retained the VLAN tagging so the L2 802.1q vlan tags were preserved across the bridge
An IP address was configured on one of the interfaces for management. Two points about configuring an IP address on the Pfsense:
- It doesnt matter which interface you configure with the IP, the interfaces are bridged
- The IP must be in the native vlan if you configure it on a physical pfsense interface
We next go on to defining queues for various traffic classes we needed. We decided not to use the wizard since that would introduce several feature we didnt need. The below is done via Firewall > Traffic Shaper.
- Enable QoS on each interface by clicking on the interface on the left hand side and ticking “Enable/disable discipline and its children“
- Decide which scheduler type to use. We chose HFSC – this is the scheduler used by several industry firewalls such as Palo Alto.
- Define the bandwidth available to the interface. In this case, since the firewall was internally placed, we set the bandwidth to 2GB/s
- Proceed to define child queues by using the “Add new queue” button. How you place the queues (i.e. parent-child relationships) is highly dependent on what you want to achieve. In our case a single “layer” of queues was sufficient. we needed a queue for each customer and an “internal” queue which takes care of internal traffic – i.e. traffic not flowing out to the internet, which should not be rate limited. A couple of points about these queues:
- You need at least one default queue per interface. This will act as a catchall. A default queue is defined as any other queue, with the difference of selecting the “default queue” option in “scheduler options”
- It’s always a good idea to enable random early detection in your queues in case they get over-subscribed
- When dealing with high-bandwidth environments such as the one presented here (internal traffic on a gigabit network) you need to increase the queue limit (this option can be changed per queue). We found a value of 2000 to be sufficient. If left as per default, your queues will not provide the maximum bandwidth you configure for them
- The most efficient QoS is applied to egress traffic. In order to visualize this, imagine you are the firewall… egress traffic on your WAN interface is what we generally call “uploading” to the internet. Similarly, egress traffic on the LAN is generally called “downloading” from the internet. Keep this in mind when defining queues. If you need to define the same queue on two interfaces (symmetric traffic shaping) simply add a new queue to the interface and ensure you name the queue in exactly the same way as you did on the other interface, for example:
- Last, apply the queues you just defined. In our case, since we had symmetric traffic shaping we wanted the queues to apply in all directions, whether egressing from one interface or the other. So we defined floating rules via firewall > rules > floating tab.
The rules allow you to classify traffic as any other firewall rule does, so you can limit by subnet, IP, service, protocol, etc… simply define the rule, and under the advanced section make sure to select the correct queue (second fiel – the first field is used for ingress QoS which we didnt use)
The nice thing is that pfsense doesnt limit the maximum number of queues that you define – much better than some commercial solutions out there!!! ;)
This document provides a short description of the most widely used Clavister (click here for more information) console commands from experience. Note: for more information about any of the commands listed below, please type in help [command]. The below commands apply to Clavister CorePlus v8.9.x
This command starts up the packet capture mechanism on the clavister. It provides filtering using wireshark-like expressions (eg source and destination IP) as well as filtering by interface and so on. This command is especially useful when troubleshooting connctivity issues, such as suspected ACL or site to site VPN issues.
This command only applies in high-availability environments. Simply typing in “ha” will return the HA status of the current unit (active/passive) as well as whether the peer unit is reachable or not. It will also display the time since this unit has been active (if any).
Another two forms of the command:
allow you to handover “master” (active) control to the peer, or vice versa.
- ipsectunnels and ipsecstats
These two commands allow you to check whether a particular vpn tunnel is up or not. The former command is a generic one, giving a quick overview of the current VPN tunnels. The latter command shows slightly more detail, and also allows filtering by remote peer IP.
This command will kill any IPSec connections to a particular remote peer IP. This comes handy when a tunnel de-syncronisation occures, that is, if the tunnel does not use keepalives (example due to incompatibilities with different vendors), one side of the tunnel is up and the other side is down. In order to start over, the “killsa” command can be used
This command is immensely useful when troubleshooting IPSec vpn negotiation issues. It is very similar to the “debug ike” / “debug ipsec” in cisco units, but presents the information in a more user-friendly format.
It will help highlight mistakes int eh VPN configuration such as mismatches, PSK problems, and so on.