FTPS is WORSE. The problem with FTP in general is with stateful firewalls and NAT/PAT.
FTP is a ridiculous protocol. For FTP to work at all these days, firewalls actually need to go out of their way to snoop in on the control channel and watch for the data channel IP & port, and then use that to pre-populate the state table with an entry for the data session.
This breaks down on a lot of firewalls if you change the control port, or if you use FTPS where the control session is encrypted and the firewall can't snoop in on the session to make it work. Instead, a common solution is to configure a large static range of ephemeral ports for the data connections that just need to be always allowed through the firewall.
Using FTP these days makes zero sense when there are better alternatives, or as OP stated, FTP just needs to die!!
SFTP on the other hand at least works over a single port (SSH), but has its own problems with SSH flow control fighting TCP flow control, multiplexed sessions over a single blocking TCP stream, etc.
"This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations."
That works out to about 45mil computations/sec for CPU or 2.65 bil computations/sec for GPU.
To get it done in 30 days would take a 79,000 machine CPU botnet, or a 1,342 machine GPU botnet.
Fudge the numbers a bit as they probably won't be running full-tilt for 30 days straight, and they won't all have CPU/GPU as spec'd in the attack (paper protoyped on Nvidia GTX 970 btw). Still, we're nowhere remotely close to 10mil machine botnet taking 3 years.
I'm convinced that Casper Dik was just a code-name for the entire SunOS/Solaris support team, and that there's no way any one individual can know and contribute so much.
Decades later, and I still aspire to have even a tenth of a clue as him.
Atari 130XE? I had the 64K version, the Atari 65XE.
YMMV, but I got together with a friend a few months ago and got him to drag his Commodore 64 stuff out of the closet. We couldn't get video output on his fancypants modded C64, but his vanilla C64 worked fine, along with disk drives and every single floppy we tried (likely from late 80s, last touched in early 90s).
I've heard before that some floppy drives may have components that wear with age (e.g. rubber belts that rot and disintegrate with age), but it's worth a shot.
Regarding expansion, as I understand it, the effects on objects within something as small as a galaxy are insignificant compared to the force of gravity holding the galaxy together.
The greater the distance between two objects, the greater the effect of expansion; and so it does become significant when comparing two distant galaxies.
Is this:
"Network Admin" as in switches, routers, firewalls, etc.;
"Network Admin" as in the often used anachronism dating from the 80s for novell admins but actually referring to what's presently known as "Windows Admin," or generically "Server Admin"; or
"Network Admin" as in "Jack of all Trades IT guy" in smaller organizations?
If you meant the first one, which maybe you did given that you have a CCNA, then you don't need to learn Exchange and SQL server. It won't hurt, but it sure won't help as much as going for your CCNP will.
Also, consider this a branching-off point. It sounds like you might presently have a job in the "jack of all trades" category, which can give you a high-level perspective of many of the areas of specialization. Pick the one you like the most, and start learning your new specialty. Cross-training on the basics can be very valuable. Learning how to do basic scripting (perl, python, lua, whatever..) will save you much more time over the years than you spend learning it. If you encounter a repeatable process then automate it. If you don't know how, then learn how, and automate it. Sorry if I'm drifting away from your question, and into general advice for someone starting out.:-)
I also have to agree with some of the other posters, even if it seems like they're trolling. Get that A+ and Network+ crap off your resume! Nobody respects it, and it only serves to accentuate your inexperience. Start cramming and replace it with something better -- schedule your exam today if you need motivation to pick up the books!
Oh, and lastly.. Don't hang out posting on slashdot. Big waste of time!
Most folks I know don't want to sit next to noisy heat-generating equipment in a lab, in the uncomfortable workspaces that often accompany them.
Keep only lab gear in the lab, with enough workspace for the just the physical hands-on type of work that's sometimes required.
Invest in switched remotely manageable power strips, remote KVM/Serial., and layer 1 switches (e.g. http://www.mrv.com/tap/physical-layer/ ). SSH/RDP access to the various lab hosts for things like packet capture, traffic generation, test automation, etc. Hire a cable-monkey (no offence intended to cable monkeys) to plug everything in. Document everything very very well.
Then, outside of the lab itself, set up some number of comfortable workspaces in a quiet setting, multiple monitors, etc., for the folks that actually need hands-on.
Hah.. I was along for a test drive of a new car once with a friend. We drove about two miles without him realizing the parking brake was full on. Upon noticing an odd smell eminating from the car, the salesman remarked that the car was so new that you could still smell the "engine surficant."
Consider that:
- a "mediation" device such as found at http://www.ss8.com/, that may cost you more than $100,000 a crack.
- each request will require legal dept oversight, and support resources.
- the cost of expensive software upgrades for vendors where lawful intercept is an upsell; or perhaps hardware upgrades that are only necessary to support lawful intercept functionality.
- despite the great cost, the capabilities are not actually used very frequently.
In 2006, there were a total of 1,839 authorized wiretaps, and only 1,714 that were actually installed. Total number of days in operation is 68,380, which gives an average of roughly 40 days per wiretap. Now consider that 1685 out of 1839 wiretap orders were for mobile devices (i.e. not Comcast). This leaves about 139 other taps, some of which Comcast might be involved with.
At Comcast's rates, that would come up to 139 * $1,000 = $139,000. With a 40 day average, you're looking at 46 * $750 = $34,500 in additional month fees. This brings you to a total of $173,500 per year for nationwide US non-wiretap fees.
Comcast can't be recovering anything close to the full cost of their intercept expense from these fees.
Cell phones with flip covers -- the keyguard feature worked great for me on non-flip Nokias which were damn near indestructible. Every flip phone I've ever owned eventually met its demise due to wear and tear from the flip feature.
My Sanyo Katana flip phone that likes to dial the last called number from my pocket on speaker-phone, because even when it's flipped closed, the right combination of button presses on the side of the phone can still manage to dial.
Cisco IOS -- Maintenance software releases are for replacing old bugs with new bugs, Technology releases are for introducing new features with new bugs.
These are two very different animals. Some comparisons between T1 and DSL:
More expensive infrastructure / Dedicated vs. Shared Transport T1: Two copper pairs, NIUs, Repeaters, DCS, SONET muxes, fixed bandwidth per-circuit TDM infrastructure DSL: One copper pair, DSLAM, ATM Switches, shared-bandwidth ATM infrastructure
To give you an idea, T1 hand-off to the aggregation device might be done on the DS-3 or OC-3 level. One DS-3 card can only ever hope to handle 28 T-1s because each T1 circuit has a dedicated 1/28th portion of that DS-3.
With DSL, the hand-off might be an ATM DS-3 or OC-3 with several hundreds of DSL subscribers attached with no bandwidth guarantees.
DSL is also not guaranteed to be available in all locations. T1 is almost universally available through use of repeaters.
Dedicated vs. Shared Internet Access T1: Almost universally sold as "Dedicated Internet Access" (DIA). DSL: Almost universally sold as no-guarantee "up to Xmbps" service.
Latency T1: Low latency DSL: Can often be very high due to cell interleaving (buffering/scrambling for x ms. that increases chance of error correction recoveries) which may be enabled universally to extend service to customers far from CO.
Typical Support T1: "It's Christmas day, but we'll have someone working on this within two hours." DSL: "We'll have someone working on this within two business days."
Terms and Conditions T1: Do anything you'd like, as long as it's not illegal. DSL: Usually a laundry list of: You cannot resell service, run servers, use excessive bandwidth, etc.
Some providers with business DSL offerings offer higher support levels and less restrictive T&C at a much higher cost than residential DSL.
There are several more things I could go into (single standard vs. many standard; availability of business-grade CPE; disparity in upstream bandwidth; SLAs; uses other than DIA; etc.), but this should be enough to show you some of the general differences.
Slashdot Mirror
The argument was definitely around in the BBS days, when (almost) everybody knew it was pronounced like "gif." ;)
FTPS is WORSE. The problem with FTP in general is with stateful firewalls and NAT/PAT.
FTP is a ridiculous protocol. For FTP to work at all these days, firewalls actually need to go out of their way to snoop in on the control channel and watch for the data channel IP & port, and then use that to pre-populate the state table with an entry for the data session.
This breaks down on a lot of firewalls if you change the control port, or if you use FTPS where the control session is encrypted and the firewall can't snoop in on the session to make it work. Instead, a common solution is to configure a large static range of ephemeral ports for the data connections that just need to be always allowed through the firewall.
Using FTP these days makes zero sense when there are better alternatives, or as OP stated, FTP just needs to die!!
SFTP on the other hand at least works over a single port (SSH), but has its own problems with SSH flow control fighting TCP flow control, multiplexed sessions over a single blocking TCP stream, etc.
Apparently Microsoft is in the smartphone business now too.. Who knew?
How do you figure?
"This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations."
That works out to about 45mil computations/sec for CPU or 2.65 bil computations/sec for GPU.
To get it done in 30 days would take a 79,000 machine CPU botnet, or a 1,342 machine GPU botnet.
Fudge the numbers a bit as they probably won't be running full-tilt for 30 days straight, and they won't all have CPU/GPU as spec'd in the attack (paper protoyped on Nvidia GTX 970 btw). Still, we're nowhere remotely close to 10mil machine botnet taking 3 years.
=(
I'm convinced that Casper Dik was just a code-name for the entire SunOS/Solaris support team, and that there's no way any one individual can know and contribute so much.
Decades later, and I still aspire to have even a tenth of a clue as him.
Try Singapore.
I ran a Renegade board for several years. Good times!
There were still a handful connected to the Internet last time I checked.
The same guy (Jason Scott) has hundreds of the old shareware (and other) CDs up for download on archive.org as well. Lots of good stuff there.
Atari 130XE? I had the 64K version, the Atari 65XE.
YMMV, but I got together with a friend a few months ago and got him to drag his Commodore 64 stuff out of the closet. We couldn't get video output on his fancypants modded C64, but his vanilla C64 worked fine, along with disk drives and every single floppy we tried (likely from late 80s, last touched in early 90s).
I've heard before that some floppy drives may have components that wear with age (e.g. rubber belts that rot and disintegrate with age), but it's worth a shot.
Regarding expansion, as I understand it, the effects on objects within something as small as a galaxy are insignificant compared to the force of gravity holding the galaxy together.
The greater the distance between two objects, the greater the effect of expansion; and so it does become significant when comparing two distant galaxies.
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
Ditto.
My next question is: is his machine compromised and part of a botnet. I.e. is he the one doing the DoSing, and his router is falling over as a result.
Is this:
"Network Admin" as in switches, routers, firewalls, etc.;
"Network Admin" as in the often used anachronism dating from the 80s for novell admins but actually referring to what's presently known as "Windows Admin," or generically "Server Admin"; or
"Network Admin" as in "Jack of all Trades IT guy" in smaller organizations?
If you meant the first one, which maybe you did given that you have a CCNA, then you don't need to learn Exchange and SQL server. It won't hurt, but it sure won't help as much as going for your CCNP will.
Also, consider this a branching-off point. It sounds like you might presently have a job in the "jack of all trades" category, which can give you a high-level perspective of many of the areas of specialization. Pick the one you like the most, and start learning your new specialty. Cross-training on the basics can be very valuable. Learning how to do basic scripting (perl, python, lua, whatever..) will save you much more time over the years than you spend learning it. If you encounter a repeatable process then automate it. If you don't know how, then learn how, and automate it. Sorry if I'm drifting away from your question, and into general advice for someone starting out. :-)
I also have to agree with some of the other posters, even if it seems like they're trolling. Get that A+ and Network+ crap off your resume! Nobody respects it, and it only serves to accentuate your inexperience. Start cramming and replace it with something better -- schedule your exam today if you need motivation to pick up the books!
Oh, and lastly.. Don't hang out posting on slashdot. Big waste of time!
Most folks I know don't want to sit next to noisy heat-generating equipment in a lab, in the uncomfortable workspaces that often accompany them.
Keep only lab gear in the lab, with enough workspace for the just the physical hands-on type of work that's sometimes required.
Invest in switched remotely manageable power strips, remote KVM/Serial., and layer 1 switches (e.g. http://www.mrv.com/tap/physical-layer/ ). SSH/RDP access to the various lab hosts for things like packet capture, traffic generation, test automation, etc. Hire a cable-monkey (no offence intended to cable monkeys) to plug everything in. Document everything very very well.
Then, outside of the lab itself, set up some number of comfortable workspaces in a quiet setting, multiple monitors, etc., for the folks that actually need hands-on.
Let everyone else access it remotely.
Yeah, but the ones in original condition would then be worth a lot less if it weren't for all the Bubbas fucking up the rest.
Hah.. I was along for a test drive of a new car once with a friend. We drove about two miles without him realizing the parking brake was full on. Upon noticing an odd smell eminating from the car, the salesman remarked that the car was so new that you could still smell the "engine surficant."
Insanity is a government-sponsored crotch groper that doesn't know the difference between electromagnetic and pressure waves?
Perhaps insanity is looking to said crotch groper for safety information on a new and relatively untested radiation generating device.
$1,000 is a lot of dough, but is it unreasonable?
Consider that:
- a "mediation" device such as found at http://www.ss8.com/, that may cost you more than $100,000 a crack.
- each request will require legal dept oversight, and support resources.
- the cost of expensive software upgrades for vendors where lawful intercept is an upsell; or perhaps hardware upgrades that are only necessary to support lawful intercept functionality.
- despite the great cost, the capabilities are not actually used very frequently.
Compare this with the data at http://www.uscourts.gov/library/wiretap.html
In 2006, there were a total of 1,839 authorized wiretaps, and only 1,714 that were actually installed.
Total number of days in operation is 68,380, which gives an average of roughly 40 days per wiretap.
Now consider that 1685 out of 1839 wiretap orders were for mobile devices (i.e. not Comcast).
This leaves about 139 other taps, some of which Comcast might be involved with.
At Comcast's rates, that would come up to 139 * $1,000 = $139,000. With a 40 day average, you're looking at 46 * $750 = $34,500 in additional month fees. This brings you to a total of $173,500 per year for nationwide US non-wiretap fees.
Comcast can't be recovering anything close to the full cost of their intercept expense from these fees.
I recently found out about this when I wanted to ask a simple straightforward question, and was forced to wait >20 minutes on hold.
Will this be taking place from a nursing home, with Spock reminiscing about his earlier years?
It wouldn't be very logical of him, but he is half human.
Cell phones with flip covers -- the keyguard feature worked great for me on non-flip Nokias which were damn near indestructible. Every flip phone I've ever owned eventually met its demise due to wear and tear from the flip feature.
My Sanyo Katana flip phone that likes to dial the last called number from my pocket on speaker-phone, because even when it's flipped closed, the right combination of button presses on the side of the phone can still manage to dial.
Cisco IOS -- Maintenance software releases are for replacing old bugs with new bugs, Technology releases are for introducing new features with new bugs.
Windows Vista -- no explanation required.
Then there are those of us that drive SUVs because our penis wont fit in a compact.
These are two very different animals. Some comparisons between T1 and DSL:
More expensive infrastructure / Dedicated vs. Shared Transport
T1: Two copper pairs, NIUs, Repeaters, DCS, SONET muxes, fixed bandwidth per-circuit TDM infrastructure
DSL: One copper pair, DSLAM, ATM Switches, shared-bandwidth ATM infrastructure
To give you an idea, T1 hand-off to the aggregation device might be done on the DS-3 or OC-3 level. One DS-3 card can only ever hope to handle 28 T-1s because each T1 circuit has a dedicated 1/28th portion of that DS-3.
With DSL, the hand-off might be an ATM DS-3 or OC-3 with several hundreds of DSL subscribers attached with no bandwidth guarantees.
DSL is also not guaranteed to be available in all locations. T1 is almost universally available through use of repeaters.
Dedicated vs. Shared Internet Access
T1: Almost universally sold as "Dedicated Internet Access" (DIA).
DSL: Almost universally sold as no-guarantee "up to Xmbps" service.
Latency
T1: Low latency
DSL: Can often be very high due to cell interleaving (buffering/scrambling for x ms. that increases chance of error correction recoveries) which may be enabled universally to extend service to customers far from CO.
Typical Support
T1: "It's Christmas day, but we'll have someone working on this within two hours."
DSL: "We'll have someone working on this within two business days."
Terms and Conditions
T1: Do anything you'd like, as long as it's not illegal.
DSL: Usually a laundry list of: You cannot resell service, run servers, use excessive bandwidth, etc.
Some providers with business DSL offerings offer higher support levels and less restrictive T&C at a much higher cost than residential DSL.
There are several more things I could go into (single standard vs. many standard; availability of business-grade CPE; disparity in upstream bandwidth; SLAs; uses other than DIA; etc.), but this should be enough to show you some of the general differences.
I can't wait to see WoW game and monthly subscription, PC hardware, video cards, internet connectivity, etc. written off as business expenses!
Many of those 8.5 million are Chinese that may not pay the same rates as in the US.