Translate
|
|
Internet Deterrent And Automatic Counter Attack
Systems
Cyber defence to punitively deter net perpetrators
(eg DDOS flood attackers, Intruders, Fraudulent Bank Web Site Criminals,
etc)
|
|
Enable Counter Attack
Capability!
Defence requires robust deterrence:
Laws can't stop global attacks.
Detect & DETER
|
Index
http://www.berklix.com/deter/
:
Active Automatic Detect & Deter capability to
enhance Internet defence,
(passive national defence of Internet is
insufficient).
USA first developed active Internet deterrent
capabilities,
various countries now have & are getting hostile
Internet capability.
Major European countries need to co-operate for
active deterrence,
to more effectively deter potential attack, sharing
development effort.
Government Required:
- Not a passive cyber defence study to be spun off
to a university.
- A weapon systems development by a company or
multi- national quango.
- Operational control needs discipline &
security (USA Command is military).
- Operations will require Secretary of State
permits.
- Governmental purview of list of co-operating
national control centres.
|
To develop technology to enable automatic responses up to punitive counter attack, To
Deter Internet Attackers that launch
un- provoked security probes, intrusion attempts, &/or
attacks.
- Internet attacks are increasing
. A few nations have had counter technologies for years.
Most developed countries have nothing.
- Escape crippling assumptions that nothing can be done,
&/or that anything we might do would be too difficult
or somehow illegal.
- Remaining unprotected is too dangerous.
- Technical capability can & should be
developed.
- Governments should fund it, (as
net services need active protection, not just passive
defence, & governments & society will probably Not
want to step aside & let industry & commerce
control it. )
- Governments need to clarify or change law to allow operation.
- Operators must later be selected, licensed, &/or
authorised, by government agency &/or industry quango
(quasi autonomous non governmental organisation).
- First we need to start finance of early development, as
that will likely take longest to develop.
-
This will never be a system or product for end users.
- General public will never have access to run
active response modules.
- Home MS PCs will not run this (except possibly
passive honey pots)
- Nodes (feeding to & controlled by NOCs) will be installed in Internet data
centres with substantial net resources.
- The system will be installed & supervised by
disciplined organised professionals.
-
The page below needs re-shaping. (A Sisyphus
job, (like painting the Forth
Bridge) tracking & linking
for:
- Changing nature of
attacks.
- Changing detection
methodologies
- Possible response options
- Legal stances & possible changes in a
myriad of countries.
- See Also: Disclaimer.
Top of Page
The General Problem
- Many criminals & other hostiles are attempting
Internet server intrusion, with more hostile intent than
foolish `Script
Kiddies' (who waste valuable administrator time for
fun).
- Criminals run Fake Bank
Sites to defraud. (Some perhaps on other's suborned
systems, discovered as insecure & invaded by
criminals). Some system owners won't know, or much care if
[part of] their system is [perhaps unknowingly] invaded
& suborned, so as long as they don't notice, others get
hurt, not them, & it mostly continues to work,
(Sensible zombie designers probably ensure to not disturb
the host of their parasite).
- Here's one example of a
criminal fraud, that took very little time to analyse,
& trace back.
- DDOS flood attacks etc.
- The problem is world wide, so trying to deal with it
individually in different European countries is a poor
solution, better to standardise & share detection detection networks & analysis
techniques & jointly develop response options, even if not all
responders use all response
techniques.
The Traditional Soft Headed European Method Fails To
Deter
- Have a firewall, possibly with dynamic components, eg
traffic filters, access failure detectors, Denial of
service (DOS) traffic filters etc.
- Have an intrusion detection
system.
- Log attempted & actual intrusions, & collect
evidence to maybe much later prosecute with (expensive)
lawyers.
- Weeks quicker & cheaper than determining language
of attacker,
- Waste time every day, viewing logs bloated with details
of intrusion attempts that have failed this day, every
day.
- If one intrusion attempt catches the eye as
particularly annoying, hand analyse it (wasting more time)
write a complaint email (knowing it will probably be ignore
or bounce, determine recipients language, pay to get it
translated to whatever, send it maybe half way round the
world to Asia or somewhere, wait days or weeks for it
probably to be ignored, unanswered.
- One day discover one of those many unpunished attempted
intruders finally succeeded, & now you have Serious
trouble.
- See that Law is a failure, a waste
of time & money & does not protect.
Logging Intrusion Attempts
- Good security is of prime importance, but we can't be
complacent knowing criminals are constantly trying to pick
our locks every day.
- Logging is worth while to improve security, justify a
security budget, or counter attack, not just for
itself.
- Logging without use or a response is just a self
deceiving feel good factor for management &/or
self.
- A waste of time = money, if after admins view logs each
day, intrusion attempts are seen, yawned at, &
discarded as usual.
- Many attempts are global, eg from Asia & ex Soviet
territory etc.
- Some countries, groups & people will obviously be
next to impossible to pursue.
- No more than an occasional snowball's chance in hell of
sueing & successfully collecting from &/or
punishing some intruders if caught.
- Even if you sue an attacker - So What !?
It's a well known business ploy of corporate adversaries,
to waste & delay & distract the time of
competitor's management, by frivolous law suits, counter
suits, threats against management individuals, or any other
distractions to take their eye of the ball, always implicit
tactics in play, such as ~Our corporate lawyer is bigger
(& more expensively funded) than yours!~" ... How can
you be sure the agressor attacking doesn't have a bigger
lawyer than you can afford ? Or is not operating from a
regime with tacit approval of attacks, or at least no
interest in inhibiting attacks.
Better to respond to an attacker Fast ! Not delay waiting
for lawyers.
- Companies don't need possible financial compensation
paid years later if by some miracle they sue an intruder
& receive judgement against intruder & manage to
avoid going bankrupt in the interim after their secrets are
stolen or database damaged, & finally bailiffs
somewhere globally manage to collect cash damages.
- Companies (& administrator's careers ;-) would
prefer the damage Not to occur in the first place.
- For many firms, the extra time off line, sealing
original attacked media as evidence, & preparing new on
line duplicates, would be business lost, & bad
publicity admitting it happened.
- Cost example: Apparently (in 2005)
German (or
Bavarian ?) police won't even forward an incident worth
less than 50K Euro to their USA compatriots if incident
launched from there, as not cost
effective for less.
- Even more so for government systems, often damage will
not easily have a fiscal worth, & no chance of sueing
& collecting compensation, just a lot of damage after
intrusion, (& egg on faces ;-).
A polite response (reporting to ISPs) usually fails:
- Reporting un- provoked attacks to ISPs (Internet
Service Providers) often fails to work, even with details,
eg intrusion
complaint complete with log.
- ISPs (& others) often just ignore complaints of
being attacked by their customers or their users.
(Not just ISPs are irresponsible, other net access
providers too eg: This author's own ex
university computer lab. (decades after graduation) failed
to respond to complaint, when author reported one of their
current students, complete with address of which 3 bedroom
terraced house student attacked from ! (Yes, reports
narrowed down to which individual house!))
- ISPs usually try to hide behind their Terms Of Service
(TOS), which are irrelevant excrement to the innocent
person who was attacked by the ISP's criminal customer.
The terms of some contract between net provider &
attacker, & even local national laws
in that jurisdiction of provider & attacker, are all No
Excuse, & Irrelevant to the innocent attacked
victim.
- If ISPs reply, they never report who the miscreant was
from their site/ customer base, & what _disciplinary_
action was taken. They merely occasionally remove a
customer.
- That is Not punitive discipline. Reporting customer or
user to the authorities & or public page of dumped
miscreants could be some discipline.
- As ISPs never report that as done, a regularly attacked
victim (& many of us Are attacked every day, consult
your logs ) may consider himself
entitled to revenge himself direct, to damage the attacker
to prevent a repeat attack on self & others, &
punitively deter other attackers.
- Some ISPs are truly complacent, criminal accomplices,
making extra revenue from criminal negligence, by paying
for insufficient staffing to control their subset of
criminal users. That under cuts more responsible ISPs.
- The most criminally complacent ISP most deserve counter attack to coerce them to
purge their criminal customers.
Top of Page
Better To Deter!
- Invest in a deterrent totally automatic co-operative
response / counter attack system, to flood/ attack/ disable
attacking hosts & nets, (regardless if `innocent &
subsumed zombies' or not.
- Turn back Your problem to be Their Problem - &
Advertise Your Counter Attack facility prominently as a
deterrent,
- When the owners of the hosts the attacks come from,
finally see it Is their problem too, then they will fix
Their problem they have been hosting & tolerating until
now, as it didn't hurt till now, just hurt other innocents,
eg us.
- Some attackers will be unattended compromised / cuckoo
proxies hosts)
- Some attackers will be irresponsible large sub nets,
who don't really care until your problem becomes their
problem, eg Universities, Coffee shops with `Hot spots',
Drive by bluetooth (`war driving') connections, Lax ISPs
with dynamic IPs, etc.
- Where originator can be classified by type, maybe
different responses may be appropriate, but it's better to
Respond than continue with.
Time to Escalate Response:
- Active automatic defence will work better (eg dynamic
firewalls).
-
Why we need automatic systems not individual manual (or
even worse, infinitely slow legal) response:
The industrialised `West' has always been ahead of the
curve on technology, automating, while other countries
play catch up deploying cheap mass labour. Just as once
we ran machines to make clothes while poorer countries
hand stitched clothes, so today, some poorer countries
& or some criminals can more easily employ lots of
people at low rates, to attempt various types of
internet incursions (eg This author has received those himself too, eg
the unsolicited phone call from a noisey call centre,
with Indian accent, "You have a virus, we can remove it
for you, point your browser at our web site." (to which
the answer was "Liar!" & phone call
terminated.) We cant afford the manpower to
manually fight all those criminals. We need to Automate
Internet Defence.
- Hostile counter attack will work yet better still.
Nothing less will encourage some sites to discipline
themselves &/or their users.
- It's time to take action against sites &
irresponsible ISPs etc who host script kiddies, criminal
fraudsters, & the negligent who run insecure systems
suborned by criminals to perpetrate crime.
Americans (& Others) Have Deterrence
- The American Government & (Others) Have Systems has
long been reported as having counter attack capabilities.
(References to American counter attack test
networks: DETER
& EMIST)
- The rest of the world needs to develop its own
deterrents, as USA has consistently showed (from
approx 1982 to 2003), that it is prepared to
embargo sensitive software source exports, eg crypt.c etc,
even to close allies such as Britain.
- The rest of the (non American) world needs to develop
their own systems to [hopefully] co-operate with American
systems.
- Hoping to just beg from the American plate would fail:
Even if American technologists might be prepared to share
source code, the USA government is likely to [now or later]
munitions embargo either code &/or databases.
-
We non Americans eg Europeans etc don't get stuff free
reliably forever by waiting & begging.
- That's why
Britain & France
developed own nuclear weapons technologies through half
a century,
- That's why Europe today develops
Galileo v. GPS etc:
-
Russians have had some capability apparently (strike if
perhaps not counter strike ?
- The
Chinese Government now has facilities apparently.
- Being dependant on variant whims of future USA (or
other) political control is not an option, especially when
this technology is so comparatively cheap to develop. Time
we Started !
Top of Page
Some problems we will deal with, some we will not, some are
optional, & some we may co-operate with other
organisations.
Some We Will Deal With
Which sort of attacks are best & easiest dealt with
needs ongoing analysis, some
thoughts: We may have multiple input modules feeding a
common collator stream (on a distributed net, no single
point of vulnerability of course) If you have technical
comments, mail author or join deter mail list.
Detect & analyse for eg:
-
DDOS Distributed Denial Of Service
- Flood Attacks, deliberate overloads.
- PWD & SSH
Password cracking flood attacks.
- SMTP
open relay Spammers running automatic search tools
seeking open mail relays :
How:
In most cases above, by adding source code to the daemon
(background process) programs (eg add code to
Generic version of bind for DNS on FreeBSD).
Initially one could also use autonomous 'tail -f' of
logs. Case marked (*) by other OS specific measures.
Some Might Be Appropriate for Co- Operation With
Others
Some net abuse could not be easily automaticly detected,
but could be automatically penalised by optional automatic
outputs of this project, eg counter attacks on sites
hosting:
- Originating sites from ssh intruders.
- Originating (or controlling) bank fraud spam
traffic.
- Bank fraud spoof we sites , ( after manual analysis of Phishing spams).
-
FTPD write access probes bases
It's not worth initially including, except
perhaps as a later module from sensing Honey Pots traps, as real sites that are
trusted to run Deter software can be assumed to have
configured their FTPDs sensibly & not be at risk
from this.
( `Warez' Illegal Bootleggers, (who invade
un- safeguarded ftp servers & write bootleg
copyright films/ movies, music, pictures, sometimes
also with illegal &/or offensive content, beyond
stolen copyright. The upload often overflows discs
& causes loss of service to genuine users, &
wasted time for administrators. The mass parallel
downloads cause excessive telecoms bills from
networking providers, & lack of availability /
performance for genuine users.) )
Some We Will Not Deal With
Other net abuse phenomena, though bad, are not aimed to
be detected/ responded here for a variety of reasons,
(eg technical, not real time etc, &/or others
deal with it, or too political, or too innumerate, hard to
define, we shouldn't bite off more than we can chew,
etc.)
-
Spammers who flood
(Be it alphabet flood or from lists, & be it with
or without viral payload). The reduction/ prevention
of spam is dealt with efficiently by many others
already well established, eg
-
Excretia dumps in Web Forms:
Some `Script Kiddies' launch robots that fill
web forms with rubbish. Web forms detecting this will
be too variant, too much work for us to provide
hooks. Some form data collection may be only later be
human analysed so not appropriate for real time response; data privacy issues,
commercial firms wont want to give us data, we wont
want it & do Not want personal data harvesting
issues, Don't want any personal data (registrar/
privacy hassles)).
-
Bootleg (commercial copyright) software & music
& videos etc.:
Outside of remit. ( Publisher monopolists get
little sympathy, they get enough millions, despite free
software.
-
Child porn, {Race & religious etc} hates,
Terrorist, Bomb builder & Criminal site etc
Outside remit. Dealt with by national police
& Europol
etc. Not phenomena appropriate to real time (sub
second) automatic detection
& response.
Top of Page
Direct attacks should be relatively easily to detect &
trace, eg either by having the attacked domain host one of
our boxes, or by attacked domain including one of our
detector IPs in their DNS etc.
Most attacks will probably be from bot nets: PCs probably
running Microsoft, subverted by viruses, to the command of
remote botnet controllers. We will need
some Honey Pots deliberately open to
sense attack, so we can see where attacks come from)
One example of a honey pot: a
modified ftpd that runs open to write & read (sought by
Warez script kiddies with smallish initial test files), that
slowly throttles big uploads after initially allowing it
fast, that runs traceroute & whois etc during upload,
& that then either deletes or slows & corrupts those
downloads to buy more time to attack uploaders, [& maybe
report downloaders]. Script kiddies will think they've found
a sucker ftpd but we'vre traced them before they can alert
most of their clients to download.
Top of Page
- Our first targets may be larger criminal &/or state
sponsored brute force attacks against particular
governmental infrastructure, large organisational or
corporate/industrial (semi predictable grudge-match)
targets: The easier identifiable low hanging fruit, that
attracts press, public, business & political interest
& funding.
- Later we will need to also respond to smaller more
random, less predictable offenders, eg general criminal/
commercial etc botnet exploiters, that may be harder to
analyse.
- We can't limit ourselves to warning or counter-
attacking just lots of small botnet zombie'd PCs; That'd be
as effective as swatting mosquitoes, (& a firewall is
only about as effective as a mosquito net), we need to
analyse botnet DNA, then toss DTD in their swamp.
- Cracking Botnets to find who is
controlling them has a project of its own: Know your Enemy:
Tracking Botnets - The Honeynet Project.
- Most Honey Pots based on Microsoft
OSs (prime target), may (or not) be internal or externally
configured by co-operating 3rd parties, ie Anti virus
companies, (the R&D departments of those companies that
presumably set out their own Honey
Pots to trap future unknown viruses to document for
next release of their own virus detection software).
- Other Honey Pots based on forms of
Unix (eg Linux, BSD, Solaris etc) could be configured by
our own internal Unix staff (as Unix core skills are needed
also for the rest of the project). These will capable of
deepest monitoring for analysis.
- There may also be access to 3rd party Honey Pots (by definition they're open to some
extent anyway, but extreme care would be needed for that,
not to trigger deadly mutual embraces between counter
nets), especially with 3rd party Honey
Pots undeclared to us as Honey
Pots, & non declaration of some (or many) is
inevitable).
- Tracing of active direct attacks is relatively easy,
same core Unix etc skill sets as above.
- Tracing of indirect attacks managed by anonymous botnet controllers will be more
difficult, needs more thought,will need more MS skills than
Unix skills, (& our project core staff will be largely
Unix skilled), so we will either need co-operation with
anti virus companies etc familiar with MS, or need to
recruit some staff experienced with MS.
- Public logs of sites that have
launched un- provoked attacks, could help co-ordinate
automatic analysis of sites
appropriate for automatic defence or counter attack; This
would be just a subset of the info available to trusted
project members.
-
Analysis of some Distributed Denial Of Service (DDOS) tools;
(As intruders already have used these tools, we should
analyse them & also could consider using similar
techniques for defence by deterrent counter attack.) :
Top of Page
After detection, comes response :
Optionally a warning, disabling, counter attack, flood, or
demolition by legal enforcement, whatever responders find
appropriate.
Types Of Response
People tend to distract to debate what they think might
be morally & legally appropriate responses not just for
them, but globally, & for various sorts of incident.
Such debate is endless & distracts & delays project
design, so serves none but the ultra pacifist who might
want to block all action.
To avoid distraction into argument, the project will aim
for a modular approach, modular in detection & modular
in response, so different response policies are usable for
each mix of { recipient & responder } & { country
legal precepts & organisation / agency policy, &
individual operational chief } & type/ gravity of
attack detected by initial innocent victim, & intensity
& timing repeat factors. Responder sub nets can then
decide configure & change their own response policy,
not subject to global agreement/ endless dispute.
Options For Passive & Active Cyber Defence &
Response
These are ideas subject to discussion & refinement,
& to promote discussion on mail
list, to show there are ways to respond once the tracing/ analysis is done, but first we
need to fund the design &
development of detection & tracing/ analysis phases.
- Starting with mildest first, for civilian agencies
operating from pacificist inclined nations) ...
- Automatic emails to hostmaster@ virus/ zombie'd PC's &/ or abuser hosts,
basically saying
"WARNING We have identified you !, Control your
user ! Log attached!" see eg README
- Increased frequency: They may wake up faster if we
send 12 then 60 mails an hour. (A colleague of an absent
administrator may get tired of the "You have new mail"
audio prompt, & look at screen).
- Later harsher wordings (including countdown ?) at
higher frequencies, as imminence of counter measures
approaches.
- Flood repeat that mail to their in box till it fills,
for several reasons: Force attention; Mild punishment;
Guarantee our warning is seen & not lost among other
mail.
-
Disabling The Network Interface Configuration of botnet - zombies (while leaving other internal
components intact eg botnet subsumed individuals' files
& editors etc) :
- Install a README displayed
at boot.
- Reboot or (if PC BIOS supports it) halt the zombie PC. (Halt is better as
people will more likely notice their machine has been
turned off, gives them more time to get it fixed
before they need it perhaps urgently.
- Pass To Human Agencies occasionally to arrange
raids by police or other law
enforcement/ at remote site, (if some responder sub nets
consider that more appropriate for that cluster of
detector reports)
-
Black Lists of: IP numbers & ports
(Unix/
FreeBSD /etc/services)
-
Input To Black Lists:
- As well as trusted members of the deter
network contributing directly to database of
attackers , also ...
- Just as organisations such as spamhaus &
other RBL providers) generate black lists of spam
senders,
- The honey pot data could
be monitored, traced, & noted, for IP numbers
of attackers, route relays & attacked target
IPs & ports (Unix/
FreeBSD /etc/services)
-
Output: Broadcast of Black Lists (of IPs ( &
ports (Unix/
FreeBSD /etc/services) )
-
Those IPs could be fed to dynamic firewalls,
direct or via live relay co-operating firewall
manufacturers.
- Fed via 2 methods: (active sending
(encrypted mail?) &/ or passively made
available for polled fetching) (ftp?).
- (We have contacts at one firewall
company
to
discuss data format possibilities, more
contacts welcome, to author
or to deter mail
list))
- [Some of] Those IPs [To certain criteria]
could be web published for others not yet
integrated, (some firewall manufacturers, OS
providers (free projects & commercial) &
intelligent end user sites.
- The IPs & ports will also be fed to other
trusted nodes in our own internal Deter
network.
- Just like anti spam lists, there's the risk of
blocking a few innocent with many guilty - but if
it's that or see your net servers die from DDOS, there's some discretionary level at
which one may want to automatically enable dynamic
filtering.
-
If/ when we detect zombie botnet controllers,
- Optional human confirmed delay, if R-DNS tools
suggest attacker is in a friendly country where we
can arrange Quick response by police or equivalent to
catch attackers red handed.
- Otherwise, Automatic Co-ordinated mass
Counter Attack from our co-operating net
nodes. Targeting IPs & ports at frequencies
considered appropriate.
-
Flood Attack of packets, mail flood, web overload
& DNS overload counter DDOS.
(Counter flood of compromised equally harmful proxies/
&/or zombies may be necessary, to alert the upstream
adjacent carriers, to realise _they_ have a problem
customer to terminate immediately, & that our problem
is not theirs to ignore, but theirs to resolve,
urgently).
For Design Notes see below
Morality
Consider some analogies :
- An illegally parked vehicle doesn't necessarily get a
warning to driver or owner before it gets wheel
clamped.
- Police in stolen car chases can throw concertina
lines of claws across the road, to cripple the tires,
then later contact owner to inform them the vehicle was
used by criminals, & question owner if vehicle was
locked before it was stolen. Here's a
notice could be served on owners of detected &
disabled zombie PCs.
- If someone deliberately used a catapult to fire stuff
at or through through your window, would you feel
entitled to grab & damage the catapult. Would you
carefully ask if the user was the owner before you
snatched it or broke it ?
- If you saw daily attempts to pick your door lock at
home, would you be complacent ? wouldn't you worry they'd
one day get lucky & break in ? If you could see where
the criminals came from, would tracing the criminals back
seem sensible ? Or would you just wait for your locks to
be picked ? Wouldn't deterrence
seem better ?)
- Might you install a weak lock on one door (a honey pot), & arm the room with flash
lights, cheap net cameras, & a silent alarm to the
police station ? (& perhaps an optional deep hole if
law allowed ? rather like the optional alternate response modules of this project).
If you'd approve some of the above, best urge decision
takers to fund some initial
development of Internet detection
& tracing/ analysis capability;
then while we are developing you will have plenty of time
to consider what the dangers are, & decide what optional response modules you may
later want to help fund &/or
enable / deploy.
- Some people knee
jerk & say doing anything active would be illegal.
- They probably don't realise: General public will
never have access to run the active response modules.
- Maybe legal constraints some places, there's an
opportunity for those interested more in law to get
engaged, explaining issues to local politicians, to change
their local laws while we develop this project, so when
it's ready for delivery, those places can use it too.
- If some places can't easily or quickly get their local
law changed to allow response by
counter attack, they'll still be able to operate honey pot which will generate data for less
active responses (eg packet black lists)..
- The rest of the world won't wait, both attackers & defenders have been developing
techniques, botnets & counter methods for
years.
- Law fails currently: doesn't protect us from incoming
attacks.
- In a world where both attackers & attacked could be
in any of (singular or multiple collections of) 190 nations
, that's 36100 combinations: hoping local law might defend us is ridiculous. Especially as
most attackers may well be be in other states, some may be
in rogue states, failed states, ineffectively controlled
states, terrorist tolerant states, states with a more
tolerant view or benefiting from piracy, or cross border
criminal bands &/or groups of anarchists, or companies/
groups / religions / whatever attacking rivals, etc.
- Laws (in some jurisdictions) prevent counter attack to
deter/ penalise attackers, especially by civilian groups, -
a problem to rectify.
- Laws in aggregate can not protect, more hinder from
responding to attacks.
- Different response modules
will be available, so different people / organisations in
different jurisdictions can respond with differing methods
& intensities, (Choice of response modules Also avoids
a distracting fruitless debate for consensus on uniform
appropriate intensity, frequency, & type of response).
- Court cases would take years, at vast expense, to fail
to deter a minute percentage of attacks.
Automatic counter attack deterrents could be issued
effectively in seconds ... As quick as a child learns not
to poke a wasp again !
Countries & peoples/ sectors will present a spectrum of
early & late adopters, some background:
- Australia - CSOC - Cyber
Security Operations Centre "... to pro-actively
and reactively respond to cyber threats".
-
Britain
- Canada: WSJ
October 17, 2012, additional 155 million Canadian dollars
(US$158 million) over five years ("The U.K., for
instance, said last year it will put an extra £650
million ($1.05 billion) into cyber security over five
years. In 2008, the U.S. began its Comprehensive National
Cyber security Initiative, under which it plans to plow
more than $10 billion into cyber defense, ... the U.S.
and U.K. see more clearly that the cyber threat is an
offensive."
-
France
-
Germany
-
Web refs found at 2013-05-18:
- A German state prosecutor once opined active
counter attack wouldn't be feasible to operate [for
civilian / corporate use] [without a change of law] -
but discussion did not include for operation by
government &/or military (different laws
presumably for military).
- Plenty of time to change laws if necessary while
development proceeds in parallel.
-
Some civilians don't like the idea:
- Some don't realise or ask: Who will have
access to the response
modules, & under what disciplined procedures
for use.
- Some don't realise the normal public will
Never have access to NOC
Databases that will control response modules.
- Some tend to be rather myopic & shocked,
partly 'cos the seriousness of attacks &
necessary defence solutions are all fairly
new.
- Some seem to prefer to remain unaware that
criminals busily use the Internet as an
international free fire zone, & national laws
do Not hinder attackers, laws just hinder
defenders; Once people acknowledge that reality,
it's hard to continue to put off the decision:
Accept continued constant attack forever more,
& not defend ? Or equip to analyse &
repulse attacks, & change restrictive laws
?
- Near all forget that all the German policeman
they pass on the street have guns on hip.
).
- Shock comes from change of perspective, eg:
(this British author was also shocked when
he first encountered armed guards in normal
civilian Munich offices in 1985.
- Germans are so used to lethal weapons
regularly in close proximity they're just part of
the landscape, it doesn't shock them, yet the
thought of remotely disabling a remotely
attacking zombie PC or server, disturbs "Rechts-staat"
(aka "politically correct") mentality of some
civilians.
- Some Nay sayers could usefully re-
analyse their perspectives & pre-conceptions
& think more logically, less reactionary knee
jerking ;-).
- Parts of the German military have
expressed interest
- Some countries may prefer to place their
NOC Command & Control under
military or police discipline rather than staff it
with an authorised civilian Quango (Quasi
Autonomous Non Governmental
Organisation).
- Operational staffing decisions should not be
allowed to delay development. Development needs to be
funded now. There will be a
couple of years to develop, during which operational
staffing & policies can be debated. Attacks regularly are in the
news
- European Union.
-
Perhaps it will be easier funded,
& operated under eg a co-operation of multi
national European military or quasi military/ police
government units.
Top of Page
-
If you are a government or EU agency, company,
organisation, or perhaps with budget to help sponsor this,
or later that might help pay for some Internet Intruder
detection, passive &/or active
defence, optionally with active deterrent counter attack
systems, services, &/or consultancy , Vector Systems Ltd & associates would be pleased to
discuss ideas free of charge, please feel free to make
contact.
- Yes, we have ideas of what it will cost. It depends on
various factors, Contact us to
discuss
- Join the deter mail
list, to show interest, & keep track, if you are a
programmer interested to develop, Or a system or net
administrator interested to later perhaps use, Or a manager
who may later have a budget for purchase of licences/
donations/ or funding consultants employees or students to
help develop the technology.
- If funding is insufficient, to encourage it, (or
possibly for security reasons) we might need to restrict source repository read access so
that funders nominate who gets access to newer code, &
public access is only to older code.
- To avoid the possibility of some funders (nations or
organisations) waiting till others alone have funded the
development:
The founding nations etc who initially fund the
development, will be given the keys to form an initial net
of NOC Command & Control
Databases
Other nations/ operators who later seek to join the NOC net may be required by those who
already paid to be in the NOC net to
make a contribution to past & perhaps ongoing further
development costs, before the international net of NOCs
will accept incident & response records from the newcomer NOC.
(Not foolproof, but encouragement to help fund the moderate
costs now to get started, & not all wait for each other
to contribute funds
Top of Page
- Currently we have just one mail list:
- deter@ To discuss how best to design automatic
counter attack technologies.
- Join the
deter@ Mail List
-
Later the list may be split into sub lists, eg :
- deter-announce@ moderated to ensure
low traffic, Announcements of funding, affiliations, calls for staff,
releases available, operational status
changes.
- deter-dev@ for developers to discuss
source code
- deter-users@ a self help mutual
assistance group for users of the code & service.
Users will be experienced server
administrators.
- deter-finance@ to arrange funding of central service portions of the
project
- deter-law@ to discuss how to get
politicians to modify obstructive laws.
Top of Page
The name IDACAS (for
international page of Internet Deterrent
And Automatic Counter Attack System) may acoustically
remind one of the Greek name Icarus, who
ignored warning & flew too near the sun & melted his
wings. The similarity is somewhat apposite: There are dangers
& responsibilities to neither over react, nor under react
to attacks.
Currently nearly all countries are asleep at the
wheel, not reacting.
`Hackers And Crackers : There's A
Difference !
` Hacker':
An Ignorant Name, used by technicly incompetent press,
politicians & clueless management;
` Cracker':
The Correct Name used by skilled computer
consultants.
Mislabelling Hackers & Crackers Displays
Ignorance
The label `Hacker' is mostly wrongly used, a useful indicator
the user is probably ignorant (& that their opinions are
worth less & sometimes worthless ;-). Most journalists
& politicians mis-lead the public, mis-using the word
Hacker, exhibiting their ignorance Learn the difference !
`Hackers' Examples:
-
Programmers who efficiently hack up (ie generate/ improve
/ adapt) existing source code in minimum time, (much
quicker than commercial programmers with proprietary
sources who have to start from scratch), usually to give
away Free eg
Mail archive of a hackers group, from March 2003
on, for the FreeBSD.org free
operating system:, No evil Crackers there !, just
innocent Hackers improving free software to give away.
Called Hackers long before ignorant journalists &
politicians mis-understood & hi-jacked the term
Hacker & mis-lead the public. The FreeBSD
Foundation is listed as a public charity by the USA
IRS, read its web to see what it does.
- Journalists - long known as Hacks - hack up articles,
sometimes from pre-existent pre-supplied text eg press
releases etc. (Hacking of text ... akin to hacking
of program sources ) - How come journalists are so clueless
they don't understand the similarity ?)
- Hacks are
general purpose non specialist horses, Hacking is a form of
riding.
` Cracker' is the much better pejorative to apply to
criminal Internet system intruders & vandals etc. ...
"Cracker" as in " Safe Cracker"
etc !
Some Crackers mis-appropriate the name Hackers, but that
only fools the ignorant. A thief may call himself a fund
manager or investment manager or banker, doesn't mean you
have to believe him either, nor assume all of them are
criminals. Similarly most Hackers are not criminals.
Use the right word: Cracker not Hacker.
- The aim is to co-operate with lists & tools for
active dynamic defence & / or counter attack.
- Preference is to initially develop on BSD (even nicer
than Linux), to work with tools compatible with the
extensive ports
collection of FreeBSD.
- Using code extensively security reviewed. Based on open
free co-operative international standards
(not proprietary commercial pseudo standards attempting to
monopolise the market).
- Particularly ports/net.html
& ports/security.html
There is no question of basing these systems on Microsoft
proprietary binary, un-sourced, virus compatible OS's
(though some honey pot will use
MS.)
- Later porting anything necessary later to NetBSD (If multiple platforms
are needed. - But most design will be for
supplemental cheap BSD boxes to be connected to other
heterogenous Unix servers, so we won't need full native run
support on all Unixes direct); &/or OpenBSD (if security features
there appeal above other BSDs at assessment time).
- Systems envisaged to be based on standard cheap PC
Server hardware bases, linked to existing major
organisations gateways.
- Later it can be ported to other Unixes eg Linux if need
be, but note: The software will NOT need to, or be allowed,
or trusted to, run on normal end user PCs, it will only run
on resilient hardware in server environments, next to
gateways & routers, accessible only to some net
administrators. There is no need, & No intention to
port or run it on any OS such as Microsoft, that does not
provide OS public source code.
- Flood deterrence by counter flood is dangerous will
need careful design, management & discipline, not to
spill over to other similar systems, recurse within itself,
or mutually deadlock, etc.
(Variable escalation criteria dependent on time zones,
work days, public holidays, root national domains, if
targeting offender direct, or escalation alert levels for
innocent but possibly lethargic neighbouring carrier
etc.)
- We may pre compile lists of R-DNS
& routings etc, in background during normal peaceful
times, (like search engines use web crawlers, but we would
only store IPs & routes (not text) for internal
reference (no external public enquiry load), so a minute
fraction of the load of search providers). We would keep
this in reserve, patched to our DNS etc, for when our own
DNS & other deter services were inevitably
attacked.
- The previous point
raises questions of DNS & BGP protocol services &
resilience of existing services that have been addressed in
other forums for some time, eg
here in French
,
& how those service might be secured more, other bodies
are looking at that, we will aim to track/ co-operate with
that.
- Security: Some work proposed may require people to sign
to eg: the British official secrets act, or German or
French equivalents, eg:
French
Agence nationale de la sécurité des
systèmes d'information requires :
noter : ces postes nécessitant
d'accéder à des informations relevant du
secret de la défense nationale, le titulaire fera
l'objet d'une procédure d'habilitation, au niveau
Secret Défense.
- DNSSEC & amp; IPSEC etc will probably be needed internally
on the project, they are tools to help build the projected
solution, they are not tools that as of themselves would be
obviate the project.
Format subject to change:
"|" separated fields (not normal Unix convention of ":" eg
for tbl, as dates use ":".
Column Order
- DATE[s] of attack (TZ=CET or CEST, ie GMT+01:00
or GMT+02:00 in summer). There may have been numerous
attack before & since. A minimum of one date is noted.
This column is first to ensure a sort will recreate
chronological log order.
- Number Of Attacker
-
DNS Address of Attacker OK or a
Lie ?
Whether via nslookup, after using RARP to match the IP#
to name, the name then maps back full circle to IP
number, as it should.
Possible Values: (In sequential test &
possible result order)
Key |
Explanation |
Conclusion |
Action Possible |
"!RARP" |
R-ARP Fails: No DNS record
maps number to name. |
Secretive |
Counter attack. |
"!FARP" |
Forward Lookup fails (Inverse of R-ARP Fails): No
DNS record maps name to number.
(Even if number to name succeeds). |
Secretive |
Counter attack. |
"!A" |
A Fails: No DNS record maps
resultant name back to a number. |
Liar |
Counter attack. |
"False" |
R-ARP & then DNS A-Name
don't agree. |
Liar |
Counter attack. |
"Match" |
DNS R-ARP & subsequent A
records match, (even if A rec might be a cluster of
IP numbers) |
Perhaps a properly & honestly configured IP,
with rogue user(s) |
Warn First. |
- NAMEParent IP Domain Name of abuse@ owner of
domain (may well not be the same as the IP number of the
attacking host, eg attacking host
chopok.fns.uniba.sk gets mapped to owner
uniba.sk )
-
REPLY Response if any.
"Fixed+Detail" |
They fixed their problem, ie purged their
customer or their customer server purged the user
account etc. They appear to be an innocent provider
doing their best to responsibly purge miscreants.
They should Not be counter attacked. They are merely
listed here to show what (small) percentage of
providers take such responsible policing action. |
"Auto" |
Automatic standard email reply |
"NS" |
Not Sent: The results of nslookup &/ or
http:// access made the domain too suspicious to
complain to. |
Top of Page
- An initial source code repository will be provided,
probably initially on Berklix servers; probably using
Subversion, a set
of
SVN tools now standardly used on FreeBSD.
- Access to this repository will be discussed with funders before policy is firmly decided.
- Our starting point is, most nation states are too small
to operate a Deter/Idacas system alone, so will have to
co-operate, & for that we need common standards
developed, eg for incident report
records, so it is proposed source code of the project
will be open to all to read & comment on,
- Yes, public read access means rogues will be able to read
our code too; inevitable, the normal price to be paid to
allow a lot more reviewers to check & report potential
loopholes, & to contribute fixes & enhancements to
source code. The old "security by obscurity" paradigm used by
proprietary for-profit companies has long been abandoned on
international public secure software projects.
- Of course only a subset of developers will have commit
privileges to write to the source code repository.
- The source repository will be
replicated/ mirrored on multiple (*) servers in Europe
(etc?), to achieve immunity to disruption from any
nationalist &/or ignorant politicians eg USA in
particular who might want to again disrupt international
developer co-cooperation, (as USA government did with
Crypt.c
& Munitions laws between about 1982 & 2003, (despite
the fact their then enemy already long had Crypt code, &
ignorant USA government was just pointlessly annoying
innocent friendly 3rd parties).
- Multiple servers in different countries so that no one
country's laws can disrupt the project. We will need
encryption technologies etc. What we produce may be argued to
come under purview of USA style munitions laws. Ignorant
politicians in various countries from time to time consider
the only valid users for encryption are the state &
criminals. (Ridiculous) It is recalled France at one time had
laws restricting encryption (current status Here);
other countries have considered similar, USA had the clipper
chip, they wanted to force on others 'cos it was CIA (or
other) cracked already), - So we'll insulate ourselves from
individual daft politicians by having a distributed
base.
- If some country passes too restrictive law, & that country happens to be the master
of the mirrored repositories, other operators of other source
repositories in other countries will simply cease mirroring
the old master, & designate a new master repository.
(Akin to & extending from situation when FreeBSD
insulated itself from daft USA politicians by having
cryptography developed internationally, but Not repository
mastered in USA, but in South Africa, so it was only ever
imported into USA, never exported from USA, & daft USA
law was thus not breached.
Top of Page
-
A distributed command & control database (not a source
code repository) will be hosted elsewhere on several
replicated/ dual-redundant sites ( to make the service more
secure from attack).
- This will be a high security system it will contain
records of past & current attacks & counter response etc.
- It will be designed as a co-operative secure net,
with no central master node (both to make it more secure
from attack, & to avoid nations distracting to debate
which one might best be ceded control of a singular
master.
- Probably each country fronting development funding (which will be cheap) will probably
also want to fund its own national
NOC (Network Operating Centre), th e design will allow
for distributed co-operative functioning.
- The various national government's funding agencies will later (perhaps towards
end of development) inform us who are to be the operators
for their country, so initial sets of security keys can
be exchanged & documented in the database.
Extra Disclaimer: Content of links
may or may not be agreed with, but may have pointers to
technology, laws, disputes, etc.
- www.freebsd.org/ports/security.html
Extra System security software that run on top of Freebsd
- www.freebsd.org/ports/net.html
Extra Networking utilities that run on top of Freebsd
- www.imsec.ch/act/hack/hackerletter.html
"An Open Letter to A Hacker: Dear
Intruder, Hacker, Cracker, or
whatever you like to call yourself"
-
FreeBSD ddos_scan/pkg-descr :-
Scans for distributed denial of service ( DDOS) agents. eg "trinoo", "TFN" and
"stacheldraht".
-
Search engine to case of Abbott V. Act Up Paris, which may
have pointers to French law
- No_Date, Seen 2013-04-06 : Logo: German Federal
Ministry of Education & Research A German Test Net -
german-lab.de - pages In English
- DNS: Domain
Name Service
- DNSSEC:
Domain Name System Security Extensions
"a set of extensions to DNS which provide to DNS clients
(resolvers) origin authentication of DNS data,
authenticated denial of existence, and data integrity, but
not availability or confidentiality"
- IPsec: IPsec = Internet
Protocol Security
"protocol suite for securing Internet Protocol (IP)
communications by authenticating and encrypting each IP
packet"
- bgp: Border
Gateway Protocol
-
DDOS:
-
Honey Pots:
- Zombies:
https://en.wikipedia.org/wiki/Zombie_%28computer_science%29
- No_Date, Seen 2013-04-06 : Logo: German Federal
Ministry of Education & Research A German Test Net -
german-lab.de - pages In English
- Top of Page
Top of Page
More legal verbiage may be necessary here later, but when
reading this page, writing tools, or reading the list, etc
note:
- Re. Un-provoked Attackers
List
- New entries to the Un-provoked
Attackers List may be innocent, they may just not have
had time to track & kill their rogue user account &
report back yet.
- Some hosts may be innocent, just having DNS entries screwed, or in transition.
- Some sites may be innocent, just having guilty host
computer(s).
- Some hosts may have been for innocent purposes, but
been cracked & compromised.
- Some administrators may be innocent, but clueless or
incompetent.
- Some hosts may be largely innocent, but with one or
more guilty users.
- Recipient (of attack & investigating ISPs return
mail) may have been away & not received response
yet.
- Occasional mail failure may occur.
- IP spoofing etc exists.
- Use your own detective skills, including comparing this
list to other intrusion lists, to decide yourself which
sites merit counter attack.
- No guarantee all intrusion attempts will be logged.
(Some recipients of un- provoked attack may not want that).
Others may qualify for immediate defence or hostile counter
attack etc, particularly repeat offenders.
- The Disclaimer on the side
bar also applies.
- Counter attacking is doubtless illegal in some
jurisdictions. Especially where politicians haven't woken
up to the fact the Internet has no national boundaries,
& local laws do Not protect their
citizens & state infrastructure, local laws often just
hinder defence by deterrence.
- Where counter attack would be illegal, don't do it, But
do consider pushing to get local laws changed, &
perhaps also help develop the technologies in parallel
while the politicians take their time changing their local
national laws.
- It's Your responsibility to comply with Your laws,
wherever you are on planet Earth.
- Author & others hereby disclaim everything in &
out of sight & & any & all inference etc.
- Use your common sense ! Determine yourself what's
moral, legal, technically feasible, reasonably or likely
safe, unsafe etc.
Top of Page
|
|