Re: 72.14.207.104

From: Newsbox (nospam_for_me_please_at_thanks.invalid)
Date: 06/18/05 

Date: Sat, 18 Jun 2005 01:41:15 -0400

On Fri, 17 Jun 2005 15:15:01 -0400, Robert Glueck wrote:

>> As an additional factor, I'm still receiving unsolicited traffic from
>> 72.14.207.104 at random times even when I am not attempting to connect
>> to google.
>>
>> I'll look into this some more, and very much appreciate your quick (<15
>> minutes) and knowledgeable help. I think I'm beginning to feel better
>> now. Thanks again.
>
> I'd appreciate it if you'd look into this some more and tell us your
> findings.

Hi Robert,

I'm just a normal user with a strong interest in security. I certainly
have been looking into it and have more looking to do before I will be
satisfied (that I know enough to feel secure in reconnecting that box.)
I'll be glad to share with you what I find right here, where other more
knowledgeable readers can comment and correct, if I err. For starters,
every bit of advice that was posted here was good and correct (and fast
and helpful), as far as I can determine and believe. And I appreciate all
of it. What I have found or will find might not be precisely analogous to
what you have seen or are seeing, but will try to keep my responses
relevant. Also, this may take some time before I fully understand it
myself, if ever.

> I also frequently get unsolicited traffic, i.e. connect attempts, from a
> few locations that pass through my NAT router and then are dropped and
> logged by my firewall (Firestarter running under Xandros). This can
> happen a long time (e.g. 30 min or more) after I last connected to the
> address in question with my browser (Firefox), if I connected to it at
> all in that session. When I posted this puzzle in this newsgroup, I
> received the following response from Rincewind:
>
> "The above are responses from a web server (SPT=80). You sometimes get
> this behaviour when the web server is so slow to respond that the
> connection is timed out by your browsing machine, but the router still
> remembers the connection and passes it through. I see this frequently
> with one of the news servers I use."
>
> And another person responded:
>
> "Those appear to be http servers that are responding to a SYN request
> from your machine. If you accessed these sites from a browser but then
> closed the browser before the response came back you would get this sort
> of thing happening.
> ...... A connect attempt would be a SYN packet. These appear to be
> acknowlegments of SYN packets sent by your machine."
>
> Perhaps you're dealing with something similar. I know rather little
> about the TCP/IP protocol and don't really understand what is going on.
> I was mostly concerned about the fact that inward-bound packets were
> able to pass through my NAT router that ostensibly were not a response
> to a connection that I had initiated.
>
> Once you've figured this out, could you explain it in novice's terms?
> Thanks.
>
> Robert

I don't know anything about your NAT router, so can't comment on that.
While not saying your should ignore that issue, an iptables firewall by
itself _should_ be quite adequate for any need. Bearing in mind that
defense in layers is a superior strategy, in the event of an unknown or
undetected failure, a second layer could still protect.

I would say I have at best an intermediate level capability with iptables.
I feel as if I can read and write and understand iptables commands, and
can effectively use them for my custom purposes. I have been able to
repair the apparent firewall issue on the box with the problem, but don't
necessarily understand why any repair was necessary. The fw was running
and tested for many months with no problem, and nothing I am aware of
doing (I'm usually pretty careful and leave lots of records and tracks for
myself to check back on) _should_ have caused the kind of issues I was
seeing.

If you are on DHCP (dynamic IP address), firestarter has a big advantage
in simplicity and ease of use because it deals well with dynamic IP
address assignments. If you have static addresses you might want to look
at firehol. You can find it on google if your google doesn't quit like
mine did. These are both "front-ends" to iptables. To deal directly with
iptables, there are good tutorials, suggestions and sample scripts
available (besides man iptables!), some posted here in the past. Others
are good in many ways, but if you hit Rusty's pages you will see how good
he is at making it clear and easy to understand.

The inherent problem with front-ends is not convenience, usability or
effectiveness, but rather that they jump several levels and make the
process opaque ("easy") to the user. ie.: firestarter is a script for a
GUI that includes a "Wizard" interface to gather your preferences and
needs (very nice). The "Wizard" writes a configuration script file (very
clever and abstruse) which is called from another script file when you
click the "start firewall" button or start your connection or computer,
whichever. The actual iptables commands are generated dynamically and not
directly saved. You can view your rules but not the commands that wrote
them. Unless your head is four feet wide, you might have trouble seeing
through all those layers to find out what went wrong. That's where I am
now. It might not be your issue.

Agreed, the "TCP/IP" stuff isn't immediately obvious and easy to
understand without at least a lot of reading. But you can watch it work
in real time and study at at your leisure with (probably) ethereal. But
be careful because ethereal deals with many protocols and so has frequent
security upgrades. Be especially careful to be current with your
installed ethereal version. You can also look at your logs to see what
has been stopped and why. That's more than I can talk about now.

Now about those pesky unsolicited packets:
The advice you cited is good advice. Unsolicited traffic has many
reasons, almost all not good. It will probably be with us a long time.
As I remarked earlier, whois may be better in some cases than nslookup,
host or dig. YMMV. OTOH, a reverse DNS lookup (host, etc) may be needed
before you can get a whois answer. Some addresses seem to have no public
records at all. It's all very dodgy at times. If someone is poking
unwanted traffic at you, the first thing you want to know is who it is,
then what it is. Failing those, you want to protect yourself.

As long as your firewall is knocking them all down, you have nothing to
worry about. But how do you know that they are all being knocked down?
... A much more difficult question to answer.

When you get unsolicited traffic more than 30 minutes after you have
terminated a connection (as you and I have), something is wrong. Traffic
can go around the world several times in a handful of seconds, at worst.
Connections normally time out in a matter of a handful of minutes at most.
The #1 probable cause is something is banged up on either your (my)
system, the responding system, or some system in between. That could be
you, me or some intermediary losing grip on security.

Then there's the other thought: that someone got between you and your
correspondent. ... Hacked systems or routers, "man-in-the-middle" are all
possibilities. I'm not equipped to talk with authority.

I have some research and thoughts about this incident and will share
whatever I can tell you. I'm not done and will need more time to know
details, if ever. I may yet just dump that box and reuse the hardware
with different software. It was a good box, but if you cannot trust it,
what good is it? If my worst paranoid suspicions were true, I wouldn't
want to post them on a NG without first validating to those who could
possibly correct the issues.

Give me some more time, and ask some more question. I'll answer as best I
can, and wish you best wishes.

Relevant Pages

  • Re: EMERGENCY - need to secure my server against an ongoing SPAMMER
    ... computer with a broadband connection. ... that IP range will prevent that spammer from wasting your systems ... This approach eventually makes your firewall machine so busy it has ... A better approach is to use IPTables to deny ALL inbound attempts to ...
    (Fedora)
  • Re: firewall using iptables DHCP IP may change?
    ... >>I am trying to set up a firewall using iptables. ... >>My internet connection is via adsl, and the IP is dynamic. ... as well as with various inbound ICMP packets. ...
    (comp.os.linux.networking)
  • Re: PPPoE Help me please!
    ... I have no idea of how to write iptables rules. ... > firestarter, you install the rpm and then open the GUI front end in xwindows. ... For me to have a firewall and iptables, ... that belong to a connection that has been initiated by another, ...
    (comp.os.linux.networking)
  • Re: basic question: eth0 ppp0, which interface?
    ... I use ppp0 for the connection. ... > I have started reading up on how to use iptables for firewall protection ... I am reading up on the stuff but need ...
    (comp.os.linux.security)
  • Re: Queries
    ... Apparently REJECT carrying the appropriate response is now ... >> the relevant RFC in this regard, ... Some enterprise firewall devices are built on top of linux, ... > netfilter, and iptables. ...
    (comp.security.firewalls)