On Jun 4, 2013, at 3:08 AM, Brian Burch <[email protected]> wrote:
>
> So (I hear you asking)... what are the martian packets? Here are my
> preliminary observations:
>
> 1. The two client source hosts are running ubuntu desktop 12.04 and
> 12.10 (see kernel notes above). They each have single network interfaces
> and have totally-open iptables.
>
> 2. The traffic associated with martians appears to be http and https
> from firefox. With parallel connections and many tabs open, there can be
> a lot of traffic to analyse!
>
> 3. Clusters of martians /seem/ to be associated with these machines
> "coming back from idle". The user of one system (a notepad) tends to
> close the lid, which suspends the system - martians appear when the lid
> is opened and the system resumes. The other system is a desktop which is
> never suspended, but the martians appear when the user reauthenticates a
> timer-locked session. (I am unsure whether martians originate from these
> two systems at times other than reauthentication).
>
> 4. My installation has several other systems, but I have not yet noticed
> martians originating from any of them.
>
> 5. The small sample of useful traces I have analysed show all the
> martian packets are FIN/ACK's associated with source ports different to
> those carrying properly natted data. The FIN/ACK's are retried with
> exponentially increasing timeouts until the connection presumably gets
> thrown away. (Because the packets are martians, the coarse filter
> firewall is discarding them, so the remote server never sees them to
> have an opinion about replying).
>
> 6. The remote hosts are legitimate web servers, so there is no malicious
> traffic involved. I suppose these web servers (e.g. facebook) run
> javascript on the browsers to keep event notification sessions alive.
> The firewall conntrack entries probably expire when the client systems
> become idle.
>
> I realise I could just shrug and ignore the martians. They are being
> detected and discarded, so they are doing no harm. However, I want to
> understand what is going on first, just in case it turns out to be a
> manifestation of a more significant problem.
Brian,
It sounds like the inner firewall is receiving FIN/ACKs for source/dest pairs
for which the corresponding conntrack entry has been discarded. Such packets
are considered to be in the INVALID connection tracking state, and hence do not
get NATted.
A solution on the inner firewall is to add this rule early in your rules file:
Invalid(DROP) all all
Note that if you have this rule in place already
Invalid(DROP) net all
then simply replace it with the one above. Or you can simply disable reverse
path filtering (routefilter) on the outer firewall's local interface.
-Tom
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
