That's obnoxious. Packet mangling (and DHCP) is an ugly hack and breaks many network protocols (IP Telephone, Incoming services, PtP filesharing, etc.) With IPv6 neither technologies are necessary.
Do you really think that NAT is the solution for the future?? I believe that the right answer is for every electronic device to have routable addresses and apply packet filtering as appropriate. Then everyone can have their own/48 address space.
So, the metadata implementation suggested somehow frees the interface from scanning a large list of files? It's still gotta build a list of files, and it's still gotta look up metadata for each one. You'd have to have a darned big directory to have any signifigant difference there. Macs make up part of the systems that I admin, and they're certainly no joy to view directories with lots of files within - mostly because of the metadata (the B-Tree thing is pretty cool, though).
I disagree with this point. In a filesystem that stored the file type (I prefer MIME) as part of the filesystem data the additional time required to read in the filetype will be imperceptable to the user. The file data would be read in at the same time as the mtime, permissions, etc. To run file(1) on each file would require open()ing each one, reading in the first hundred bytes or so and comparing it against a large list of magic numbers. This entire operation is merely overhead, if the Content-Type was stored as part of the file data it would already have been gotten by the time the system could even start file() scanning.
As others have pointed out, BeOS did this right by making this part of the interface instead of like a Mac where the type/creator info is hidden from the user and not editable without downloading additional software.
I happen to have Debian installed on a SS10 (30MHz TI microSPARC, 32MB RAM) that I use as a backup desktop machine. It runs Blackbox, xlock and Opera (slowly but usably). It also have over 330 days of uptime, and is the most stable machine I have in my house (at work we've had several RH42 machines with 400+ day uptimes though). Next best is my IBM Model 8595 PS/2 with over 150 days, but file handle exhaustion caused by Squid or NFSd killed it in its prime (the system was still running OK, and a quick tweak in/proc would have fixed it if I had been able to get to a shell).
I'm sure that you are right about *BSD being better tuned for the hardware, especially since Linux development is currently more focused on SPARC64. My experience with NetBSD on a Personal Decstation (25MHz MIPS R3000, 24MB RAM) was that it made the hardware run much faster then I would have estimated. I actually ran Squid on that box with a 756MB cache and Samba without performance problems. The only problem was the cheezy excuse for a serial port.
Did you notice that the entire system runs the X protocol? I doubt they are even using XHOST auth on the NCD terminals (Of course I don't actually know anything). With the entirety of the X sessions going over the network in the clear I doubt that they are as worried about the security of their big beefy servers. Those can be kept on their own switches and under tight administrative control. I suppose that they could use SSH and maintain keyfiles for each user across all hosts serving X apps, but this wouldn't help with hosts that are serving Citrix apps and any user who can break root on one of the servers has access to all accounts on all machines anyway. It might give you warm fuzzies but I think that it would only add overhead.
Of course, I could be wrong. I'm just playing devil's advocate.
I don't know about the job market in your area but from where I'm at this isn't actually true. One can get an MCSE cheap, but you get what you pay for, a B-school dropout who heard that "There's money in them computer thingies". A competant MCSE and a competant Unix admin are going to cost around the same.
If you want to mentor a young'in there are probably more people around who are familiar with a/bin/sh prompt than you think. Try asking around, maybe at your local LUG.
That's a really bad analogy. The Internet is nothing like a crowded subway car, packets don't just bump into your external firewall by random chance. It's deterministic, somebody sent them for a reason, whether by mistake or by malice.
Having my machine scanned by cracked boxes and script kiddies, forgetting for a moment the limited number of professional crackers, is definately something that I would wish to bring to the attention of the IP owner. It's common courtesy and not "retarded". It's also definately not something to get your undies in a twist about, and not something that should cause you to forswear the Internet over.
Just like the "Real World(tm)" the Internet is full of garbage and assholes, gee . . . Imagine that.
Just out of curiosity: how do you configure a firewall for those kinds of protocol?
That's easy. You don't. 8^).
There are only a few ways to do this. You can:
Configure the service to use a fixed port
Use firewall with stateful inspection of the higher layer protocol stream
Allow any high port to any other high port (ick, improper trust relationship)
Or just don't and use something else that you can firewall properly
Many firewall products try to inspect the traffic as it is whizzing by but this is almost impossible to get right and very, very easy to get wrong. Most of the time you can inject crafted traffic into a stream and cause the firewall to 1) Crash, 2) Give up root, 3) Open arbitrary hole. This kind of attack can effect IDS systems as well, as they are grabbing an analyzing hostile traffic. I believe that PIX, FW1, Snort, and ISS have all had these kind of problems in the past. Given enough time and effort I'm sure more will be found in the future. Plan accordingly.
That's not entirely true. daytime would be quite helpful in identifying ancient Unix boxes that actually run the service by default as well as defeating time-based protocols (like some bad auth systems). In any case I think that is suspicious but definately not panic-worthy. In fact, if you are denying the traffic very little is panic-worthy.
I'd prefer to think of myself as over zealous rather then clueless.
Ich Auch! And that isn't such a bad thing.
The norm was no response at all and often the worst offenders are the BIG ISPs in that department.
Boringly normal. Even with a database of known good email addresses to override the crappy whois database I still only manage to get a 25-30% response rate (including autoresponders). I still file several hundred incidents a day (well, it is my job 8^). My experience: If you expect someone to jump every time you send an abuse mail you are expecting way too much. I believe that it is your responsibility as a good netizen to report unusual activity (probably from a rooted box). As long as the mail doesn't bounce, what they do with the information is up to them, it is not your problem (unless you are being DoS'd).
Anyway in answer to Kirks question yes this is probably going overboard and admins should probably look at a combination of firewall logging and an IDS like snort to spot the true hostile activity.
Caveat: You will run into the problem that you will never see the payload of any TCP connection that has been denied, making your IDS useful only for single packet UDP and ICMP attacks as well as TCP traffic that you allow (web, smtp, etc.).
I know that on all the firewalls that I build ICMP Echo requests/replies are blocked through the firewall as well as UDP. All of our protected networks are RFC1918 addressed, both ICMP and UDP are stateless protocols making NAT error prone or excessively difficult. It is impossible to prevent random packets from being injected into a UDP stream, for example, exposing their client machines to more risk. If the client has a legit request they can change their security policy (at their own risk), but I wouldn't allow anything by default that wasn't requested.
Too true. Many people thought it would be the greatest if everybody used Linux, then balked at the flood of clueless newbie users. The same people balk when users try to inexpertly secure their systems.
But, face it. People are getting downright racist about packets. Any unknown packet is a bad packet, and it's just there to do something evil, and unimaginably bad.
That's me, the packet facist. While I do work from the assumption that any traffic that I haven't allowed is bad, I don't necessisarily believe that the traffic is evil. Every packet came from somewhere, unless you have really broken network equipment. In any case I believe that any traffic that you can't explain as good should be followed up with the source IP owner. But that's just me, the facist
Yes! And I say this not just because I work for small managed security firm (Please ignore the fact that the website is ugly, I know). If you don't understand how to build a firewall or IDS then you should hire someone else to do it as it is very easy to get wrong (the concept of least privilege is lost on 99% of all network admins who just want things to work). Security takes time to do right and requires constant maintenance (logreading, etc.), if you don't have the time or knowledge to do it right you are going to get burned.
May I suggest to the newbies that the best practice when you see anything you don't recognize is to first do the research (Google, SANS, etc.) to find out what it probably is. Only if you can't figure it out through a moderate amount of searching should you contact the source and ask. May I also suggest that if you are running a commercial IDS that you may wish to double check your findings with Snort (or at least be familiar with the Snort ruleset). Snort is merely programmed to work well for the people who use it and there is little pressure to "bulk up" the ruleset with a lot of spurrious signatures.
I don't know what the UWEC admin said to you, but unless he was quite rude the response you describe was completely uncalled for. I manage many firewalls and if I see a connection attempt on port 23 to some random host I most certainly would question it and bring it up with the owner of the IP block that it came from. If it turns out to be nothing, then fine, but I should at least spend the effort to find out.
9/10 of the time, when I get a human response (mostly I get autoresponders from various ISP's ticketing systems), it is to report that the source machine was cracked and scanning and that they are very sorry, etc. Sometimes I get a generic, "It's fixed" message and rarely I get an abusive message from a person like you. I hate that.
Not everybody has the same attitude or security policy as you. However anyone who gets rude over portscans or portscan reports needs to get a life in my book.
That's cool. I read firewall logs for a living and I like it when I get the "form letter" when I make a mistake as opposed to the "flame letter". It always hurts when some uptight admin reams me for accidently reporting some bogus traffic. I think that my incident form letter is pretty mild "This may be a probe or just a misconfigured client, etc." but I still sometimes get unfriendly critiques of my admin ability, my family's genealogy, etc.
I'm just trying to make the Internet a more friendly place, and it's always better to deal with others who are sympathetic to the cause.
Sure, from your network to your network. There should be no presumption that I am running ident on my internet-accessable hosts, and I don't presume that you are running ident on your hosts. I would imagine that only the very old-school and clueless would attempt, or pay any attention to, ident over the Internet.
Grr. Nobody used finger anymore, except in the rare case to run a.plan or pgp-key server. Unless you specifically know that a host is running finger is should not be assumed. Running the safe_finger rules from the tcpwrappers man page is, like, soooo 1992 8^).
LOL, I remember working for a place that was trying to use InsightManager. They were trying to run the management station on someone's workstation (Win98). This person had to make sure to keep Insight Manager running throughout the day while they worked, and since MAPI is a big steaming pile of non-standard crap they also had to keep Netscape open so the darn thing could send mail. This has to be the stupidest system I have ever seen a network admin try to implement. Foul and unreliable.
I totally agree, but this should be caveated with the fact that many other servers wish/require ident. The worst offenders are IRC networks and SMTP servers. If you just drop ident traffic you can increase connect times while the remote server waits on an ident response that will never come. Better to REJECT the traffic or write a small daemon (beware of DoS-ability) that only responds with some properly formatted garbage.
Re:If these guys had any sense at all...
on
Eco-Terrorism
·
· Score: 2
As I understand it the new coolant is much safer to the environment than Freon. So DuPont's finantial interest and the environmental interest were aligned, explain to me again why this is a bad thing?
Re:Stupidity is Self Curing
on
Eco-Terrorism
·
· Score: 2
One of the main objections people raise is that farmers that grow GM crops, or have their fields inadvertently contaminated by neighbouring farmers, can find themselves with unexpected problems down the line. E.g., they may find themselves beholden to the company they bought the seed from if that company has produced so-called 'terminator' (i.e., sterile) seeds which will not themselves produce seeds that can be resown next year. Assuming farmers want to keep producing crops, they have to keep paying for the privilege.
There is a danger of having a few companies controlling the seed market through their sterile seeds I think there would be a greater danger in having genetically engineered foodstuffs that can reproduce uncontrollably. If some new engineered seed doesn't work out (The people who create this stuff are careful but they are also human beings and fallable) then one can just stop making it, but if it can reproduce then we may end up with annother kudzu (Whoops, and that mistake didn't require any special whizzy technology).
People who believe that they know everything there is to know about genetics and can create with impunity are wrong, also people who belive that all genetic engineers are like Dr. Frankenstein are also wrong.
Slashdot Mirror
That's obnoxious. Packet mangling (and DHCP) is an ugly hack and breaks many network protocols (IP Telephone, Incoming services, PtP filesharing, etc.) With IPv6 neither technologies are necessary.
Do you really think that NAT is the solution for the future?? I believe that the right answer is for every electronic device to have routable addresses and apply packet filtering as appropriate. Then everyone can have their own /48 address space.
I happen to have Debian installed on a SS10 (30MHz TI microSPARC, 32MB RAM) that I use as a backup desktop machine. It runs Blackbox, xlock and Opera (slowly but usably). It also have over 330 days of uptime, and is the most stable machine I have in my house (at work we've had several RH42 machines with 400+ day uptimes though). Next best is my IBM Model 8595 PS/2 with over 150 days, but file handle exhaustion caused by Squid or NFSd killed it in its prime (the system was still running OK, and a quick tweak in /proc would have fixed it if I had been able to get to a shell).
I'm sure that you are right about *BSD being better tuned for the hardware, especially since Linux development is currently more focused on SPARC64. My experience with NetBSD on a Personal Decstation (25MHz MIPS R3000, 24MB RAM) was that it made the hardware run much faster then I would have estimated. I actually ran Squid on that box with a 756MB cache and Samba without performance problems. The only problem was the cheezy excuse for a serial port.
Did you notice that the entire system runs the X protocol? I doubt they are even using XHOST auth on the NCD terminals (Of course I don't actually know anything). With the entirety of the X sessions going over the network in the clear I doubt that they are as worried about the security of their big beefy servers. Those can be kept on their own switches and under tight administrative control. I suppose that they could use SSH and maintain keyfiles for each user across all hosts serving X apps, but this wouldn't help with hosts that are serving Citrix apps and any user who can break root on one of the servers has access to all accounts on all machines anyway. It might give you warm fuzzies but I think that it would only add overhead.
Of course, I could be wrong. I'm just playing devil's advocate.
Hello, neighbor. 8^)
I don't know about the job market in your area but from where I'm at this isn't actually true. One can get an MCSE cheap, but you get what you pay for, a B-school dropout who heard that "There's money in them computer thingies". A competant MCSE and a competant Unix admin are going to cost around the same.
If you want to mentor a young'in there are probably more people around who are familiar with a /bin/sh prompt than you think. Try asking around, maybe at your local LUG.
You both should quit fiddling with your analogies, it's totally pointless. I believe that it is called "Arguing over Symantecs" 8^).
That's a really bad analogy. The Internet is nothing like a crowded subway car, packets don't just bump into your external firewall by random chance. It's deterministic, somebody sent them for a reason, whether by mistake or by malice.
Having my machine scanned by cracked boxes and script kiddies, forgetting for a moment the limited number of professional crackers, is definately something that I would wish to bring to the attention of the IP owner. It's common courtesy and not "retarded". It's also definately not something to get your undies in a twist about, and not something that should cause you to forswear the Internet over.
Just like the "Real World(tm)" the Internet is full of garbage and assholes, gee . . . Imagine that.
That's easy. You don't. 8^).
There are only a few ways to do this. You can:
- Configure the service to use a fixed port
- Use firewall with stateful inspection of the higher layer protocol stream
- Allow any high port to any other high port (ick, improper trust relationship)
- Or just don't and use something else that you can firewall properly
Many firewall products try to inspect the traffic as it is whizzing by but this is almost impossible to get right and very, very easy to get wrong. Most of the time you can inject crafted traffic into a stream and cause the firewall to 1) Crash, 2) Give up root, 3) Open arbitrary hole. This kind of attack can effect IDS systems as well, as they are grabbing an analyzing hostile traffic. I believe that PIX, FW1, Snort, and ISS have all had these kind of problems in the past. Given enough time and effort I'm sure more will be found in the future. Plan accordingly.That's not entirely true. daytime would be quite helpful in identifying ancient Unix boxes that actually run the service by default as well as defeating time-based protocols (like some bad auth systems). In any case I think that is suspicious but definately not panic-worthy. In fact, if you are denying the traffic very little is panic-worthy.
Ich Auch! And that isn't such a bad thing.
Boringly normal. Even with a database of known good email addresses to override the crappy whois database I still only manage to get a 25-30% response rate (including autoresponders). I still file several hundred incidents a day (well, it is my job 8^). My experience: If you expect someone to jump every time you send an abuse mail you are expecting way too much. I believe that it is your responsibility as a good netizen to report unusual activity (probably from a rooted box). As long as the mail doesn't bounce, what they do with the information is up to them, it is not your problem (unless you are being DoS'd).
Caveat: You will run into the problem that you will never see the payload of any TCP connection that has been denied, making your IDS useful only for single packet UDP and ICMP attacks as well as TCP traffic that you allow (web, smtp, etc.).
I know that on all the firewalls that I build ICMP Echo requests/replies are blocked through the firewall as well as UDP. All of our protected networks are RFC1918 addressed, both ICMP and UDP are stateless protocols making NAT error prone or excessively difficult. It is impossible to prevent random packets from being injected into a UDP stream, for example, exposing their client machines to more risk. If the client has a legit request they can change their security policy (at their own risk), but I wouldn't allow anything by default that wasn't requested.
Too true. Many people thought it would be the greatest if everybody used Linux, then balked at the flood of clueless newbie users. The same people balk when users try to inexpertly secure their systems.
Damned if you do, damned if you don't
That's me, the packet facist. While I do work from the assumption that any traffic that I haven't allowed is bad, I don't necessisarily believe that the traffic is evil. Every packet came from somewhere, unless you have really broken network equipment. In any case I believe that any traffic that you can't explain as good should be followed up with the source IP owner. But that's just me, the facist
Yes! And I say this not just because I work for small managed security firm (Please ignore the fact that the website is ugly, I know). If you don't understand how to build a firewall or IDS then you should hire someone else to do it as it is very easy to get wrong (the concept of least privilege is lost on 99% of all network admins who just want things to work). Security takes time to do right and requires constant maintenance (logreading, etc.), if you don't have the time or knowledge to do it right you are going to get burned.
May I suggest to the newbies that the best practice when you see anything you don't recognize is to first do the research (Google, SANS, etc.) to find out what it probably is. Only if you can't figure it out through a moderate amount of searching should you contact the source and ask. May I also suggest that if you are running a commercial IDS that you may wish to double check your findings with Snort (or at least be familiar with the Snort ruleset). Snort is merely programmed to work well for the people who use it and there is little pressure to "bulk up" the ruleset with a lot of spurrious signatures.
I don't know what the UWEC admin said to you, but unless he was quite rude the response you describe was completely uncalled for. I manage many firewalls and if I see a connection attempt on port 23 to some random host I most certainly would question it and bring it up with the owner of the IP block that it came from. If it turns out to be nothing, then fine, but I should at least spend the effort to find out.
9/10 of the time, when I get a human response (mostly I get autoresponders from various ISP's ticketing systems), it is to report that the source machine was cracked and scanning and that they are very sorry, etc. Sometimes I get a generic, "It's fixed" message and rarely I get an abusive message from a person like you. I hate that.
Not everybody has the same attitude or security policy as you. However anyone who gets rude over portscans or portscan reports needs to get a life in my book.
That's cool. I read firewall logs for a living and I like it when I get the "form letter" when I make a mistake as opposed to the "flame letter". It always hurts when some uptight admin reams me for accidently reporting some bogus traffic. I think that my incident form letter is pretty mild "This may be a probe or just a misconfigured client, etc." but I still sometimes get unfriendly critiques of my admin ability, my family's genealogy, etc.
I'm just trying to make the Internet a more friendly place, and it's always better to deal with others who are sympathetic to the cause.
Sure, from your network to your network. There should be no presumption that I am running ident on my internet-accessable hosts, and I don't presume that you are running ident on your hosts. I would imagine that only the very old-school and clueless would attempt, or pay any attention to, ident over the Internet.
Grr. Nobody used finger anymore, except in the rare case to run a .plan or pgp-key server. Unless you specifically know that a host is running finger is should not be assumed. Running the safe_finger rules from the tcpwrappers man page is, like, soooo 1992 8^).
LOL, I remember working for a place that was trying to use InsightManager. They were trying to run the management station on someone's workstation (Win98). This person had to make sure to keep Insight Manager running throughout the day while they worked, and since MAPI is a big steaming pile of non-standard crap they also had to keep Netscape open so the darn thing could send mail. This has to be the stupidest system I have ever seen a network admin try to implement. Foul and unreliable.
I totally agree, but this should be caveated with the fact that many other servers wish/require ident. The worst offenders are IRC networks and SMTP servers. If you just drop ident traffic you can increase connect times while the remote server waits on an ident response that will never come. Better to REJECT the traffic or write a small daemon (beware of DoS-ability) that only responds with some properly formatted garbage.
As I understand it the new coolant is much safer to the environment than Freon. So DuPont's finantial interest and the environmental interest were aligned, explain to me again why this is a bad thing?
There is a danger of having a few companies controlling the seed market through their sterile seeds I think there would be a greater danger in having genetically engineered foodstuffs that can reproduce uncontrollably. If some new engineered seed doesn't work out (The people who create this stuff are careful but they are also human beings and fallable) then one can just stop making it, but if it can reproduce then we may end up with annother kudzu (Whoops, and that mistake didn't require any special whizzy technology).
People who believe that they know everything there is to know about genetics and can create with impunity are wrong, also people who belive that all genetic engineers are like Dr. Frankenstein are also wrong.