This is a replay attack. So don't use a static (replayable) sequence of ports for the knock sequence. Instead, require a dynamic sequence that is a function of the current time.
The bad guys are motivated (and some of them are clever!). You must assume that they *will* figure out the obfuscated, confusing, or secret portions of your code (if by no other means than disassembling it and inspecting it, line by line).
Certainly, secrecy may be a component of a security implementation -- for example, it is important to not disclose your password to others. But it is not a proper *foundation* for security engineering. If you system is vulnerable in the event that "somebody figured the undocumented flag", then you must assume it is vulnerable, period.
If you build a system such that it is insecure when provided with certain input, the you are being careless and sloppy. At a minimum, users of your system deserve to know the details so that they can make an informed decision about whether the risk is acceptable.
A packet-filtering firewall looks at headers -- source and destination address, port, flags, etc.
This is cheap, quick, and failure-prone (since the mapping of headers to applications is mostly by mutual consensus, and an attacker, or a developer with a deadline looking to bypass the foot-dragging firewall admin, can be assumed to not be "playing fair"). You have no little or no control over packet data/payload. This translates, at a higher layer, to no control over what service runs on a particular TCP port.
OTOH, a proxy firewall "knows" something about your service protocol. It inspects packet payloads and makes decisions (drop, pass, rewrite) based on the content. This is expensive, slow, and failure-prone (hey, the proxy has to correctly parse the service protocol AND be configured correctly!).
Net result -- if you use a packet-filtering firewall and make the assumption that "port 80 means HTTP", sooner or later you're going to be wrong. You need to move up the protocol stack and make filtering decisions based on payload (e.g. is this request, whether HTTP or SOAP, one that I wish to act on?). That's the job of the proxy firewall (or your web/app server -- the line can get blurry).
This paper includes very loose regex heuristics for requests that "might be" attacks. These may be interesting for anomaly detection, when coupled with an engine that records incidence rate (if you see an exponential surge in 'weird' requests, then maybe you're seeing a worm's infection growth curve ).
But the result of deploying these (say, matching for "%20" in a URI) as intrusion detection system rules would be a high false positive rate.
You would be better off looking at arachNIDS for rules that are more specific and less likely to drown you in alerts.
Expand your awareness... A router running Cisco IOS v12+ includes SSH support, as do PIX firewalls and Catalyst 6000 switches. I routinely use Expect and SSH to automate (securely!) maintenance tasks (e.g. ACL updates on the PIX) on my company's infrastructure equipment.
And if the piece of equipment doesn't have SSH support, or if you want to take your admin traffic entirely out of band, how about connecting an old PC to the serial console line? Run an sshd on the PC, and bang -- secure access.
... it's the users. The real network or security admins on a site of > 1 hosts are likely to:
have more pressing issues to resolve than failed identd queries (e.g. exhaustive network probing, exploit attempts, etc.)
have a clue (i.e. that an identd query probably corresponds to a client connection, and that identd lookups at a regular interval are probably from a cron job or similar)
When I ran a single workstation on my desk in college, I had plenty of time to write huffy emails each time a line was added to/var/log/security (by the default log levels, which I had only the slightest inkling of how to configure). Now that I (try to) secure a class B network, I do 3 things:
screen the network with a firewall
run an IDS (Snort http://www.snort.org)
(largely) ignore all the crud that bangs into the firewall each day
Here's what this lets me do with the scenario described above:
When I run end-of-period reporting against the IDS logs, the nightly identd query shows up as a traffic spike. That night, I set the network sniffer to log all traffic to and from the "suspicious" external host/network. Bingo! The outgoing FTP client connection is logged as well. The owner of the offending workstation gets a phone call to find out if they know about their cron-job.
How recently have you studied statistics? It seems that you've forgotten a bit...
One uses samples, or population subsets, when scoring the entire population is cost prohibitive or impossible. In this case, it's unreasonable to demand a large sample size from a volunteer organization that may be short on manpower... and further, it's statistically unnecessary.
A random sample of URLs, n = 50, is adequate for making predictions about the accuracy of the entire population of URLs. The only quibble I have is whether there is an order to the URL list that would make the use of the *first* 50 suspect (i.e. non-random, or non-representative of the population).
I assert that "text" refers to "the words of something written," without regard to how it is written (e.g. a braille book certainly contains text, but is tactile rather than visual). You're (deliberately?) confounding your accustomed presentation mode -- characters on a visual display -- with the information those characters represent.
Ditto with your general assertion regarding the web. The underlying data is abstract! We represent it using arbitrary encodings (ASCII, HTML, WAV, etc), but the notion that the Web is visual in some way that it is not tactile or audible is nonsensical. You're simply describing your preferred I/O device or paradigm.
Slashdot Mirror
I believe you meant Yahoo.
This is a replay attack. So don't use a static (replayable) sequence of ports for the knock sequence. Instead, require a dynamic sequence that is a function of the current time.
The bad guys are motivated (and some of them are clever!). You must assume that they *will* figure out the obfuscated, confusing, or secret portions of your code (if by no other means than disassembling it and inspecting it, line by line).
Certainly, secrecy may be a component of a security implementation -- for example, it is important to not disclose your password to others. But it is not a proper *foundation* for security engineering. If you system is vulnerable in the event that "somebody figured the undocumented flag", then you must assume it is vulnerable, period.
If you build a system such that it is insecure when provided with certain input, the you are being careless and sloppy. At a minimum, users of your system deserve to know the details so that they can make an informed decision about whether the risk is acceptable.
A packet-filtering firewall looks at headers -- source and destination address, port, flags, etc.
This is cheap, quick, and failure-prone (since the mapping of headers to applications is mostly by mutual consensus, and an attacker, or a developer with a deadline looking to bypass the foot-dragging firewall admin, can be assumed to not be "playing fair"). You have no little or no control over packet data/payload. This translates, at a higher layer, to no control over what service runs on a particular TCP port.
OTOH, a proxy firewall "knows" something about your service protocol. It inspects packet payloads and makes decisions (drop, pass, rewrite) based on the content. This is expensive, slow, and failure-prone (hey, the proxy has to correctly parse the service protocol AND be configured correctly!).
Net result -- if you use a packet-filtering firewall and make the assumption that "port 80 means HTTP", sooner or later you're going to be wrong. You need to move up the protocol stack and make filtering decisions based on payload (e.g. is this request, whether HTTP or SOAP, one that I wish to act on?). That's the job of the proxy firewall (or your web/app server -- the line can get blurry).
This paper includes very loose regex heuristics for requests that "might be" attacks. These may be interesting for anomaly detection, when coupled with an engine that records incidence rate (if you see an exponential surge in 'weird' requests, then maybe you're seeing a worm's infection growth curve ).
But the result of deploying these (say, matching for "%20" in a URI) as intrusion detection system rules would be a high false positive rate.
You would be better off looking at arachNIDS for rules that are more specific and less likely to drown you in alerts.Expand your awareness... A router running Cisco IOS v12+ includes SSH support, as do PIX firewalls and Catalyst 6000 switches. I routinely use Expect and SSH to automate (securely!) maintenance tasks (e.g. ACL updates on the PIX) on my company's infrastructure equipment.
And if the piece of equipment doesn't have SSH support, or if you want to take your admin traffic entirely out of band, how about connecting an old PC to the serial console line? Run an sshd on the PC, and bang -- secure access.
- have more pressing issues to resolve than failed identd queries (e.g. exhaustive network probing, exploit attempts, etc.)
- have a clue (i.e. that an identd query probably corresponds to a client connection, and that identd lookups at a regular interval are probably from a cron job or similar)
When I ran a single workstation on my desk in college, I had plenty of time to write huffy emails each time a line was added to- screen the network with a firewall
- run an IDS (Snort http://www.snort.org)
- (largely) ignore all the crud that bangs into the firewall each day
Here's what this lets me do with the scenario described above:When I run end-of-period reporting against the IDS logs, the nightly identd query shows up as a traffic spike. That night, I set the network sniffer to log all traffic to and from the "suspicious" external host/network. Bingo! The outgoing FTP client connection is logged as well. The owner of the offending workstation gets a phone call to find out if they know about their cron-job.
How recently have you studied statistics? It seems that you've forgotten a bit...
One uses samples, or population subsets, when scoring the entire population is cost prohibitive or impossible. In this case, it's unreasonable to demand a large sample size from a volunteer organization that may be short on manpower... and further, it's statistically unnecessary.
A random sample of URLs, n = 50, is adequate for making predictions about the accuracy of the entire population of URLs. The only quibble I have is whether there is an order to the URL list that would make the use of the *first* 50 suspect (i.e. non-random, or non-representative of the population).
This is merely a Lycos-branded version of NeoPlanet's
'browser'. Ironically, it requires IE, as it isn't really a browser at all.
Ditto with your general assertion regarding the web. The underlying data is abstract! We represent it using arbitrary encodings (ASCII, HTML, WAV, etc), but the notion that the Web is visual in some way that it is not tactile or audible is nonsensical. You're simply describing your preferred I/O device or paradigm.