interpreting pfsense(ntop) on wan

[securityfocus () thedaileyplanet com]

Short answer:  ignore the junk you're seeing, or call your ISP and ask to be moved to a quieter VLAN.  Hopefully you 
are not being billed for the useless traffic that is reaching you.

Long answer:  What you're seeing is likely 'fast switching' noise (or at least that's what I call it).  Modern layer 
three switches often will flood unknown or stale (to the control plane) layer three flows to all ports in a VLAN until 
the path (source and destination ports) are learned by the control plane, which then trims the forwarding plane 
flooding to unicast to the involved ports.  This can take several seconds, and sometimes results in a great deal of 
data bursting to hosts (like yours) that should not see the flow, but it is considered normal by all vendors that I 
have queried about it.  Most do not consider it a leakage problem, as flows are generally learned within the first few 
frames, and it is uncommon to push data during the handshake.  Furthermore, if it's sensitive data being transmitted 
over a public network, it should be encrypted.  If fast switching is not used, delays in handling TCP handshakes and 
UDP flow setup could cause slow start to kick in and inhi
 bit end station performance, which is especially noticeable when using a web browser for lots of short TCP 
connections.  In especially 'dirty' L3 switch implementations, unknown flows from *all* VLANs are copied to VLAN 1 in 
addition to flooding the VLAN the traffic is sourced from; in those cases, I disable VLAN 1 or remove all ports from 
it, and create new VLANs to limit leakage.  I test every piece of switching equipment I buy for this behavior.

Welcome to the vagaries of connecting to a public network.

Chad


On Thu, Dec 22, 2011 at 3:44 AM, J. von Balzac <j.gmail.com> wrote:

    > NTOP will report the frame whenever it is seen on the interface you are
    > monitoring... it does not 'ask' pfsense if it blocked it or forwarded it.
    > You might try listening on an inside interface instead of your WAN interface
    > to reduce the noise factor.

    Yes, point taken.

    > You don't mention if 198.51.100.0/24 is your inside address block or your WAN
    > address block...

    It is the address of the WAN port.

    > If 198.51.100.0/24 is inside, then NTOP is telling you that 203.0.113.25 did
    > indeed establish four sessions to .123... otherwise it appears that you're on
    > a hub or a mirror port (or just picking up fastpath switching noise) and
    > seeing these sessions being created. A bit more knowledge of your pfsense
    > box setup would be more helpful to discern good vs evil.

    Alright, here's an interesting use case. Comments/considerations welcome.

    I've a bare-metal server, configured as a Xen 4 dom0. Dom0's eth0 nic is
    connected to the ISP's switch.

    After power on dom0 boots Linux which starts a custom network script. The
    script turns off arp on eth0 and gives it a txqueuelen of 10000. Then the
    script creates a couple of STP-enabled bridges: wan0; lan0; lan1. It adds eth0
    to wan0 and then ups these 4 devices. Dom0 does not require internet access so
    it does not configure IP addresses. I can reach it via the serial port.

    Dom0 then starts up pfsense, a domU with three nics. Each is connected to one
    of dom0's bridges. Then pfsense configures an address on each device. wan0 is
    set to 198.51.100.37/24 (and one additional address, last octet .38). Its
    defaultroute is 198.51.100.1.

    When I start tcpdump -pni eth0 on dom0, I see traffic that I'm unable to
    interpret because I'm new to datacenter environments. 198.51.100.253 sends out
    VRRP advertisements to a multicast address, and it keeps sending out ARP
    requests for every IP on the subnet.

    Apart from that I see STP packets, sometimes a CDPv2 Device-ID, IGMP, many
    DHCP/BOOTP requests, IPv6 'HBH ICMP6' and router ads. And I see all kinds of
    silly traffic like netbios that obviously come from poorly configured hosts that
    live in my subnet.

    30 minutes progressed, then suddenly I see this appearing in my tcpdump:

    21:49:21.739032 IP 112.101.64.128.6000 > 198.51.100.22.9415: Flags
    [S], seq 674627584, win 16384, length 0
    21:49:22.591329 IP 121.160.102.136.9715 > 198.51.100.22.80: Flags [S],
    seq 27865527, win 65535, options [mss 1460,nop,nop,sackOK], length 0
    ...
    21:58:38.088660 IP 180.3.43.184.2788 > 198.51.100.17.445: Flags [S],
    seq 2620140464, win 16384, options [mss 1414,nop,nop,sackOK], length 0
    ...
    21:59:27.241982 IP 60.234.148.55.3795 > 198.51.100.10.23: Flags [S],
    seq 115296695, win 5772, options [mss 1443,sackOK,TS val 291724481 ecr
    0,nop,wscale 0], length 0
    21:59:28.240709 IP 60.234.148.55.3815 > 198.51.100.21.23: Flags [S],
    seq 127044603, win 5772, options [mss 1443,sackOK,TS val 291724581 ecr
    0,nop,wscale 0], length 0
    21:59:28.242273 IP 60.234.148.55.3816 > 198.51.100.22.23: Flags [S],
    seq 126898827, win 5772, options [mss 1443,sackOK,TS val 291724581 ecr
    0,nop,wscale 0], length 0


    I'm not particularly worried because all similar packets of this nature have a
    length of 0. I suppose this is what I see reflected in ntop. But sometimes I do
    see stuff like this in ntop --

    TCP Connections Established: 4 [40%]; directed to: 198.51.100.123 and
    198.51.100.210, rcvd from: 0

    These hosts aren't mine but they are in my subnet.

    Thank you,
    Jan 

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------