Home / server / Questions / 498873
Accepted
user145837
Asked: 2013-04-13 10:47:27 +0800 CST

pfSense and Snort: unexpected portscan traffic on interface

  • 772

I have a pfSense box acting as my public facing router and stateful firewall.

There is 1 WAN interface and several LAN interfaces using private IPs behind NAT.

I EXPECT to see portscans or all kinds of things with Snort on the WAN interface.

I don't expect to see this SNORT alert on one of the LAN interfaces.

Attempted Information Leak
PSNG_UDP_PORTSCAN
SRC: 165.98.148.2  (some Nicaraguan IP)
DST: 192.168.5.15  (a linux file sever on the LAN)

I have no port forwarding going to 192.168.5.15. In fact, nothing on the pfSense box at all should be forwarding/routing/NATing/PATing anything to that internal address.

I could understand if my internal machine was communicating TO the Nicaraguan ip, but how in the world do UDP datagrams make it from the WAN interface to the LAN interface with no forwarding?

pfsense

2 Answers

  1. Best Answer

    So there are a few things going on here which, I think, are causing confusion.

    First, what Snort means by source and destination. While Snort does have the capability to keep some state information for stateful inspection (called flowbits) the signatures are processed against individual packets. This means that the source and destination do not map to client and server, they map directly to the source and destination address fields in the IP header. So that means that the specific packet that caused this rule to fire had 192.168.5.15 in the destination address and 165.98.148.2 in the source address. We're talking about a single packet here, it has nothing to do with who initiated the session.

    Second, your NAT device is doing more with UDP than you think it is. TCP is easy. It's a connection oriented protocol. The whole design is that you negotiate a communication session, chat for a while, and then say goodbye. The whole process is very well defined, and the NAT devices follow those standards. They see your SYN go out and add an entry to the xlate table, then the xlate entry gets deleted when the FIN+ACK comes back in, or a FIN+RST goes out, or enough time passes.

    UDP, being connectionless, is just fire and forget. The whole idea is that the application either implements it's own handshake and/or retransmission system, or it doesn't need them. So you would assume the firewall would allow your UDP packet to go out, but any response would get blocked. Except it doesn't. Your NAT device knows that even a connectionless protocol like UDP frequently has two-way communication. As such it will insert xlate entries for outgoing UDP traffic just like it would TCP. The rules are a little different, for instance I would expect the entries to time out on a different interval and only be deleted when they time out.

    Thirdly, this alert is probably being triggered by the sfPortscan preprocessor for Snort. In a tightly restricted environment I can see it being quite useful. Otherwise it can be quite noisy. The problem lies in the types of detections that it performs

    1. TCP/UDP traffic where one host talks to one host and hits many ports
    2. TCP/UDP traffic where many hosts talk to one host and hits many ports
    3. TCP/UDP/ICMP traffic where one host talks to many hosts on a single port

    Largely because of the #3 this alert can be triggered by just about any system that's actually providing a service. For some reason Windows SMB fileservers seem to be the worst offenders for false positives.

    Now here's where things get fun. Let's assume configurations (server, network, and firewall) are all good. In that event, chances are, your file server initiated communications with the outside IP. Then the return communication triggered the sfPortscan preprocessor which caused pfSense to display an alert. This is probably a bad thing. Were I you I would start a packet capture for anything to/from your file server and an external address. Then you can start reviewing the packet captures and try to figure out what's going on.

    • 4

  2. UDP src/dest can easily be mistaken by Snort. Without knowing more about what the traffic is it's hard to say. That UDP portscan rule misfires all the time on VoIP traffic, DNS requests and other things. If you don't have any port forwards or 1:1 NAT to that internal IP, then it's not traffic sourced from the remote IP, it's from the local IP.

    • 0