Perhaps diatomaceous earth or Delta Dust. Once they are dead you can air-spray
or vacuum the area to get rid of it all.
--Patrick Darden
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eduardo A. Suárez
Sent: Tuesday, August 12, 2014 1:53 PM
To: NANOG
I don't think anyone uses S-BGB or soBGP in the wild--except on Internet2
(debatable whether I2 is in the wild). Mostly just labs and classrooms...?
We get zmap/nmap/xmap scans on our BGP speakers constantly. However, most
people do a tight lockdown on anything internet-exposed, limiting
Misc thoughts...
Legal
I don't know your background, but I recommend you get with the EFF and/or SANS
and get a good idea of possible legal ramifications, e.g. if you choose to be
an internet provider vs. an internet services provider vs. a private network
provider or a telecommunications
+1 to what Faisal said.
And before you take possession I recommend you do a thorough fibre test. Check
for all aspects of the fibre--signal deterioration and etc. Shoot the fibre
and map it out, it's strengths and weaknesses, so you know what you are dealing
with.
--Patrick Darden
Get a cheap usb--serial converter. Check amazon for trend usb rs-232 db9
serial converter, tu-s9. Then you can just use whatever laptop.
--p
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Max Clark
Sent: Monday, November 10, 2014 2:39 PM
To:
If there is a cheap quad-core laptop with 64GB of ram and no huge downsides...
then sign me up! I expect that will be the standard in 5 years, but right now
that is a hoss.
Izaac's suggestion of using the cloud is good, if you can do it. Cloud
services have come a long way--fast and easy
You say lock in, they say loyalty
Tell them loyalty is two ways, and you need them to help you remain a loyal
customer. To start with, a fantastic CLA. Make sure it includes 15 minute new
optics delivery in case of failure (since you can't keep spares on-site as they
are too expensive.)
MTU should be automatically managed by the AnyConnect client. With that said,
have you done PMTUd (e.g. nmap --script path-mtu dest-ip from one endpoint to
the next)?
I'd do a network map, working with your upstream provider, to identify and
isolate variables. E.g. to find media changes
Securing hosts/applications/services themselves is the way to protect them
from compromise.
Can't go wrong with defense in depth. I'd definitely throw securing routers in
there, throw in firewalls, periodic internal scanning for idiot mistakes,
audits, etc.
I still think IPS/IDSes can be
Like most tools, IPSes are only as good as the people using them.
+10 you can't just plug the magic box inline and expect to relax
IPSes can't replace a well administered modern firewall, with default deny,
well defined protocols with sanity checking, etc. But imho they can help--e.g.
with
IPSes are like any security technology, they are only as good as their
implementor/administrator. I've seen some installations just set up defaults
and leave them that way without any maintenance nor much oversight of alarms.
I've even seen some that do 0-day implementation of new signatures,
Auto-Update can cause problems. I take the stance that updates should be
verified in a CERT or ISO first, before being operationalized.
--p
-Original Message-
From: Colin Johnston [mailto:col...@gt86car.org.uk]
Sent: Friday, February 06, 2015 10:46 AM
To: Darden, Patrick
Cc: Colin
Absolutely.
Valuable humans behind the tools will always provide better benefits than
what vendors may generically sell/deliver.
, February 06, 2015 10:09 AM
To: nanog@nanog.org
Subject: [EXTERNAL]Re: Checkpoint IPS
On 6 Feb 2015, at 21:27, Darden, Patrick wrote:
I understand the whole argument against state, and dismiss it.
One can 'dismiss' the speed of light in a vacuum or the Planck constant, but
that doesn't exempt one
...@gt86car.org.uk]
Sent: Friday, February 06, 2015 10:32 AM
To: Darden, Patrick
Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org
Subject: [EXTERNAL]Re: Checkpoint IPS
Thought I would add
Astaro IPS works great, great functionality and does prevent ddos and exploits.
Colin
These are all excellent tools for a dedicated knowledgeable network security
person to use. The most important element being the dedicated knowledgeable
network security person.
--p
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jimmy Hess
Sent:
I believe the ASA was first developed as the PIX on Plan 9. The OS that came
out of that was originally called Finesse OS, but was later renamed as PIX OS.
After Cisco purchased the PIX and renamed it to the ASA, they began using a
Linux kernel around PIX OS V8.
--p
-Original
+10
The original SANS DDOS task force, and many others since, have emphasized this.
Filter your Outbound! Bogons for obvious reasons, BGP3 to keep routing
multipliers, non-internals to keep from being used as an amplifier network, the
list goes on. Be a good network neighbor.
--p
One more outré purpose for spoofing SIPs is to have you blacklist/nullroute
someone, effectively enlisting you to cause a DOS.
--p
-Original Message-
From: NANOG [mailto:nanog-bounces+patrick.darden=p66@nanog.org] On Behalf
Of Matthew Huff
Sent: Tuesday, March 10, 2015 6:41 PM
To:
Good point. It's a massive job, and sometimes it is best to look at those
piecemeal. Start with small goals, and pick low hanging fruit--your example of
the server room is good. Set it up with and IDS, a firewall, harden the hosts
by turning off/removing unused/unneeded services, setting up
, Darden, Patrick patrick.dar...@p66.com wrote:
Good point. It's a massive job, and sometimes it is best to look at those
piecemeal. Start with small goals, and pick low hanging fruit--your example
of the server room is good. Set it up with and IDS, a firewall, harden the
hosts by turning off
So, obviously, MPTCP can cause problems with Stateful Firewalls (as in
asymmetric routing, out of state packets, etc.). Cisco's take on how to deal
with MPTCP is just as interesting as MPTCP itself is.
Text or it never happened.
--p
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Glen Kent
Sent: Thursday, August 06, 2015 8:44 AM
To: nanog@nanog.org
Subject: [EXTERNAL]Re: Strange traceroute result to VM in EC2, Singapore
Ooops. The attachment was dropped
That could NEVER happen. :-)
--p
http://www.theregister.co.uk/2015/03/18/want_to_dodge_nsa_supply_chain_taps_ask_cisco_for_a_dead_drop/
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Blake Hudson
Sent: Wednesday, September 16, 2015 8:37 AM
To:
You can easily make one-way traffic patterns using nmap. You could use ping -A
to do adaptive ping, or ping -f to flood, both of which would help you find out
some simple metrics (dropped packets, intervals, pps, etc.).
or
You could use Expect to script some common functions, then just run
Talk to your upstream provider. They may already have mitigation in place
(e.g. Arbor devices). If not, then if you know much about this anticipated
attack (and you seem to have some details) they can certainly implement ACLs
and other moderating tools. Regardless, contact the FBI or
Could someone from RedSeal contact me off list please?
(I think the CTO was a regular on NANOG 2 years ago?)
Thanks,
--Patrick Darden
Could a Google Op get in touch with me off-list please? I have a fairly
stupid situation
--p
Watch out for licensing gotchyas.
In active/active ClusterXL situations (load sharing multicast mode) be
careful of multicast--make sure any traversed switches and routers are
compatible with Ethernet Multicast (make sure they don't partition ports
due to high broadcast traffic). Active/Active
I noticed this as well around 11:50 eastern.
--Patrick Darden
-Original Message-
From: Maria Iano [mailto:ma...@iano.org]
Sent: Thursday, May 21, 2009 11:56 AM
To: nanog@nanog.org
Subject: facebook DNS
It looks like facebook is having DNS troubles. The www.facebook.com
subdomain is
nmap has some modes that are useful for this:
nmap -sX network#christmas treepackets are sent, nastygram,
kamikaze, should light up any IPS
nmap -sS network#stealth syn scan, should light up any good IPS
nmap -O network #OS scan, should light up any
Seriously.
--p
-Original Message-
From: Aled Morris [mailto:al...@qix.co.uk]
I'd treat this as the first of their pen tests - a social engineering
attack to obtain secret information about the network, and refuse.
Aled
I'm with Barry--a network diagram showing everything from the pov of the pen
team should be part of the end report.
--p
-Original Message-
From: Barry Greene [mailto:bgre...@senki.org]
Hi Tim,
A _good_ pen test team would not need a network diagram. Their first round of
penetration
You can do it multiple ways:
1. old fashioned hunt groups for multiple analog lines.
2. getting a PRI with one outward facing number.
3. talk to your local Bell about what would best suit your needs (digital
calls? 56K? 64k? 128K? ISDN? Analog? dialout capability, or just dialin?
etc.
My first thought for this was: route filtering. My second thought
was: use different AS#s. Then I reread your question and thought
of something far simpler.
It seems to me if you are migrating from provider A to provider B
then you should set everything up for B, then shut down the
interface
I don't think you will have any troubles with industry standard hardware for
the rates you are quoting. When you get in excess of 300Mbps you have to
start worrying about PPS. When you are looking at 600Mbps then you
should pick out your system more carefully (tcpoe nics, pcie(X), cpu
at over
I think your next step is your lawyer. Put all your missives, your
email, your phone conversations, your logs, your auditing results, your
detection troubleshooting and sleuthing trails etc. in a folder, create
a one page summary including any damages you feel might have been caused
(e.g. time,
Athens GA, tried to call in a ticket (Metro Ethernet) and was told a
master ticket was already in place for my circuits. Other than the
ticket # they wouldn't give me any details. Anybody know anything?
--p
Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing
mirroring), and as always individual discretion.
--Patrick Darden
-Original Message-
From: Leo Bicknell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2008 9:10 AM
To: nanog@nanog.org
Subject: Is it time to
start at the bottom and work up: 192.168.0.X++,
10.0.0.X++, etc. This makes
any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen
a lot of hack jobs
using NAT to get around this. Ugly.
--Patrick Darden
-Original Message-
From: Darden, Patrick S.
Sent: Wednesday
it to
work this way (imho).
--p
-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2008 11:21 AM
To: Darden, Patrick S.
Cc: nanog@nanog.org
Subject: Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote:
*randomly* from
PM
To: Darden, Patrick S.
Cc: nanog@nanog.org
Subject: Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote:
Most organizations that would be doing this would not randomly pick out
subnets, if I understand you. They would randomly pick out a subnet, then
they would sub
Actually, rereading this, I agree. My experience is large companies take it
all, using huge swathes inefficiently, instead of doing it right. In my
previous post I was answering the question I thought you were asking, not your
real question.
I agree with you both.
I think that RFC1918
1. DOS of Cymru (as noted below).
2. False Positives. Your network is suddenly stranded. Maybe on purpose.
(DOS of a network, e.g. China or Youtube).
3. False Negatives. A bogus network is suddenly centrally rubber-stamped.
Could happen. We've seen a lot of shenanigans with the domain
Hi Jay,
Jay Ashworth:
Sure. And he's not always right either; none of us are.
But he gave cogent arguments to support his point, and you gave us
He gave good arguments. You, however, did not.
None of which amounts to wants to hurt people, which is what you
accused him of.
I was out of
Joe makes some good points here. I'd have to add one caveat though:
it depends.
It depends on the server. Busy email servers definitely depend on
having fast DNS, and benefit *greatly* from a caching DNS server using
local sockets instead. Web servers generally don't. Centralized
logging
I think Colin just said everything I said, but in 1/10'th the words.
And he posted before me. Drats.
--Patrick Darden
-Original Message-
From: Colin Alston [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2008 8:38 AM
To: Joe Greco
Cc: [EMAIL PROTECTED]
Subject: Re: maybe a dumb
1. I think ARP is effectively a ping for a mac. It verifies connectivity on
level 2 between two hosts. You have to be on the same segment though
To make it work, you would have to know the mac address of the remote host,
clear the arp table the local host, then send the ARP request
Somebody's going to bring in Emacs now. Then somebody else will claim VI can
do it faster and using less memory
Argh. ;-)
--p
-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 1:29 PM
To: [EMAIL PROTECTED]
Cc: nanog@nanog.org
Subject:
Check your ARP tables, local and on intervening switches/routers. Make sure
there are no duplicate entries for that IP. If you note the response time, the
second packet is always higher which might be indicative. I would also check
for a botched MITM a la CA.
Even if there is no obvious
Or his DSL is set to bridging.
--p
-Original Message-
From: Nathan Ward [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 12:47 AM
To: nanog list
Subject: Re: confusing packet data
On 16/09/2008, at 4:43 PM, Hank Nussbacher wrote:
Are you running Skype? Have you become a
It's been up and down since maybe 11am eastern. We have a ticket in
with them, but no response as of yet.
--Patrick Darden
Athens Regional Medical Center
-Original Message-
From: Raleigh Apple [mailto:rap...@rapidlink.com]
Sent: Tuesday, February 09, 2010 3:14 PM
To: nanog@nanog.org
There's not that much overhead--your certs should be ok. TCP for SQL would
just make sense. I personally wouldn't want to do what you are contemplating.
Here's some stuff to think about:
1. your modems will not be able to do compression. You can't easily compress
random data (e.g.
The short answer is you can't. ARIN only cares about /24s or bigger. If the
network were a /24 or larger, then your customer would need to get an ASN
(autonomous system number) and then you could register the network to them.
More info here: https://www.arin.net
--Patrick Darden
54 matches
Mail list logo
