Hey gang,
We're seeing an incredible amount of port- and proxy-scans from 211.0.0.0/8,
and 0 legitimate packets from the same range. I'm thinking about blocking
the entire /8, as noone on our network needs any contact with Asia (I belive
those addresses are all in Asia - correct me if I'm wrong). Has anyone here
blocked 211.? Any unexpected results when doing so?
Thanks,
John
Unexpected? It depends on what you expect the results to be.
I have acted as a diplomat de jure negotating resumption of traffic
between people blocking these network ranges and organizations in Japan in
the past. In addition to Japan, the 211 netblock is assigned to
organizations in other Asia Pacific countries.
Its your network (or maybe your employer's network) to do whatever you
choose. You may want to consider blocking smaller ranges than the
entire /8.
Sean Donelan writes on 11/1/2003 5:23 PM:
Its your network (or maybe your employer's network) to do whatever you
choose. You may want to consider blocking smaller ranges than the
entire /8.
Or go the opposite extreme and nullroute 0/0.
Portscans on the internet are a fact of life - unpleasant, yes, but you can safely ignore them, and instead, concentrate on keeping your systems secured.
ftp://ftp.apnic.net/public/apnic/dbase/data/country-ipv4.lst
is probably your friend. 211/8 contains assignments/allocations to operators in Japan, Taiwan, Malaysia, Australia, Korea and China.
suresh@outblaze.com (Suresh Ramasubramanian) writes:
Portscans on the internet are a fact of life - unpleasant, yes, but you
can safely ignore them, and instead, concentrate on keeping your systems
secured.
that is certainly what the malware authors and users hope that we'll all do,
so listen up. just because many of the infected hosts won't be disinfected,
don't assume that there's no value in tracking and reporting them, or that
there's no reason to spend money listening to and acting on complains about
them. the internet's immune system needs *more* resources, not fewer.
There are however legitimate reasons for a portscan, responding to incoming abuse and attack being one of them, automatically searching for openrealys used to send you spam is another. Curtailing scanning shouldn't be a priority here, nailing packet kids, spammers etc should be. Sadly both of these groups don't seem to be going to jail in droves.
Andrew D Kirch wrote:
There are however legitimate reasons for a portscan, responding to incoming abuse and attack being one of them, automatically searching for openrealys used to send you spam is another.
And on that note I would like to inform all, the new SORBS scanning process is running, this involves scanning all ports of machines used to send spam or high spamassassin scoring mail. When scanning is complete it will test each port for various proxy and relay methods, identification rate varies, but I have found a large number of proxy servers recently (as many as 30 in any one minute) on unusual ports (similar to jeem, but appearing anywhere port 1 through 65535).
If you see a scan, the SORBS scans are initiated with nmap and are not using any of the stealth options (deliberately), each host scanning has a PTR record indicating a sorbs.net host barring one - that one will answer on port 80 with the SORBS website.
Scans are performed after a host sends spam or high scoring mail only, and should only be tested once in any 3 month period, unless spam is received in which case it may be tested manually as well.
I'm sorry if that inconvinences users, and/or admins, however I believe it is for the greater good.
As before anyone wanting network reports for the networks they are responsible for should send email to me (off list) and I will arrange it, there is a weekly reporting system already running at SORBS.
Yours
Matthew
trelane@trelane.net (Andrew D Kirch) writes:
There are however legitimate reasons for a portscan, responding to
incoming abuse and attack being one of them, automatically searching for
openrealys used to send you spam is another. Curtailing scanning
shouldn't be a priority here, nailing packet kids, spammers etc should
be. Sadly both of these groups don't seem to be going to jail in droves.
here's the way it works out. if a network is paying attention to complaints
then it will shut down wormridden customer hosts based on some combination of
complaints and observations, and there will be fewer legitimate port scans
which if the network notices them they'll assume they're legitimate.
if however a network is not paying attention to complaints then it will very
likely become alarmed by their IDS when legitimate port scans come through,
and then they'll (surprise!) call and complain about it. funny assymetry.
anyway, when they call, and they learn that it was a legit port scan, then
they can learn of the need to shut down wormridden customer hosts.
so no matter what, it's good to listen to complaints, and good to complain.
I've had an idea kicking around my head since Paul posted this. Most of the
reporting work seems to be centered around finding who to report problems
to.
I think we need to turn the problem around: Devise a system that assumes
owners of IP space WANT to know about problems. In simple terms, a system
that would let me issue a command such as report --open-proxy 192.168.1.1
(or even report --open-proxy 192.168.1.1 <logfiles )
and have a report sent to whoever needed to know about it.
To participate in this, I would have to run a problem-report server that
accepts reports on my IP space. It would be registered with some central
server, that refers problems to the proper server for that IP address, like
DNS.
This might be a NOC to NOC tool, or perhaps useing registered PGP
signatures, reports from other NOCs could have more weight then those from
end users.
In any case, the idea is to allow automated testing based on reports,
aggragation of reports to weed out mistakes and errors, and provide a
mechanisim for various firewalls, intusion detection systems, etc to talk to
each other to solve problems as quickly as possible.
So in the above example, if I receive the report for 192.168.1.1 being an
open proxy, I might have my system configured, because that is a residential
DSL IP, to automaticly do a full port scan on it to look for open proxies,
and if I confirm that it is open shut the line down, or just kick out a
ticket for someone to call the customer. Or, start a netflow analysis on it
to look for virus/worm traffic. Or not do anything until a certain number of
reports are received, weighted based on the ranking of PGP sigs.
Paul's use of the word immune system hit it on the head. An immune system
kicks in automaticly to fight infection, and right now there isn't one on
the net.
Christopher X. Candreva wrote:
So in the above example, if I receive the report for 192.168.1.1 being an
open proxy, I might have my system configured, because that is a residential
DSL IP, to automaticly do a full port scan on it to look for open proxies,
and if I confirm that it is open shut the line down, or just kick out a
ticket for someone to call the customer. Or, start a netflow analysis on it
to look for virus/worm traffic. Or not do anything until a certain number of
reports are received, weighted based on the ranking of PGP sigs.
That's a start, but think about this. Worms are fast now. [1]
Lets say you have 30 seconds to stop a worm from the time it hits the internet to until the time it's fully propagated to the point of serious network disruption.
Automated techniques are the only thing that will stop it but is your idea "fast enough?" I don't think so. Relying on user reports is good for compromises and spambots but it won't do anything to stop CodeRed or Nimda.
Paul's use of the word immune system hit it on the head. An immune system
kicks in automaticly to fight infection, and right now there isn't one on
the net.
It has to automatically fight it, it has to be accurate and it has to be fast.
I don't think anything comes close to that today.
-davidu
Automated techniques are the only thing that will stop it but is your
idea "fast enough?" I don't think so. Relying on user reports is good
for compromises and spambots but it won't do anything to stop CodeRed or
Nimda.
True -- but I did say that this was a:
mechanism for various firewalls, intrusion detection systems, etc to talk
to each other to solve problems as quickly as possible.
I don't think anything comes close to that today.
No, nothing does. This is a start. The example I gave of a command line tool
was just that. The idea is a framework that people and tools can use to
exchange information. I think the protocol itself -- the underlying system
-- is what will be important. The command line program would be the second
part of "Rough consensus and working code". As with DNS and web servers, I
expect there would be many implementations, from inclusion in firewall
programs to CPAN modules.
Devise a system that assumes owners of IP space WANT to know about problems.
report --open-proxy 192.168.1.1 <logfiles
and have a report sent to whoever needed to know about it.
http://www.Dshield.org/howto.php
-bryan bradsby